[Bug c/52923] New: Warn if making external references to local stack memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923 Bug #: 52923 Summary: Warn if making external references to local stack memory Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: fredrik.hederstie...@securitas-direct.com Created attachment 27123 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27123 Example code with functions returning with stack memory refs bugs. GCC does warn if returning a pointer to a local variable (stack memory). But there are alot of more cases where GCC could possibly warn, eg. when references are made to local variables or stack memory. See this attached example code. GCC warns for first case, but not the others. I think all cases can be considered program bugs, and could trigger a compiler warning I think. I've found out that the present warning is done in "c-typeck.c", is this the right place to but additional warnings of this kind too? Thanks & Best Regards Fredrik Hederstierna The example code file was compiled with "-O2 -W -Wall -Wextra" for enabling as many warnings as possible.
[Bug c++/52922] failed to build gcc 4.7 on SL6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922
--- Comment #3 from scott at smedleyfamily dot net 2012-04-10 07:45:58 UTC ---
Hi Andrew,
Works fine - see below.
Let me know if there's anything I can do to help.
Scott. :)
lcas-el6build1>> cat >! test.cc
#include "string.h"
#include "stdio.h"
int main(void)
{
printf ("Hello world.\n");
}
lcas-el6build1>> g++ -pedantic test.cc
lcas-el6build1>> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.2/libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6.2/configure --prefix=/usr/local/gcc-4.6.2
--enable-cloog-backend --enable-lto
Thread model: posix
gcc version 4.6.2 (GCC)
[Bug c++/52922] failed to build gcc 4.7 on SL6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922 --- Comment #4 from Jonathan Wakely 2012-04-10 07:52:39 UTC --- This implies the /usr/local/bin/gcc compiler you're using was not built on SL6.1, or was built against an older glibc I've had exactly this error when trying to use a compiler built on CentOS5 on CentOS6 - the fixincluded headers assume an older glibc Try installing gcc from SL RPMs via yum and ensuring that is earlier in your path than /usr/local/bin/gcc
[Bug c/52923] Warn if making external references to local stack memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923 --- Comment #1 from Andrew Pinski 2012-04-10 07:59:40 UTC --- These all need to have some kind of flow analysis going on (the return one is the only one which does not which is why we warn already).
[Bug c/52923] Warn if making external references to local stack memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923 --- Comment #2 from Jonathan Wakely 2012-04-10 08:03:13 UTC --- See also PR 49974 requesting the same thing for C++ and PR 51270 and PR 44859 are similar but for temporaries
[Bug c++/52922] failed to build gcc 4.7 on SL6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922 --- Comment #5 from scott at smedleyfamily dot net 2012-04-10 08:13:44 UTC --- H, you are right. I was compiling gcc with a version of gcc built on Centos 5.6. (though I compiled Andrew's test program with a different "native" version) I would like to build gcc on an "old" system (Centos 5.6) & then install the binaries on other "newer" Linux systems - is it possible? We want to have the exact same compiler running on dozens of Linux systems running either Centos >= 5.6 or SL6.x.
[Bug c++/52924] New: Using an std::function object as deleter of shared_ptr in C++0x mode does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52924
Bug #: 52924
Summary: Using an std::function object as deleter of shared_ptr
in C++0x mode does not compile
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@essi.fr
The following program fails to compile in C++0X mode :
#include
#include
class A {};
A a;
void fdeleter(A *pa) {}
std::function deleter = fdeleter;
std::shared_ptr spa(&a, deleter);
int main()
{}
Note that
- replacing deleter by fdeleter (or a lambda) in spa definition works;
- compiling in non-c++0x mode (replacing std by std::tr1 works as well
- this program compiles OK in c++0x mode with gcc-4.6.x
gcc-version : gcc-4.7.0 (64 bits)
system : Linux Fedora 15 (64 bits)
gcc configuration: (gcc -v)
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/test/gcc-4.7.0/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/test/gcc-4.7.0
--with-local-prefix=/usr/local/test/gcc-4.7.0 --enable-threads
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++
--with-gmp-lib=/usr/lib64 --with-mpfr-lib=/usr/lib64 --with-mpc-lib=/usr/lib64
--disable-multilib
Thread model: posix
gcc version 4.7.0 (GCC)
Compilation command and compiler output:
g++ -g -Wall -Wextra -std=c++0x -o deleter-bug-c++0x deleter-bug-c++0x.cpp
deleter-bug-c++0x.cpp:7:6: warning: unused parameter ‘pa’ [-Wunused-parameter]
In file included from
/usr/local/test/gcc-4.7.0/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/shared_ptr.h:52:0,
from
/usr/local/test/gcc-4.7.0/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/memory:87,
from deleter-bug-c++0x.cpp:1:
/usr/local/test/gcc-4.7.0/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/shared_ptr_base.h:
In instantiation of ‘class std::_Sp_counted_deleter, std::allocator, (__gnu_cxx::_Lock_policy)2u>’:
/usr/local/test/gcc-4.7.0/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/shared_ptr_base.h:474:8:
required from ‘std::__shared_count<_Lp>::__shared_count(_Ptr, _Deleter) [with
_Ptr = A*; _Deleter = std::function; __gnu_cxx::_Lock_policy _Lp =
(__gnu_cxx::_Lock_policy)2u]’
/usr/local/test/gcc-4.7.0/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/shared_ptr_base.h:776:37:
required from ‘std::__shared_ptr<_Tp, _Lp>::__shared_ptr(_Tp1*, _Deleter)
[with _Tp1 = A; _Deleter = std::function; _Tp = A;
__gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
/usr/local/test/gcc-4.7.0/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/shared_ptr.h:130:37:
required from ‘std::shared_ptr<_Tp>::shared_ptr(_Tp1*, _Deleter) [with _Tp1 =
A; _Deleter = std::function; _Tp = A]’
deleter-bug-c++0x.cpp:10:35: required from here
/usr/local/test/gcc-4.7.0/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/shared_ptr_base.h:324:11:
error: looser throw specifier for ‘virtual std::_Sp_counted_deleter, std::allocator,
(__gnu_cxx::_Lock_policy)2u>::~_Sp_counted_deleter()’
/usr/local/test/gcc-4.7.0/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/shared_ptr_base.h:116:7:
error: overriding ‘std::_Sp_counted_base<_Lp>::~_Sp_counted_base() noexcept
(true) [with __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
Compilation exited abnormally with code 1 at Tue Apr 10 10:00:29
[Bug middle-end/52925] New: [4.5/4.6 Regression] var-tracking never terminates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52925 Bug #: 52925 Summary: [4.5/4.6 Regression] var-tracking never terminates Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org gcc -O2 -g-S bug-756235_t.c hangs forever in #0 0x01176db4 in htab_mod_1 (x=99, y=59, inv=363980280, shift=5) at /space/rguenther/src/svn/gcc-4_6-branch/libiberty/hashtab.c:257 #1 0x01176e50 in htab_mod_m2 (hash=99, htab=0x1a79900) at /space/rguenther/src/svn/gcc-4_6-branch/libiberty/hashtab.c:282 #2 0x011779b3 in htab_find_slot_with_hash (htab=0x1a79900, element=0x1b77fb0, hash=99, insert=INSERT) at /space/rguenther/src/svn/gcc-4_6-branch/libiberty/hashtab.c:671 #3 0x00c93ad7 in vars_copy (dst=0x1a79900, src=0x1a7a850) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/var-tracking.c:1601 #4 0x00c9344b in shared_hash_unshare (vars=0x1a948e8) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/var-tracking.c:1404 #5 0x00c93520 in shared_hash_find_slot_unshare_1 (pvars=0x1bd6748, dv=0x1b77cb0, dvhash=67, ins=INSERT) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/var-tracking.c:1440 #6 0x00c9357e in shared_hash_find_slot_unshare (pvars=0x1bd6748, dv=0x1b77cb0, ins=INSERT) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/var-tracking.c:1448 #7 0x00ca22fb in set_variable_part (set=0x1bd6598, loc=0x75bc9528, dv=0x1b77cb0, offset=0, initialized=VAR_INIT_STATUS_INITIALIZED, set_src=0x0, iopt=INSERT) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/var-tracking.c:6730 #8 0x00c947c9 in val_store (set=0x1bd6598, val=0x1b77cb0, loc=0x75bc9528, insn=0x7504f870, modified=0 '\000') at /space/rguenther/src/svn/gcc-4_6-branch/gcc/var-tracking.c:1889 #9 0x00c9f7b3 in compute_bb_dataflow (bb=0x74209dd0) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/var-tracking.c:5824 #10 0x00ca08ab in vt_find_locations () with no progress. Maybe works in 4.7 by luck.
[Bug middle-end/52925] [4.5/4.6 Regression] var-tracking never terminates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52925 Richard Guenther changed: What|Removed |Added Known to work||4.3.6 Target Milestone|--- |4.5.4
[Bug middle-end/52925] [4.5/4.6 Regression] var-tracking never terminates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52925 --- Comment #1 from Richard Guenther 2012-04-10 08:40:29 UTC --- Created attachment 27124 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27124 preprocessed source
[Bug c++/52924] Using an std::function object as deleter of shared_ptr in C++0x mode does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52924 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-10 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-04-10 09:07:57 UTC --- Mine
[Bug c++/52922] failed to build gcc 4.7 on SL6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922 --- Comment #6 from Jonathan Wakely 2012-04-10 09:11:03 UTC --- No, in general you can't use GCC built for one target on a different target. What I do is just build the same version of GCC with the exact same configuration on each OS I need to target.
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #1 from Jonathan Wakely 2012-04-10 09:12:39 UTC --- we might need an explicit instantiation of that type in libstdc++.so, I'll investigate
[Bug libstdc++/52917] [DR 2048] explicitly stated return type in std::mem_fn cannot be compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
--- Comment #3 from freunddeslichts at web dot de 2012-04-10 09:54:28 UTC ---
Ok, I didn't know about the defect report and resolution yet.
I must admit that I quite like the syntax.
I added a remark about the defect and a short example to
http://en.cppreference.com/w/cpp/utility/functional/mem_fn
And I noted that the most c++11-ish code would be anyway:
auto y = [] (X& x) {return x.get();};
[Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52916 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #2 from Tobias Burnus 2012-04-10 10:02:13 UTC --- That's probably due to my patch for PR 40973 / PR 52751 (Rev. 186223). That patch marked functions/subroutines and variables from MODULES as TREE_PUBLIC() = 0, if they have the PRIVATE attribute and no C-binding name. That will definitely fail if one accesses the procedures directly, e.g. from C via "__moduleName_MOD_subroutine ();". The question is whether 481.wrf does so (probably not). However, I fail to see how it could otherwise encounter the problem. As I do not have access to SPEC CPU, I would be happy if someone could provide more information. (Best would be a test case.) As a first step: Are the missing symbols procedures or (global) variables? Or both?
[Bug c++/52924] [4.7 Regression] Using an std::function object as deleter of shared_ptr in C++0x mode does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52924 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |4.7.1 Summary|Using an std::function |[4.7 Regression] Using an |object as deleter of|std::function object as |shared_ptr in C++0x mode|deleter of shared_ptr in |does not compile|C++0x mode does not compile --- Comment #2 from Jonathan Wakely 2012-04-10 10:22:41 UTC --- The problem is that std::function::~function should be noexcept, but isn't because PR 50043 is not fixed on the 4.7 branch I'll fix it by adding a noexcept destructor to _Sp_counted_deleter and/or _Sp_counter_deleter::_My_deleter
[Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52916 Tobias Burnus changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Tobias Burnus 2012-04-10 10:27:37 UTC --- Found the information I was looking for at http://www.cesm.ucar.edu/models/cesm1.0/cesm/cesmBbrowser/html_code/esmf_wrf_timemgr/ESMF_TimeMod.F90.html The problem is that the PRIVATE module procedure is used as specific procedure for an operator (which is PUBLIC). Thus, one cannot set the TREE_PUBLIC() = 0 for PRIVATE procedures, if (a) the generic procedure / user-defined operator/assignment is not also PRIVATE (b) a procedure is used as type-bound procedure in a nonabstract nonprivate TYPE declaration. [(c) if the (sub)module has a submodule. (Note: Currently, no submodules are supported.)] The simplest might be to add another attribute - and set it during resolution. Workaround: Undo the "build_function_decl" part of the commit Rev. 186223 - or revert the complete commit. Test case, which will produce at link time with any optimization level: undefined reference to `__m_MOD_bar' ! - FILE 1 module m interface gen module procedure bar end interface gen private :: bar contains subroutine bar() print *, "bar" end subroutine bar end module m ! - FILE 2 use m call gen() end
[Bug middle-end/52925] [4.5/4.6 Regression] var-tracking never terminates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52925 Bart Van Assche changed: What|Removed |Added CC||bart.vanassche at gmail dot ||com --- Comment #2 from Bart Van Assche 2012-04-10 10:52:49 UTC --- I ran into this issue too - see also http://bugzilla.novell.com/show_bug.cgi?id=756235.
[Bug c/52926] New: gcc 4.7.0 20120324: wrong optimized asm code produced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52926
Bug #: 52926
Summary: gcc 4.7.0 20120324: wrong optimized asm code produced
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jkt...@gmail.com
gcc -c hash.c -O2 -std=c99 -fno-common -Wstrict-prototypes -Wmissing-prototypes
-Wsign-compare -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-align
-Wpacked -Wformat -Wno-format-extra-args -Wformat-security -fstack-protector
-Wall -Werror -ggdb -MD -D_GNU_SOURCE -DMAJOR= -DMINOR= -DVERSION=.
gcc -o sum sum.o hash.o -lpthread -Wl,-z -Wl,defs -Wl,-zrelro
ERROR: GCC makes wrong assembler code for LongAdd function located in hash.c:
static void LongADD(void *a,void *b)
{
uint32_t s = 0;
uint16_t *a16 = (uint16_t*)a;
uint16_t *b16 = (uint16_t*)b;
int i;
for(i = 0;i<16;i++)
{
s = (uint32_t)a16[i]+(uint32_t)b16[i]+(s>>16);
a16[i] = (uint16_t)s;
}
}
static void LongADD_1(void * a,uint32_t b)
{
uint32_t bb[8];
memset(bb,0,sizeof(bb));
bb[0] = b;
LongADD(a,bb);
}
OBJDUMP show me the next code for LongAdd:
00401f30 :
401f30: 48 c7 44 24 d8 00 00 mov QWORD PTR [rsp-0x28],0x0
401f37: 00 00
401f39: 48 c7 44 24 e0 00 00 mov QWORD PTR [rsp-0x20],0x0
401f40: 00 00
401f42: 31 c0 xor eax,eax
401f44: 48 c7 44 24 e8 00 00 mov QWORD PTR [rsp-0x18],0x0
401f4b: 00 00
401f4d: 48 c7 44 24 f0 00 00 mov QWORD PTR [rsp-0x10],0x0
401f54: 00 00
401f56: 31 c9 xor ecx,ecx
401f58: 89 74 24 d8 mov DWORD PTR [rsp-0x28],esi
401f5c: 31 d2 xor edx,edx
401f5e: eb 05 jmp 401f65
401f60: 0f b7 4c 04 d8 movzx ecx,WORD PTR [rsp+rax*1-0x28]
401f65: c1 ea 10 shr edx,0x10
401f68: 01 ca add edx,ecx
401f6a: 0f b7 0c 07 movzx ecx,WORD PTR [rdi+rax*1]
401f6e: 01 ca add edx,ecx
401f70: 66 89 14 07 mov WORD PTR [rdi+rax*1],dx
401f74: 48 83 c0 02 add rax,0x2
401f78: 48 83 f8 20 cmp rax,0x20
401f7c: 75 e2 jne 401f60
401f7e: f3 c3 repz ret
We can see that instruction at [401f60:] is skipped in 1st iteration.
[Bug tree-optimization/52870] ICE during SLP pattern matching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870 --- Comment #3 from Ulrich Weigand 2012-04-10 10:56:17 UTC --- Author: uweigand Date: Tue Apr 10 10:56:11 2012 New Revision: 186272 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186272 Log: gcc/ PR tree-optimization/52870 * tree-vect-patterns.c (vect_recog_widen_mult_pattern): Verify that presumed pattern statement is within the same loop or basic block. gcc/testsuite/ PR tree-optimization/52870 * gcc.dg/vect/pr52870.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr52870.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug tree-optimization/52870] ICE during SLP pattern matching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870 Ulrich Weigand changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Ulrich Weigand 2012-04-10 10:58:25 UTC --- Fixed.
[Bug libstdc++/52917] [DR 2048] explicitly stated return type in std::mem_fn cannot be compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
--- Comment #4 from Jonathan Wakely 2012-04-10
11:23:51 UTC ---
(In reply to comment #3)
> Ok, I didn't know about the defect report and resolution yet.
> I must admit that I quite like the syntax.
It's a peculiarity of the C++ grammar, the function parameter R T::*pm is a
pointer to member, with T deduced as X and R deduced as the function type
int&()
If it helps, consider that you can declare X::get() like this:
#include
struct X
{
int a;
typedef int& func_type();
func_type get;
};
int& X::get() { return a; }
And then you can use the typedef with mem_fn:
auto pm = std::mem_fn(&X::get);
> I added a remark about the defect and a short example to
> http://en.cppreference.com/w/cpp/utility/functional/mem_fn
N.B. That page has a heading "Execptions"
> And I noted that the most c++11-ish code would be anyway:
>
> auto y = [] (X& x) {return x.get();};
In most cases yes, but mem_fn has the advantage it always returns the same
type, whereas two lambda expressions produce two different closure types even
if the expressions are identical, and mem_fn might be easier to use in
late-specified return types.
[Bug middle-end/52881] [4.8 Regression] ICE due to null pointer deref in cfgloop.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52881 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-10 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-04-10 11:33:49 UTC --- Confirmed, mine.
[Bug middle-end/52886] [4.8 Regression] FAIL: gcc.dg/torture/pr36978.c -On (internal compiler error), n=1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52886 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-10 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-04-10 11:34:32 UTC --- Mine.
[Bug fortran/52921] With realloc-lhs: Conditional jump or move depends on uninitialised value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52921 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2012-04-10 CC||burnus at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Memory errors when compiled |With realloc-lhs: |with -fstrict-overflow flag |Conditional jump or move ||depends on uninitialised ||value --- Comment #1 from Tobias Burnus 2012-04-10 11:42:07 UTC --- I already get the valgrind warning Conditional jump or move depends on uninitialised value(s) for MY_ARR%ARR(I)%CMP = [1, 2] even without any optimization. (I replaced the READ by an assignment and marked "i" as VOLATILE.)
[Bug rtl-optimization/52888] Unable to inline function pointer call with inexact signature match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52888 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-10 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-04-10 11:49:14 UTC --- It's the pointer-to-member function descriptor that is rejected. The compatibility check is too constrained, I have a fix (for this particular case at least).
[Bug middle-end/52890] Revision 185336 causes 10% degradation on cpu2000 benchmark 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-10 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-04-10 12:06:26 UTC --- (gdb) prt to unit size align 8 symtab 0 alias set 2 canonical type 0xfffaff00f18 precision 64> I suppose SRA does this. Can you check with -fno-tree-sra? The code in SRA, which is /* If prev_base were always an originally performed access we can extract more optimistic alignment information by looking at the access mode. That would constrain the alignment of base + base_offset which we would need to adjust according to offset. */ align = get_pointer_alignment_1 (base, &misalign); if (misalign == 0 && (TREE_CODE (prev_base) == MEM_REF || TREE_CODE (prev_base) == TARGET_MEM_REF)) align = MAX (align, TYPE_ALIGN (TREE_TYPE (prev_base))); misalign += (double_int_sext (tree_to_double_int (off), TYPE_PRECISION (TREE_TYPE (off))).low * BITS_PER_UNIT); misalign = misalign & (align - 1); if (misalign != 0) align = (misalign & -misalign); if (align < TYPE_ALIGN (exp_type)) exp_type = build_aligned_type (exp_type, align); only looks at conservative alignment in this case (prev_base is not a base, but a COMPONENT_REF). I think martin has a patch to fix this.
[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52891 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-10 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|ICE in adjust_bool_pattern |[4.8 Regression] ICE in ||adjust_bool_pattern Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-04-10 12:08:01 UTC --- Confirmed.
[Bug middle-end/52894] [4.5,4.6,4.7 Regression] Stage1 bootstrap fails with gcc-4.6.3: Infinite loop in pointer_set_insert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52894 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.5.4
[Bug c++/52900] Compile source using Boost header with -static -flto -std=c++11 breaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52900 Richard Guenther changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-10 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther 2012-04-10 12:10:24 UTC --- Please attach preprocessed source.
[Bug c++/52906] [4.7/4.8 Regression] ICE: SIGSEGV in check_tag_decl (decl.c:4230) with "__attribute__ ((__deprecated__));" alone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52906 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.1
[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
Richard Guenther changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-04-10
CC||rguenth at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #4 from Richard Guenther 2012-04-10
12:16:54 UTC ---
It's the
if (nfds < 0)
conditional that we warn on. We cannot currently derive an upper bound
for nfds based on the number of iterations of the loop as it is not
an induction variable we can analyze.
int
wait_reading_process_output (void)
{
int nfds = 0;
int channel;
for (channel = 0; channel < 1024; ++channel)
{
if (foo (channel))
nfds++;
}
if (nfds < 0)
return 1;
This is in some way a missed optimization in value-range analysis as well.
[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 --- Comment #21 from Ulrich Weigand 2012-04-10 12:16:36 UTC --- (In reply to comment #19) > and the matching alternative would be (f, Q) with > > ;; Note that while this accepts mem, it only accepts non-volatile mem, > ;; and so cannot be "fixed" by adjusting the address. Thus it cannot > ;; and does not use define_memory_constraint. > (define_constraint "Q" > "Non-volatile memory for FP_REG loads/stores" > (and (match_operand 0 "memory_operand") >(match_test "!MEM_VOLATILE_P (op)"))) Ah, I see. So the fix would probably be to simply add an equivalent "if reload_in_progress, accept pseudos" (since pseudo stack slots are never volatile) to this constrains ...
[Bug tree-optimization/52907] Underflowing floating point expressions wrongly folded to zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52907 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-10 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-04-10 12:18:12 UTC --- Does real.c even communicate this fact?
[Bug target/52911] [4.5/4.6/4.7/4.8 Regression] gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911 Richard Guenther changed: What|Removed |Added Known to work||4.3.6 Target Milestone|--- |4.5.4 Summary|gcc 4.7.0 (ppc32 e500mc)|[4.5/4.6/4.7/4.8 |when compile a c file, |Regression] gcc 4.7.0 |after a lot of time, gcc|(ppc32 e500mc) when compile |failed and internal |a c file, after a lot of |compiler error occurs. |time, gcc failed and ||internal compiler error ||occurs.
[Bug tree-optimization/52912] [4.8 Regression] ICE: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52912 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-10 Component|c |tree-optimization AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Summary|ICE: verify_ssa failed |[4.8 Regression] ICE: ||verify_ssa failed Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-04-10 12:23:14 UTC --- Confirmed, mine. Possibly a dup of 52886.
[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52918 Richard Guenther changed: What|Removed |Added Component|c++ |target Target Milestone|--- |4.8.0 Summary|ICE: Invalid|[4.8 Regression] ICE: |bb->loop_father (NULL) in |Invalid bb->loop_father |add_bb_to_loop |(NULL) in add_bb_to_loop --- Comment #2 from Richard Guenther 2012-04-10 12:25:22 UTC --- The bug is that bb has no loop_father. Without preprocessed source I cannot verify with a cross compiler.
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 Richard Guenther changed: What|Removed |Added CC||garfieldsk at gmail dot com --- Comment #9 from Richard Guenther 2012-04-10 12:28:50 UTC --- *** Bug 52920 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/52920] function call optimized away with ftree-loop-distribute-patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52920 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther 2012-04-10 12:28:50 UTC --- . *** This bug has been marked as a duplicate of bug 52835 ***
[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52918 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-10 CC||ktietz at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Kai Tietz 2012-04-10 12:31:39 UTC --- I am on it. It is related to target's use of SjLj's exception, but target hook TARGET_EXCEPT_UNWIND_INFO isn't set and so DWARF2 is used. I am just about testing a patch for it.
[Bug c/52923] Warn if making external references to local stack memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923
Richard Guenther changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-04-10
Ever Confirmed|0 |1
--- Comment #3 from Richard Guenther 2012-04-10
12:33:38 UTC ---
We lack a must points-to analysis pass. But it's questionable to warn for
void* test_alloc_struct_ptr_to_stack_mem(void)
{
int a[100];
struct test* t = (struct test*)malloc(sizeof(struct test));
// GIVE WARNING?
// "function returns with reference to local variable?"
t->ptr = a;
return t;
}
as you have no idea whether t is actually dereferenced in the caller.
void* test_alloc_struct_on_stack_mem(void)
{
struct test* t = (struct test*)alloca(sizeof(struct test));
t->ptr = NULL;
// GIVE WARNING?
// "function returns allocation from stack memory?"
return t;
}
for this I'd say yes, warn. Similar for returning a pointer that was free()d.
[Bug c/52926] gcc 4.7.0 20120324: wrong optimized asm code produced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52926 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther 2012-04-10 12:35:05 UTC --- You are violating C aliasing rules. Use -fno-strict-aliasing.
[Bug c/52923] Warn if making external references to local stack memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923 --- Comment #4 from Fredrik Hederstierna 2012-04-10 12:52:36 UTC --- Maybe it have advantages to have a "pointer-deref" analysis pass rather than a "point-to" analysis pass. Then GCC could warn only if the pointer is being dereferenced for real, this to avoid false positives. But in case of shared library-code etc, I guess we never know what users/callers will do with the pointer... Could there possibly be a connection to the work I think maybe Jeff Law and others maybe are doing will null-deref checking pass? I guess they already do some flow analysis and then checking for null-deref rather than 'dangeling-mem-deref' in this case (eg. stack local mem, or free()d-mem). (I think this is done in PR16351.) I also seen the __attribute__((nonnull)) with -Wnonnull, could it be possible perhaps to have some __attribute__((nonlocal)) or similar when declaring pointer? /Fredrik
[Bug c++/52924] [4.7 Regression] Using an std::function object as deleter of shared_ptr in C++0x mode does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52924
--- Comment #3 from Jonathan Wakely 2012-04-10
12:55:40 UTC ---
another testcase showing a similar bug:
#include
template
struct Alloc : std::allocator
{
template struct rebind { typedef Alloc other; };
template Alloc(const Alloc&) { }
Alloc() = default;
~Alloc() noexcept(false) { }
};
Alloc alloc;
auto x = std::allocate_shared(alloc);
[Bug c/52927] New: "procps" do not work with -Os flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 Bug #: 52927 Summary: "procps" do not work with -Os flag. Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jonatan.goe...@digitel.com.br I imagine it's the same bug as I found here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621 but for another platform. This happens for the e500x2 core, using uClibc 0.9.32. The main difference, is that there is no segmentation fault, the software just stuck.
[Bug c/52927] "procps" do not work with -Os flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-10 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-04-10 13:13:33 UTC --- If it was the same then it would be fixed in gcc 4.1.2 and not present in gcc 4.5.3 But noone can tell if it's the same because you haven't provided any information at all about the problem.
[Bug middle-end/52888] Unable to inline function pointer call with inexact signature match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52888 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|rtl-optimization|middle-end Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Richard Guenther 2012-04-10 13:21:11 UTC --- Fixed for trunk.
[Bug rtl-optimization/52888] Unable to inline function pointer call with inexact signature match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52888 --- Comment #2 from Richard Guenther 2012-04-10 13:20:55 UTC --- Author: rguenth Date: Tue Apr 10 13:20:50 2012 New Revision: 186276 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186276 Log: 2012-04-10 Richard Guenther PR middle-end/52888 * gimple-low.c (gimple_check_call_args): Properly account for compatible aggregate types. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-low.c
[Bug target/52928] New: Alpha/VMS: c++ triggers gas errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52928 Bug #: 52928 Summary: Alpha/VMS: c++ triggers gas errors Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ging...@gcc.gnu.org While building libsupc++: .../libstdc++-v3/libsupc++/array_type_info.cc -o array_type_info.obj cc56SH6m.s: Assembler messages: cc56SH6m.s: Error: no entry symbol for global function '_ZN10__cxxabiv117__array_type_infoD1Ev' cc56SH6m.s: Fatal error: can't close array_type_info.obj: Section has no contents Looks like an hole in gas.
[Bug target/52928] Alpha/VMS: c++ triggers gas errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52928 ging...@gcc.gnu.org changed: What|Removed |Added Target||alpha64-dec-openvms Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-10 AssignedTo|unassigned at gcc dot |gingold at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug debug/52727] [4.7/4.8 Regression] internal compiler error at dwarf2cfi.c2:685
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52727 --- Comment #15 from Florian Fainelli 2012-04-10 13:39:26 UTC --- (In reply to comment #13) > Author: rth > Date: Fri Mar 30 18:00:37 2012 > New Revision: 186018 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186018 > Log: > PR debug/52727 > * combine-stack-adj.c (prev_active_insn_bb): New. > (next_active_insn_bb): New. > (force_move_args_size_note): New. > (combine_stack_adjustments_for_block): Use it. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/combine-stack-adj.c Works for me, thanks Richard!
[Bug target/52908] xop-mul-1:f9 miscompiled on bulldozer (-mxop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52908 --- Comment #3 from Uros Bizjak 2012-04-10 13:49:02 UTC --- (In reply to comment #2) > Created attachment 27117 [details] > Proposed patch Michael, can you please test this patch?
[Bug c/44005] gcc should implement __int64, so it can e.g. read the VMS system headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44005 ging...@gcc.gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gingold at gcc dot gnu.org Resolution||FIXED --- Comment #1 from gingold at gcc dot gnu.org 2012-04-10 13:51:12 UTC --- __int64 is now defined as long long.
[Bug other/44279] system.h calloc/malloc/realloc VMS size_t vs. __size_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44279 ging...@gcc.gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gingold at gcc dot gnu.org Resolution||FIXED --- Comment #1 from gingold at gcc dot gnu.org 2012-04-10 13:53:13 UTC --- GCC definition of size_t now matches DEC-C one.
[Bug target/44242] vms-crt0*.c should compile with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44242 ging...@gcc.gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gingold at gcc dot gnu.org Resolution||FIXED --- Comment #3 from gingold at gcc dot gnu.org 2012-04-10 13:54:40 UTC --- Fixed by the rework.
[Bug bootstrap/44000] gcc/resource.h conflicts with sysroot/usr/include/resource.h (alpha-dec-vms)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44000 ging...@gcc.gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gingold at gcc dot gnu.org Resolution||FIXED --- Comment #1 from gingold at gcc dot gnu.org 2012-04-10 13:55:20 UTC --- Fixed by fixinclude.
[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52891
John Regehr changed:
What|Removed |Added
CC||regehr at cs dot utah.edu
--- Comment #2 from John Regehr 2012-04-10 14:08:41
UTC ---
Another small testcase, if that's helpful.
[regehr@dyson r18]$ cat small.c
#pragma pack(1)
struct S2
{
unsigned f0:22;
};
struct
{
struct S2 f0;
} c;
int a, b, d;
void
fn1 ()
{
if (1 ? (!c.f0.f0 & d < 0) < a : 0)
b = 0;
}
[regehr@dyson r18]$ current-gcc -O3 -c small.c
small.c: In function 'fn1':
small.c:12:1: internal compiler error: in adjust_bool_pattern, at
tree-vect-patterns.c:2301
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r18]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186257-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186257-install
--program-prefix=r186257- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120410 (experimental) (GCC)
[Bug c/44003] gcc 4.5.0 stddef.h clobbers __size_t with #define, breaks VMS (code already avoids similar on FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44003 ging...@gcc.gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gingold at gcc dot gnu.org Resolution||FIXED --- Comment #2 from gingold at gcc dot gnu.org 2012-04-10 14:29:48 UTC --- Now fixed by change in stddef.h
[Bug translation/45116] config/ia64/vms_symvec_libgcc_s.opt not an options file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45116 ging...@gcc.gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gingold at gcc dot gnu.org Resolution||FIXED --- Comment #2 from gingold at gcc dot gnu.org 2012-04-10 14:47:00 UTC --- OBE as the file has been removed.
[Bug rtl-optimization/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #14 from H.J. Lu 2012-04-10 14:49:37 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00320.html
[Bug lto/52722] ICE in lto_output_varpool_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52722 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jan Hubicka 2012-04-10 15:07:57 UTC --- Both the testcase and make check works for me now.
[Bug lto/52634] multiple definition error when using alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634 --- Comment #9 from Jan Hubicka 2012-04-10 15:09:27 UTC --- Fixed on mainline, will backport the fix if no problems shows up.
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #19 from Alan Modra 2012-04-10 15:13:24
UTC ---
I think I was on the right track when I questioned whether the problem might be
mixing atomics and mutex protected ops, but was looking in the wrong place. I
should have looked at default_weaktoshared.o rather than libstdc++.so.
objdump -drS default_weaktoshared.o shows
[snip]
void* thread_hammer(void* opaque_weak)
{
0: 94 21 ff d0 stwur1,-48(r1)
static inline _Atomic_word
__attribute__ ((__unused__))
__exchange_and_add_dispatch(_Atomic_word* __mem, int __val)
{
#ifdef __GTHREADS
if (__gthread_active_p())
4: 3d 20 00 00 lis r9,0
6: R_PPC_ADDR16_HA pthread_cancel
8: 7d 80 00 26 mfcrr12
c: 7c 08 02 a6 mflrr0
10: 39 29 00 00 addir9,r9,0
12: R_PPC_ADDR16_LO pthread_cancel
14: 2e 09 00 00 cmpwi cr4,r9,0
18: 93 c1 00 28 stw r30,40(r1)
typedef typename __traits_type::pointer pointer;
_GLIBCXX_CONSTEXPR __normal_iterator() : _M_current(_Iterator()) { }
explicit
__normal_iterator(const _Iterator& __i) : _M_current(__i) { }
1c: 3f c0 00 01 lis r30,1
20: 90 01 00 34 stw r0,52(r1)
24: 93 81 00 20 stw r28,32(r1)
28: 93 a1 00 24 stw r29,36(r1)
2c: 93 e1 00 2c stw r31,44(r1)
30: 91 81 00 1c stw r12,28(r1)
34: 7c 7c 1b 78 mr r28,r3
38: 63 de 86 a0 ori r30,r30,34464
3c: 83 a3 00 00 lwz r29,0(r3)
40: 48 00 00 18 b 58 <_Z13thread_hammerPv+0x58>
44: 60 00 00 00 nop
48: 60 00 00 00 nop
4c: 60 00 00 00 nop
0x9908b0dful, 11, 7,
0x9d2c5680ul, 15,
0xefc6ul, 18> rng;
wp_vector_t::iterator cur_weak = weak_pool.begin();
for (unsigned int i = 0; i < HAMMER_REPEAT; ++i)
50: 37 de ff ff addic. r30,r30,-1
54: 41 82 00 ac beq-100 <_Z13thread_hammerPv+0x100>
// now that __weak_count is defined we can define this constructor:
template<_Lock_policy _Lp>
inline
__shared_count<_Lp>::
__shared_count(const __weak_count<_Lp>& __r)
: _M_pi(__r._M_pi)
58: 83 fd 00 04 lwz r31,4(r29)
{
if (_M_pi != 0)
5c: 2f 9f 00 00 cmpwi cr7,r31,0
60: 41 9e 00 cc beq-cr7,12c <_Z13thread_hammerPv+0x12c>
inline void
_Sp_counted_base<_S_atomic>::
_M_add_ref_lock()
{
// Perform lock-free add-if-not-zero operation.
_Atomic_word __count = _M_use_count;
64: 81 3f 00 04 lwz r9,4(r31)
68: 91 21 00 08 stw r9,8(r1)
do
{
if (__count == 0)
6c: 2f 89 00 00 cmpwi cr7,r9,0
70: 41 9e 00 d8 beq-cr7,148 <_Z13thread_hammerPv+0x148>
// Replace the current counter value with the old value + 1, as
// long as it's not changed meanwhile.
}
while (!__atomic_compare_exchange_n(&_M_use_count, &__count, __count + 1,
true, __ATOMIC_ACQ_REL,
__ATOMIC_RELAXED));
74: 81 01 00 08 lwz r8,8(r1)
78: 39 29 00 01 addir9,r9,1
7c: 38 7f 00 04 addir3,r31,4
80: 7c 20 04 ac lwsync
84: 7d 40 18 28 lwarx r10,0,r3
88: 7c 0a 40 00 cmpwr10,r8
8c: 40 82 00 0c bne-98 <_Z13thread_hammerPv+0x98>
90: 7d 20 19 2d stwcx. r9,0,r3
94: 4c 00 01 2c isync
98: 91 41 00 08 stw r10,8(r1)
_Sp_counted_base<_S_atomic>::
_M_add_ref_lock()
{
// Perform lock-free add-if-not-zero operation.
_Atomic_word __count = _M_use_count;
do
9c: 40 82 00 a4 bne-140 <_Z13thread_hammerPv+0x140>
a0: 41 92 00 ac beq-cr4,14c <_Z13thread_hammerPv+0x14c>
return __exchange_and_add(__mem, __val);
a4: 38 80 ff ff li r4,-1
a8: 48 00 00 01 bl a8 <_Z13thread_hammerPv+0xa8>
a8: R_PPC_REL24 _ZN9__gnu_cxx18__exchange_and_addEPVii
void
_M_release() // nothrow
{
// Be race-detector-friendly. For more info see bits/c++config.
_GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&_M_use_count);
if (__gnu_cxx::__exchange_and_add_dispatch(&_M_use_count, -1) == 1)
ac: 2f 83 00 01 cmpwi cr7,r3,1
b0: 40 9e ff a0 bne+cr7,50 <_Z13thread_hammerPv+0x50>
{
_GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(&_M_use_count);
_M_dispose();
b4: 81 3f 00 00 lwz r9,0(r31)
b8: 7f e3 fb 78 mr r3,r31
bc: 81 29 00 08 lwz r9,8(r9)
c0: 7d 29 03 a6 mtctr r9
c4: 4e 80 04 21 bctrl
_GLIBCXX_WRITE_MEM_BARRIER;
That certainly looks like _M_use_count is fiddled with both by atomics and
__exchange_and_add with pthread mutex.
[Bug c/52927] "procps" do not work with -Os flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 --- Comment #2 from Jonatan GOebel 2012-04-10 15:14:53 UTC --- The ps code calls the funcion "set_personality()" This function ends with a "goto *(found->jump);" this goto jump to " case_unknown:" do some stuffs and returns NULL. And the program stuck, he probably returned to somewhere else.
[Bug fortran/52473] CSHIFT slow - inline it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52473 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-04-10 15:22:30 UTC --- Cf. also http://gcc.gnu.org/ml/fortran/2012-04/msg00041.html
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #7 from Laurent Aflonsi 2012-04-10
15:28:07 UTC ---
Ping ? Here is the patch proposed.
--- libstdc++-v3/src/mt_allocator.cc2011/08/04 07:56:492064
+++ libstdc++-v3/src/mt_allocator.cc2012/04/03 08:45:482551
@@ -47,7 +47,9 @@
if (_M_thread_freelist_array)
{
__gthread_key_delete(_M_key);
+ _M_key = NULL;
::operator delete(static_cast(_M_thread_freelist_array));
+ _M_thread_freelist = NULL;
}
}
};
@@ -639,7 +641,10 @@
}
}
-__gthread_setspecific(freelist._M_key, (void*)_M_id);
+if (freelist._M_key)
+ {
+__gthread_setspecific(freelist._M_key, (void*)_M_id);
+ }
}
return _M_id >= _M_options._M_max_threads ? 0 : _M_id;
}
=
[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 --- Comment #22 from Eric Botcazou 2012-04-10 15:29:46 UTC --- > > ;; Note that while this accepts mem, it only accepts non-volatile mem, > > ;; and so cannot be "fixed" by adjusting the address. Thus it cannot > > ;; and does not use define_memory_constraint. > > (define_constraint "Q" > > "Non-volatile memory for FP_REG loads/stores" > > (and (match_operand 0 "memory_operand") > >(match_test "!MEM_VOLATILE_P (op)"))) > > Ah, I see. So the fix would probably be to simply add an equivalent "if > reload_in_progress, accept pseudos" (since pseudo stack slots are never > volatile) to this constrains ... Quite ugly, but probably the most reasonable approach. While we are at it, do you have an opinion as to how we should fix the MEM_VOLATILE_P problem? It turns out that memory_operand doesn't accept only MEMs, but also SUBREGs of MEMs, and it is therefore invalid to directly access MEM_VOLATILE_P. I'm going to test the obvious restriction in any case.
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #20 from Jonathan Wakely 2012-04-10
15:36:40 UTC ---
You're quite right, my apologies for telling you that wouldn't happen.
In bits/shared_ptr_base.h we have:
template<>
inline void
_Sp_counted_base<_S_atomic>::
_M_add_ref_lock()
{
// Perform lock-free add-if-not-zero operation.
_Atomic_word __count = _M_use_count;
do
{
if (__count == 0)
__throw_bad_weak_ptr();
// Replace the current counter value with the old value + 1, as
// long as it's not changed meanwhile.
}
while (!__atomic_compare_exchange_n(&_M_use_count, &__count, __count + 1,
true, __ATOMIC_ACQ_REL,
__ATOMIC_RELAXED));
}
This will always be atomic if __default_lock_policy is _S_atomic
The problem is in ext/concurrence.h:
// Compile time constant that indicates prefered locking policy in
// the current configuration.
static const _Lock_policy __default_lock_policy =
#ifdef __GTHREADS
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
&& defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
_S_atomic;
#else
_S_mutex;
#endif
#else
_S_single;
#endif
This is inconsistent with the definition of _GLIBCXX_ATOMIC_BUILTINS and means
that on power shared_ptr thinks it can use atomics, but the "dispatch"
functions in ext/atomicity.h don't use atomics.
__default_lock_policy should not say to use atomics if the dispatch functions
don't use atomics.
A quick fix would be to only set __default_lock_policy=_S_atomic if
_GLIBCXX_ATOMIC_BUILTINS is also defined
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |4.7.1 --- Comment #21 from Jonathan Wakely 2012-04-10 15:58:35 UTC --- In brief: in ext/concurrence.h we set __default_lock_policy to _S_atomic if we have 2-byte and 4-byte CAS, which is true for powerpc. but in ext/atomicity.h we fallback to a mutex unless we have 2-byte, 4-byte *and* 8-byte CAS, and there is no 8-byte CAS on powerpc. The fix isn't so brief: Ideally the ext/atomicity.h code should not require 8-byte CAS. If we had a _GLIBCXX_ATOMIC_BUILTINS_WORD that indicated atomics work for 'int' then we could use that in both ext/atomicity.h and ext/concurrence.h and then they'd be consistent, ensuring we don't mix atomics with mutexes ... *but* then powerpc would stop using a mutex to implement refcounts in libstdc++ and because those functions are inlined that would prevent mixing code built with old and new libstdc++ which is not acceptable. So I think the right fix is to set __default_lock_policy = _S_mutex when we don't have 8-byte CAS, i.e. make it also depend on _GLIBCXX_ATOMIC_BUILTINS. We could potentially add a --enable-libstdcxx-atomic-word switch that would change the ABI so powerpc could use atomic builtins for refcounts, then make that the default when we change the libstdc++ SONAME.
[Bug middle-end/52890] Revision 185336 causes 10% degradation on cpu2000 benchmark 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890 Pat Haugen changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #3 from Pat Haugen 2012-04-10 16:13:49 UTC --- (In reply to comment #2) > (gdb) prt to > type size > unit size > align 8 symtab 0 alias set 2 canonical type 0xfffaff00f18 precision > 64> > > I suppose SRA does this. Can you check with -fno-tree-sra? With -fno-tree-sra they both generate the same code, a sequence of 8-byte stores to build up the rhs, and then a call to memcpy for the entire structure copy. At expand phase we now have: struct ggVector3 D.2563; struct ggVector3 D.2562; struct ggVector3 D.2561; struct ggONB3 D.2573; # BLOCK 2 freq:1 # PRED: ENTRY [100.0%] (fallthru,exec) D.2561.e[0] = 1.0e+0; D.2561.e[1] = 0.0; D.2561.e[2] = 0.0; D.2562.e[0] = 0.0; D.2562.e[1] = 0.0; D.2562.e[2] = -1.0e+0; D.2563.e[0] = 0.0; D.2563.e[1] = 1.0e+0; D.2563.e[2] = 0.0; D.2573.U = D.2561; D.2573.V = D.2562; D.2573.W = D.2563; VHR_1(D)->UVW = D.2573; Whereas with SRA we had: MEM[(struct mrViewingHitRecord &)VHR_1(D)] = 1.0e+0; MEM[(struct mrViewingHitRecord &)VHR_1(D) + 8] = 0.0; MEM[(struct mrViewingHitRecord &)VHR_1(D) + 16] = 0.0; MEM[(struct mrViewingHitRecord &)VHR_1(D) + 24] = 0.0; MEM[(struct mrViewingHitRecord &)VHR_1(D) + 32] = 0.0; MEM[(struct mrViewingHitRecord &)VHR_1(D) + 40] = -1.0e+0; MEM[(struct mrViewingHitRecord &)VHR_1(D) + 48] = 0.0; MEM[(struct mrViewingHitRecord &)VHR_1(D) + 56] = 1.0e+0; MEM[(struct mrViewingHitRecord &)VHR_1(D) + 64] = 0.0;
[Bug libstdc++/52476] [DR 518] Unordered multimap reorders equivalent elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52476 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Paolo Carlini 2012-04-10 16:55:04 UTC --- Fixed for 4.7.1.
[Bug c++/52924] [4.7 Regression] Using an std::function object as deleter of shared_ptr in C++0x mode does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52924 Paolo Carlini changed: What|Removed |Added CC|jpr at essi dot fr | --- Comment #4 from Paolo Carlini 2012-04-10 17:03:55 UTC --- Thanks for handling this, Jon. I would recommend adding the testcase to mainline too.
[Bug tree-optimization/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #14 from Aldy Hernandez 2012-04-10 17:07:22 UTC --- Richard G., or perhaps another aliasing expert. I am working on a patch for this problem. Could you pontificate as to why no optimization pass has been able to figure out that g_2_lsm.6_12 == g_2 below? # VUSE <.MEM_9(D)> g_2_lsm.6_12 = g_2;<-- g_2_lsm set to g_2 if (pretmp.4_1 != 0) goto ; else goto ; : # VUSE <.MEM_9(D)> D.1883_17 = g_2; if (g_2_lsm.6_12 != D.1883_17)<-- g_2_lsm compared with g_2 goto ; Why can't anyone figure out that g_2_lsm is g_2? Am I building the conditions and stores incorrectly, is there a missing annotation, or is something else amok here? Thanks.
[Bug middle-end/52890] Revision 185336 causes 10% degradation on cpu2000 benchmark 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890 Pat Haugen changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
[Bug c/52927] "procps" do not work with -Os flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 --- Comment #3 from Uros Bizjak 2012-04-10 17:52:52 UTC --- (In reply to comment #2) Please follow instructions at http://gcc.gnu.org/bugs/#report on how to provide all required information.
[Bug c/52927] "procps" do not work with -Os flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 --- Comment #4 from Jonatan GOebel 2012-04-10 18:15:58 UTC --- Created attachment 27125 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27125 S file compiled with -Os flag
[Bug c/52927] "procps" do not work with -Os flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 --- Comment #5 from Jonatan GOebel 2012-04-10 18:16:36 UTC --- Created attachment 27126 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27126 S file compiled without -Os flag
[Bug c/52927] "procps" do not work with -Os flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 --- Comment #6 from Jonatan GOebel 2012-04-10 18:17:39 UTC --- Created attachment 27127 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27127 compiled sorce file.
[Bug c/52927] "procps" do not work with -Os flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 --- Comment #7 from Jonatan GOebel 2012-04-10 18:24:55 UTC --- props project: http://procps.sourceforge.net/index.html Hi, I attached the i and the S files from the source code that causes the program to stuck. And this is the only warning in this source. In file included from ps/../proc/escape.h:7:0, from ps/common.h:16, from ps/global.c:24: ps/../proc/readproc.h:76:2: warning: padding struct to align 'start_code' the full command line is: powerpc-e500v2-linux-uclibcspe-gcc -c -D_GNU_SOURCE -I proc -fno-common -ffast-math -W -Wall -Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Os -save-temps -Wdeclaration-after-statement -Wpadded -Wstrict-aliasing -fweb -frename-registers -fomit-frame-pointer -fno-inline-functions ps/global.c -o ps/global.o
[Bug c++/52929] New: use of undeclared identifier '__ATOMIC_ACQ_REL'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52929
Bug #: 52929
Summary: use of undeclared identifier '__ATOMIC_ACQ_REL'
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o...@xeviox.com
The error occurs on Archlinux x64 with everything updated.
The project uses Qt 4.8.x which was installed using the package manager. I also
tried compiling with clang, which came up with the same error.
The following error breaks the compile:
In file included from /usr/include/QtCore/qstring.h:54:
In file included from
/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/string:53:
In file included from
/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/basic_string.h:40:
/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:48:45:
error:
use of undeclared identifier '__ATOMIC_ACQ_REL'
{ return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
^
/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:52:38:
error:
use of undeclared identifier '__ATOMIC_ACQ_REL'
{ __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
^
2 errors generated.
make[1]: *** [../bin/debug/obj/main.o] Error 1
make[1]: Leaving directory `/tmp/qirk/src'
make: *** [sub-src-make_default-ordered] Error 2
I also tried to find the define using grep:
# grep -r __ATOMIC_ACQ_REL /usr/include/
/usr/include/c++/4.7.0/bits/shared_ptr_base.h: true,
__ATOMIC_ACQ_REL,
/usr/include/c++/4.7.0/ext/atomicity.h: { return __atomic_fetch_add(__mem,
__val, __ATOMIC_ACQ_REL); }
/usr/include/c++/4.7.0/ext/atomicity.h: { __atomic_fetch_add(__mem, __val,
__ATOMIC_ACQ_REL); }
/usr/include/c++/4.7.0/profile/impl/profiler_state.h:
&inv, __s, false, __ATOMIC_ACQ_REL,
/usr/include/c++/4.7.0/parallel/compatibility.h:return
__atomic_fetch_add(__ptr, __addend, __ATOMIC_ACQ_REL);
/usr/include/c++/4.7.0/parallel/compatibility.h:return
__atomic_fetch_add(__ptr, __addend, __ATOMIC_ACQ_REL);
/usr/include/c++/4.7.0/parallel/compatibility.h:return
__atomic_fetch_add(__ptr, __addend, __ATOMIC_ACQ_REL);
/usr/include/c++/4.7.0/parallel/compatibility.h: false,
__ATOMIC_ACQ_REL,
/usr/include/c++/4.7.0/parallel/compatibility.h: false,
__ATOMIC_ACQ_REL,
/usr/include/c++/4.7.0/parallel/compatibility.h: false,
__ATOMIC_ACQ_REL,
/usr/include/c++/4.7.0/tr1/shared_ptr.h: true,
__ATOMIC_ACQ_REL,
Greetings
Ben
[Bug c++/52929] use of undeclared identifier '__ATOMIC_ACQ_REL'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52929 ncahill_alt at yahoo dot com changed: What|Removed |Added CC||ncahill_alt at yahoo dot ||com --- Comment #1 from ncahill_alt at yahoo dot com 2012-04-10 18:54:51 UTC --- Regarding this, I've found that __ATOMIC_ACQ_REL is new in 4.7.0, it is not used in any 4.6.x. And also my source-built 4.7.0 is lacking a #define for this macro. Neil.
[Bug c++/52929] use of undeclared identifier '__ATOMIC_ACQ_REL'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52929 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Andrew Macleod 2012-04-10 20:18:01 UTC --- It is built in to the C preprocessor as a predefined value in GCC 4.7 (see cppbuiltin.c), so you wouldn't find a specific #define anywhere. The __atomic built-ins don't work properly without at least a GCC 4.7 compiler, so you wouldn't be able to compile them properly with a different compiler.
[Bug c++/52900] Compile source using Boost header with -static -flto -std=c++11 breaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52900 --- Comment #4 from gccBugs at haatschii dot de 2012-04-10 20:37:36 UTC --- To large to attach it directly: http://haatschii.de/preprocessed_source.cpp
[Bug c++/52929] use of undeclared identifier '__ATOMIC_ACQ_REL'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52929 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-10 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely 2012-04-10 20:53:36 UTC --- Please read http://gcc.gnu.org/bugs/ and provide the requested information. Tell us what "gcc -v" shows, attach preprocessed source etc.
[Bug c/52927] "procps" do not work with -Os flag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #8 from Jonathan Wakely 2012-04-10 20:57:06 UTC --- Thank you for the additional details.
[Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366 Andrew Benson changed: What|Removed |Added CC||abenson at caltech dot edu --- Comment #16 from Andrew Benson 2012-04-10 21:06:13 UTC --- The following compiles with "-std=f2003" and runs successfully (using gfortran 4.8 r186145) with the "a=b" line in, but if I switch it for the "a%d=b%d" line I get a "Variable must not be polymorphic in intrinsic assignment at (1) - check that there is a matching specific subroutine for '=' operator" error: module testMod implicit none public t type t integer :: i end type t type c class(t), allocatable :: d end type c end module testMod program testProg use testMod implicit none type(t) :: f type(c) :: a,b allocate(b%d,source=f) b%d%i=12345 a=b !! THIS COMPILES OK ! a%d=b%d !! THIS DOES NOT write (0,*) a%d%i write (0,*) b%d%i end program testProg Since "d" is polymorphic both should be disallowed with "-std=f2003" (and both allowed under F2008 I think).
[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52918 --- Comment #4 from B. Scott Michel 2012-04-10 21:28:25 UTC --- Created attachment 27128 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27128 Preprocessed eh_alloc.cc, for reference Per request, preprocessed source attached.
[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52918 --- Comment #5 from B. Scott Michel 2012-04-10 21:31:13 UTC --- I deduced that add_bb_to_loop and a null bb->loop_father meant that the enclosing basic block was either missing or incorrectly annotated. The fix, however, is not obvious without getting heavily involved in gcc development. Preprocessed source uploaded for additional insight.
[Bug middle-end/52894] [4.5,4.6,4.7 Regression] Stage1 bootstrap fails with gcc-4.6.3: Infinite loop in pointer_set_insert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52894 --- Comment #6 from John David Anglin 2012-04-10 22:11:45 UTC --- Author: danglin Date: Tue Apr 10 22:11:38 2012 New Revision: 186296 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186296 Log: PR middle-end/52894 * varasm.c (process_pending_assemble_externals): Set pending_assemble_externals_processed true. (assemble_external): Call assemble_external_real if the pending assemble externals have been processed. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/varasm.c
[Bug middle-end/52894] [4.5,4.6,4.7 Regression] Stage1 bootstrap fails with gcc-4.6.3: Infinite loop in pointer_set_insert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52894 --- Comment #7 from John David Anglin 2012-04-10 22:13:56 UTC --- Author: danglin Date: Tue Apr 10 22:13:52 2012 New Revision: 186297 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186297 Log: PR middle-end/52894 * varasm.c (process_pending_assemble_externals): Set pending_assemble_externals_processed true. (assemble_external): Call assemble_external_real if the pending assemble externals have been processed. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/varasm.c
[Bug other/52930] New: quadmath: missing logbq, modfq, nexttowardq, exp2q
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52930 Bug #: 52930 Summary: quadmath: missing logbq, modfq, nexttowardq, exp2q Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: tyde...@tybor.com Either the header is missing the prototypes, and/or the library -lquadmath is missing the functions listed in the summary. These problems were found in a C99 program using 4.6.3-2 of float128 in Linux Fedora Core 16 on an Intel Core 2 CPU. Also, FLT128_DENORM_MIN should be renamed to FLT128_TRUE_MIN to match C11. Also, #define FLT128_DECIMAL_DIG 36 should be added to match C11. Also, #define FLT128_HAS_SUBNORM 1 should be added to match C11. It would be nice if supported all four floating-point types; float, double, long double, __float128. It would be nice if isnan(), isinf(), ... supported all four floating-point types. It appears that the 113/128 quad is converted to 64/80 long double when any of the quad functions are called. For example, fabsq(1.0Q - FLT128_EPSILON) returns 1.0Q
[Bug tree-optimization/52734] [4.7/4.8 Regression] Incorrect optimization of uClibc sbrk()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52734 joerg.jungermann at gmx dot de changed: What|Removed |Added CC||joerg.jungermann at gmx dot ||de --- Comment #12 from joerg.jungermann at gmx dot de 2012-04-10 22:40:41 UTC --- We at Freetz[1] had serveral problems compiling a running uclibc 0.9.3[23] with gcc 4.7.0. -fno-tree-tail-merge did fix this, so I applied the patch from #c10. [1] http://freetz.org/ticket/1752
[Bug tree-optimization/52734] [4.7/4.8 Regression] Incorrect optimization of uClibc sbrk()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52734 --- Comment #13 from Sedat Dilek 2012-04-10 22:57:15 UTC --- Just some remarks: Freetz is an OSS project supporting router (platforms) of a popular German company. The target-system is mostly MIPS(EL). The majority of our developers build on AMD64 hosts (32bit-toolchain). The full patchset for gcc-4.7.0 can be found in [1]. Jörg provided his adapted/backported patch in [2]. Thank you for testing! [0] http://freetz.org/ [1] http://freetz.org/browser/trunk/toolchain/make/target/gcc/4.7.0/ [2] http://freetz.org/attachment/ticket/1752/r8889-gcc-4.7-fix.patch
[Bug c++/52922] failed to build gcc 4.7 on SL6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922 --- Comment #7 from scott at smedleyfamily dot net 2012-04-10 23:19:58 UTC --- Thanks Jonathan, > No, in general you can't use GCC built for one target on a different target. I realise this is off-topic but I would love to know: what is causing this limitation? I thought by building gcc on the "oldest" architecture I could expect ABI backward-compatibility on the "newer" architectures. Thanks for your help. Scott.
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957 m...@gcc.gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #20 from mrs at gcc dot gnu.org 2012-04-10 23:22:40 UTC --- This testcase doesn't unroll for me without -funroll-all-loops. Any downside to using -funroll-all-loops over -funroll-loops?
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 Alan Modra changed: What|Removed |Added Target Milestone|4.7.1 |--- --- Comment #22 from Alan Modra 2012-04-10 23:53:16 UTC --- Regarding the ABI change, would I be correct to say that the ABI was broken for powerpc by 2012-02-10 Benjamin Kosnik Jonathan Wakely since that particular patch introduced the dependency on having long long atomics? If I understand correctly, before that change code would use sync builtins on powerpc throughout. So code compiled before that date won't behave correctly using a current libstdc++.so, which now uses mutexes. I'm not trying to apportion blame, just pointing out that making libstdc++ use atomics on powerpc *fixes* an ABI breakage for the great majority of cases.
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #23 from Jonathan Wakely 2012-04-11 00:30:46 UTC --- I hadn't got as far as tracking down when it changed - if you're right that would be quite nice and we'll be able to fix it properly.
[Bug c++/52922] failed to build gcc 4.7 on SL6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922 --- Comment #8 from Jonathan Wakely 2012-04-11 00:49:39 UTC --- (In reply to comment #7) > I realise this is off-topic but I would love to know: what is causing this > limitation? GCC's "fixincludes" mechanism, which installs modified versions of system headers alongside GCC's own headers, earlier in the include path. The installed "fixed" features.h header is based on a copy of that header from glibc 2.5 (or whatever old version it is that SL5 uses) and that is incompatible with glibc 2.12 (or whatever it is SL6 uses). IIRC in glibc 2.5 the xlocale features were GNU extensions, so only enabled by _GNU_SOURCE. The xlocale features were later added to POSIX 2008, so glibc 2.12 doesn't consider them to be GNU extensions and enables them when _XOPEN_SOURCE >= 700. The glibc 2.5 features.h defines _XOPEN_SOURCE=600 (i.e. POSIX 2001) when _GNU_SOURCE is defined, because that's the latest POSIX spec that existed when glibc 2.5 was released. So the "fixed" features.h installed with the old GCC doesn't know about POSIX 2008 and doesn't set the required _XOPEN_SOURCE=700 value, so the __locale_t type is not declared by /usr/include/xlocale.h. (That's all from memory, you should be able to diff SL6's /usr/include/features.h with the header found under the GCC installation dir to confirm it.) > I thought by building gcc on the "oldest" architecture I could expect ABI > backward-compatibility on the "newer" architectures. If you use that GCC and actually build *on* the oldest system, yes, the binaries produced will run on the newer system too. But you cannot move that GCC you built to the newer system and expect it to still work. You can't expect the compiler to even work, let alone produce binaries that will run on the old systems. Building on the newer arch will create dependencies on the newer glibc and other system libs. There is far more to ABI compatibility than just the compiler used.
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 Jonathan Wakely changed: What|Removed |Added CC||bkoz at gcc dot gnu.org --- Comment #24 from Jonathan Wakely 2012-04-11 00:58:17 UTC --- Benjamin, it seems that the patch for PR 51798 caused this regression and ABI-incompatible change on 32-bit power, so that the functions in ext/atomicity.h now use a mutex where they previously used atomic builtins. What's the reason for requiring 8-byte compare-and-swap for _GLIBCXX_ATOMIC_BUILTINS to be defined?
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #8 from Paolo Carlini 2012-04-11 01:08:12 UTC --- Note, stylistically, no curly brackets in the if body, and also no NULL, just 0 in C++98. I also note that you are not patching mainline, all the fixes go to mainline first. Finally, more substantively, how did you test the patch? Running make check-performance exercises mt_allocator quite a bit, for example. Are all the leaks / crashes gone with the patch?
