[Bug rtl-optimization/54783] [4.8 Regression] valgrind reports using uninitialised data in mark_pseudo_regno_live and make_object_born on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54783 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-03 06:34:18 UTC --- Not a bug, probably. Valgrind ought to be used only when --enable-checking=valgrind. Otherwise we have to live with those sparseset warnings, as those valgrind markups aren't compiled in. The thing is in gcc-4.7 sparseset_alloc we have: /* We use xcalloc rather than xmalloc to silence some valgrind uninitialized read errors when accessing set-sparse[n] when n is not, and never has been, in the set. These uninitialized reads are expected, by design and harmless. If this turns into a performance problem due to some future additional users of sparseset, we can revisit this decision. */ sparseset set = (sparseset) xcalloc (1, n_bytes); But in trunk sparseset_alloc there's: sparseset set = XNEWVAR(struct sparseset_def, n_bytes); /* Mark the sparseset as defined to silence some valgrind uninitialized read errors when accessing set-sparse[n] when n is not, and never has been, in the set. These uninitialized reads are expected, by design and harmless. */ VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (set, n_bytes));
[Bug rtl-optimization/54783] [4.8 Regression] valgrind reports using uninitialised data in mark_pseudo_regno_live and make_object_born on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54783 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 06:54:22 UTC --- Alternative would be to check for valgrind devel headers always, tweak the existing VALGRIND* macros used in gcc sources such that it would be only used if ENABLE_VALGRIND_CHECKING (otherwise expand to nothing) and in sparseset for hosts that have valgrind support, but no valgrind devel headers, fall back to XCNEWVEC, otherwise if valgrind devel headers are available, use the valgrind special insn even without --enable-checking=valgrind.
[Bug lto/54790] New: [4.8 Regression] Missing optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54790 Bug #: 54790 Summary: [4.8 Regression] Missing optimization with LTO Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 28337 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28337 Testcase GCC 20120916 (r191367) - ok, 20120923 (r191654) - bug. $ gcc -O2 -flto pr54790.c /tmp/ccTyOv2G.ltrans0.ltrans.o:ccTyOv2G.ltrans0.o:function foo: error: undefined reference to 'link_error' collect2: error: ld returned 1 exit status
[Bug fortran/54788] ICE on pointer-array element assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-10-03 07:32:43 UTC --- (In reply to comment #1) I think both programs are invalid and should be rejected. I concur. (In reply to comment #0) vec(1) = vec(0) 1 Error: Expected bounds specification for 'vec' at (1) R733 pointer-assignment-stmt is data-pointer-object [ (bounds-spec-list) ] = data-target or data-pointer-object (bounds-remapping-list ) = data-target or proc-pointer-object = proc-target with bounds-specis lower-bound-expr : bounds-remapping is lower-bound-expr : upper-bound-expr C716 (R733) If bounds-spec-list is specified, the number of bounds-specs shall equal the rank of data-pointer-object. C717 (R733) If bounds-remapping-list is specified, the number of bounds- remappings shall equal the rank of data-pointer-object. Thus, if you want to do bounds remapping, you have to specify a range, e.g. vec(1:1) = vec(0:0) integer, pointer :: a(:) integer :: b a(0:0) = b That violates C717 as the LHS is rank 1 and the RHS is scalar. But it shouldn't give an ICE.
[Bug c++/54780] G++ does not find precompiled headers in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54780 --- Comment #3 from jpakkane at gmail dot com 2012-10-03 07:53:59 UTC --- Thanks for the explanation and workaround. I guess this is not a big issue if you are using Autotools, where the established practice is to compile inside the source directory. It might cause a lot of head scratching for users of other build systems or those few autotools users that use a dedicated build directory.
[Bug middle-end/54782] [4.8 Regression] ICE: in change_scope, at final.c:1543 with -O -ffast-math -ftree-parallelize-loops=2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54782 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-03 CC||dehao at google dot com, ||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-03 07:58:48 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revisionamp;revision=191494
[Bug lto/54790] [4.8 Regression] Missing optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54790 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-10-03 08:11:17 UTC --- Started with r191466 (Honza's LTO symtab rework).
[Bug c++/54780] G++ does not find precompiled headers in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54780 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-03 09:00:05 UTC --- I think the majority don't use PCH anyway.
[Bug fortran/54788] ICE on pointer-array element assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-10-03 09:14:26 UTC --- (In reply to comment #0) allocate(vec(2)) allocate(vec(0)%arr(4,4)) I assume you have a C background. In Fortran, by default the lower array bound is one. Thus, with allocate(vec(2)) you allocated an array of size 2, which can be accessed via vec(1) and vec(2). Thus, you access invalid memory for vec(0). However, you can also allocate via allocate(vec(0:2)) then you have a size-3 array, where vec(0), vec(1) and vec(2) are valid. (you could also have negative bounds, e.g. allocate(vec(-2:0)).) The other point is, as Janus already mentioned: Fortran only has pointers to arrays but not an array of pointers. Thus vec(1) and vec(2) point to the same array, one to the first element and one to the second element. In terms of the standard, allocate(vec(2)) allocates an anonymous target (a rank-1, size-2 array) and then pointer assigns that target to the (scalar) pointer vec. Thus vec is a pointer to a size-2 array with the lower bound 1 and upper bound 2. (In reply to comment #2) Thus, if you want to do bounds remapping, you have to specify a range, e.g. vec(1:1) = vec(0:0) Remark to my example: While it is syntactically correct, accessing vec(0:0) isn't (out of bounds). It were okay for allocate(vec(0:2)) - but still, it wouldn't do what you expect: vec(1) would then point to the first element of the array, vec(2) would be in principle the second element (and in practice accessible), but but one may not use it: In vec(1:1) = one has explicitly told the compiler that one only wants to point to a size-1 array.
[Bug c++/54791] New: AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791
Bug #: 54791
Summary: AIX-only: Constructors are not called in main program.
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adivilce...@yahoo.com
I work on a very big project on AIX 6.1(TL5 SP7). I migrated from xlC to
gcc(v4.7.2). I have the problem that constructors of a global objects defined
almost anywhere are not called. After searching a lot on this I saw this could
be if the objects are in libs(static or shared) and not referenced. This is not
my case because my global object is defined in the main source file(where main
is defined) and they are referenced.
I try to isolate the problem so I removed all the code from my main source file
and just let the following code:
#include mybigtreeofconfidentialheaders.h
class Adiv{
public:
Adiv(char in_name[])
{
printf(Adiv()=%s\n,in_name);
strcpy(name,in_name);
}
~Adiv()
{
printf(~Adiv()=%s\n,name);
}
void f()
{
printf(f()name=%s\n,name);
}
char name[32];
int x;
};
Adiv a(a);
static Adiv b(b);
int main()
{
static Adiv c(c);
a.f();
b.f();
c.f();
return 0;
}
After building and executing I get the following output:
Adiv()=c
f()name=
f()name=
f()name=c
~Adiv()=c
Now, if I remove the #include mybigtreeofconfidentialheaders.h then I get the
correct output:
Adiv()=a
Adiv()=b
Adiv()=c
f()name=a
f()name=b
f()name=c
~Adiv()=c
~Adiv()=b
~Adiv()=a
The line I use to compile is:
g++ -c -w -fno-strict-aliasing -fpermissive -save-temps -DMYCUSTOM_DEFINES
-DIALL_CHECKS -D_AIX_PTHREADS_D7 -Imy_custom_includes main.cpp
The line I use to link is:
g++ -Wl,-bmaxdata:0x4000
-Wl,-blibpath:/usr/lib/threads:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.7.2:/usr/lib:/lib
-Wl,-bloadmap:/map.txt -omyexe main.o myobj_1.o myobj_2.o ...myobj_n.o
I want to mention that beside the pdsmain.cpp I have a lot of other
confidential cpp that I compile and link with pdsmain.cpp, but that should not
affect the constructors calling in the main object file, correct ?
So my basic question is: What could cause the constructors not to be called ?
Its definitely has to do with the big tree of headers. I can not provide them
as they are confidential.
I tried the same build (with the big tree of headers) on Linux and there it
works !
If needed I think I can provide the assembly file of the main.cpp with and
without the big tree of headers for you to see the differences.
One more thing:
This thread seems to have the same problem as me but it was never solved:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2413#c3.
See the comment from David Obermann 2006-09-20 06:38:07 UTC .
It seems in both cases the problem is reproducible with big applications on
AIX.
Could be the very number of global objects? Big TOC ?
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||dje at gcc dot gnu.org Component|c++ |target --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-03 09:40:27 UTC --- CC-ing David.
[Bug rtl-optimization/54792] New: [4.8 Regression] -fcompare-debug failures introduced by r191493
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54792 Bug #: 54792 Summary: [4.8 Regression] -fcompare-debug failures introduced by r191493 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: ja...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: ber...@gcc.gnu.org Target: i686-linux Created attachment 28338 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28338 tree-inline.ii.bz2 While bootstrapping a newer PR54519 fix, I've encountered a bootstrap comparison failure on i686-linux, which can be reproduced by stock trunk on the patched tree-inline.ii with: ./g++ -B ./ -S -O2 -m32 -fcompare-debug tree-inline.ii g++: error: tree-inline.ii: -fcompare-debug failure (length) I've bisected it to the http://gcc.gnu.org/viewcvs?root=gccview=revrev=191493 changes.
[Bug rtl-optimization/54792] [4.8 Regression] -fcompare-debug failures introduced by r191493
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54792 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 09:52:57 UTC --- Created attachment 28339 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28339 tree-inline-reduced.ii Delta reduced testcase. This one just fails -fcompare-debug, doesn't swap two insns as the full testcase.
[Bug rtl-optimization/54792] [4.8 Regression] -fcompare-debug failures introduced by r191493
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54792 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-03 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug rtl-optimization/54792] [4.8 Regression] -fcompare-debug failures introduced by r191493
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54792 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 09:59:05 UTC --- Created attachment 28340 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28340 gcc48-pr54792.patch Untested fix. The problem appears to be that find_modifiable_mems wasn't scanning the TAIL insn, without -g on the testcase there was a load from memory at the end of a basic block and it wasn't scanned, with -g there were some DEBUG_INSNs after it, thus tail was a DEBUG_INSN and the load was scanned and triggered the optimization.
[Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 --- Comment #6 from janus at gcc dot gnu.org 2012-10-03 10:38:22 UTC --- (In reply to comment #5) The following patch seems to cure the test case in comment 1, as well as both variants in comment 0: ... and regtests cleanly!
[Bug fortran/54788] ICE on pointer-array element assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788 --- Comment #4 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-10-03 10:45:10 UTC --- Thanks for your replies! I've managed to get a vector of array pointers employing one more intermediate derived type. The arrvec_t defined below has also some limited support for negative indexing as in Python: module arrvec_m implicit none type :: arr_t real, pointer :: a(:,:) end type type :: arrptr_t class(arr_t), pointer :: p end type type :: arrvec_t class(arrptr_t), pointer :: at(:) logical, pointer :: inited(:) contains procedure :: ctor = arrvec_ctor procedure :: init = arrvec_init procedure :: dtor = arrvec_dtor ! waiting for FINAL end type contains subroutine arrvec_ctor(this, n) class(arrvec_t) :: this integer, intent(in) :: n allocate(this%at(-n:n-1)) allocate(this%inited(0:n-1)) this%inited = .false. end subroutine subroutine arrvec_init(this, n, i_min, i_max, j_min, j_max) class(arrvec_t) :: this integer, intent(in) :: n, i_min, i_max, j_min, j_max allocate(this%at(n)%p) allocate(this%at(n)%p%a(i_min : i_max, j_min : j_max)) this%inited(n) = .true. this%at(n - size(this%inited))%p = this%at(n)%p end subroutine subroutine arrvec_dtor(this) class(arrvec_t) :: this integer :: i do i = 0, size(this%inited) - 1 if (this%inited(i)) then deallocate(this%at(i)%p%a) deallocate(this%at(i)%p) end if end do deallocate(this%at) end subroutine end module program test_arrvec use arrvec_m class(arrvec_t), pointer :: psi allocate(psi) call psi%ctor(2) call psi%init(0, 0, 3, 0, 4) print*, psi%at(0)%p%a print*, psi%at(0)%p%a(1,1) psi%at(0)%p%a(1,1) = 10 print*, psi%at(0)%p%a(1,1) print*, psi%at(-2)%p%a(1,1) call psi%dtor deallocate(psi) end
[Bug debug/54595] [4.8 Regression] symbol causes a section type conflict with itself with -O -g -fdata-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54595 Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org 2012-10-03 12:25:21 UTC --- Creating a reduced test case confirms this is the same as bug 53475. *** This bug has been marked as a duplicate of bug 53475 ***
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 --- Comment #12 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org 2012-10-03 12:25:21 UTC --- *** Bug 54595 has been marked as a duplicate of this bug. ***
[Bug debug/54793] New: the location of a formal_parameter is not started from a function entry with -mfentry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 Bug #: 54793 Summary: the location of a formal_parameter is not started from a function entry with -mfentry Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: masami.hiramatsu...@hitachi.com With -mfentry, GCC (I've found this with Red Hat 4.7.0-5 and Red Hat 4.7.2-2 on Fedora 17) generates odd debuginfo about variable locations. Here are examples: - 19a58: Abbrev Number: 86 (DW_TAG_subprogram) 9a59 DW_AT_external: 1 9a59 DW_AT_name: (indirect string, offset: 0xd82): unregister_di e_notifier 9a5d DW_AT_decl_file : 1 9a5e DW_AT_decl_line : 551 9a60 DW_AT_prototyped : 1 9a60 DW_AT_type: 0x7c 9a64 DW_AT_low_pc : 0x740 9a6c DW_AT_high_pc : 0x75a 9a74 DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) 9a76 DW_AT_GNU_all_call_sites: 1 9a76 DW_AT_sibling : 0x9aac 29a7a: Abbrev Number: 87 (DW_TAG_formal_parameter) 9a7b DW_AT_name: nb 9a7e DW_AT_decl_file : 1 9a7f DW_AT_decl_line : 551 9a81 DW_AT_type: 0x2a96 9a85 DW_AT_location: 0x172f (location list) ... 172f 0745 0750 (DW_OP_reg5 (rdi)) 172f 0750 0757 (DW_OP_reg4 (rsi)) 172f 0757 075a (DW_OP_GNU_entry_value: (DW_OP_reg5 (rdi)); DW_OP_stack_value) 172f End of list - As you can see, the location of the parameter nb, starts from 0x745 but unregister_die_notifier() function itself starts from 0x740. - 19aac: Abbrev Number: 86 (DW_TAG_subprogram) 9aad DW_AT_external: 1 9aad DW_AT_name: (indirect string, offset: 0x321f): notify_die 9ab1 DW_AT_decl_file : 1 9ab2 DW_AT_decl_line : 530 9ab4 DW_AT_prototyped : 1 9ab4 DW_AT_type: 0x7c 9ab8 DW_AT_low_pc : 0xb0 9ac0 DW_AT_high_pc : 0xe0 9ac8 DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) 9aca DW_AT_GNU_all_call_sites: 1 9aca DW_AT_sibling : 0x9b6c 29ace: Abbrev Number: 87 (DW_TAG_formal_parameter) 9acf DW_AT_name: val 9ad3 DW_AT_decl_file : 1 9ad4 DW_AT_decl_line : 530 9ad6 DW_AT_type: 0x2b36 9ada DW_AT_location: 0x177b (location list) ... 177b 00b0 00cd (DW_OP_reg5 (rdi)) 177b 00cd 00dd (DW_OP_reg4 (rsi)) 177b 00dd 00e0 (DW_OP_GNU_entry_value: (DW_OP_reg5 (rdi)); DW_OP_stack_value) 177b End of list - However, without fentry call (notifiy_die is marked notrace), the parameter val location start with 0xb0, which is same as notify_die start address. URL: https://lkml.org/lkml/2012/10/3/187
[Bug c++/54780] G++ does not find precompiled headers in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54780 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org 2012-10-03 13:10:32 UTC --- I guess this is not a big issue if you are using Autotools, where the established practice is to compile inside the source directory. It is common practice to build outside the source directory, since it is very well supported.
[Bug lto/54794] New: [4.8 regression] tree code '�F Hc���' is not supported in LTO streams
- 35710k} {GC
35710k - 35710k} static-var {GC 35710k - 35710k} {GC 35710k - 35710k} {GC
35710k - 35710k} {GC 35710k - 35710k} {GC 35710k - 35710k} {GC 35710k -
35710k}
Streaming out libp.so.ltrans0.o ( 8537 insns) libp.so.ltrans1.o ( 7341 insns)
libp.so.ltrans2.o ( 7290 insns) libp.so.ltrans3.o ( 6141 insns)
libp.so.ltrans4.o ( 6125 insns) libp.so.ltrans5.o ( 5859 insns)
libp.so.ltrans6.o ( 5835 insns) libp.so.ltrans7.o ( 5778 insns)
libp.so.ltrans8.o ( 5741 insns)
Program received signal SIGSEGV, Segmentation fault.
lto_output_tree (ob=0x1c71880, expr=0x17, ref_p=true, this_ref_p=true)
at /home/dimhen/src/gcc-current/gcc/lto-streamer-out.c:389
389 if (this_ref_p tree_is_indexable (expr))
(gdb) bt
#0 lto_output_tree (ob=0x1c71880, expr=0x17, ref_p=true,
this_ref_p=true) at /home/dimhen/src/gcc-current/gcc/lto-streamer-out.c:389
#1 0x009fb801 in write_ts_common_tree_pointers (ref_p=true,
expr=0x7420f6e0, ob=0x1c71880) at
/home/dimhen/src/gcc-current/gcc/tree-streamer-out.c:438
#2 streamer_write_tree_body (ob=0x1c71880, expr=0x7420f6e0,
ref_p=optimized out) at
/home/dimhen/src/gcc-current/gcc/tree-streamer-out.c:821
#3 0x00763fe4 in lto_write_tree (ref_p=optimized out,
expr=0x7420f6e0, ob=0x1c71880) at
/home/dimhen/src/gcc-current/gcc/lto-streamer-out.c:340
#4 lto_output_tree (ob=ob@entry=0x1c71880, expr=0x7420f6e0,
ref_p=ref_p@entry=true, this_ref_p=this_ref_p@entry=true) at
/home/dimhen/src/gcc-current/gcc/lto-streamer-out.c:427
#5 0x009fc1f0 in write_ts_exp_tree_pointers (ref_p=true,
expr=0x76d4b2d0, ob=0x1c71880) at
/home/dimhen/src/gcc-current/gcc/tree-streamer-out.c:677
#6 streamer_write_tree_body (ob=0x1c71880, expr=0x76d4b2d0,
ref_p=optimized out) at
/home/dimhen/src/gcc-current/gcc/tree-streamer-out.c:860
#7 0x00763fe4 in lto_write_tree (ref_p=optimized out,
expr=0x76d4b2d0, ob=0x1c71880) at
/home/dimhen/src/gcc-current/gcc/lto-streamer-out.c:340
#8 lto_output_tree (ob=0x1c71880, expr=0x76d4b2d0, ref_p=optimized out,
this_ref_p=optimized out) at
/home/dimhen/src/gcc-current/gcc/lto-streamer-out.c:427
#9 0x009fc154 in write_ts_exp_tree_pointers (ref_p=true,
expr=0x74205f80, ob=0x1c71880) at
/home/dimhen/src/gcc-current/gcc/tree-streamer-out.c:675
#10 streamer_write_tree_body (ob=0x1c71880, expr=0x74205f80,
ref_p=optimized out) at
/home/dimhen/src/gcc-current/gcc/tree-streamer-out.c:860
#11 0x00763fe4 in lto_write_tree (ref_p=optimized out,
expr=0x74205f80, ob=0x1c71880) at
/home/dimhen/src/gcc-current/gcc/lto-streamer-out.c:340
#12 lto_output_tree (ob=0x1c71880, expr=0x74205f80, ref_p=optimized out,
this_ref_p=optimized out) at
/home/dimhen/src/gcc-current/gcc/lto-streamer-out.c:427
#13 0x0075ebd6 in output_node_opt_summary (encoder=0x198d650,
node=0x762b24a0, ob=0x1c71880) at
/home/dimhen/src/gcc-current/gcc/lto-cgraph.c:1416
#14 output_cgraph_opt_summary () at
/home/dimhen/src/gcc-current/gcc/lto-cgraph.c:1459
#15 output_symtab () at /home/dimhen/src/gcc-current/gcc/lto-cgraph.c:767
#16 0x0076545d in lto_output () at
/home/dimhen/src/gcc-current/gcc/lto-streamer-out.c:1018
#17 0x0079c321 in ipa_write_optimization_summaries_1 (pass=0x1473c40,
state=state@entry=0x1bf65d0) at /home/dimhen/src/gcc-current/gcc/passes.c:2388
#18 0x0079d18f in ipa_write_optimization_summaries (encoder=0x198d650)
at /home/dimhen/src/gcc-current/gcc/passes.c:2435
#19 0x004d29e3 in lto_wpa_write_files () at
/home/dimhen/src/gcc-current/gcc/lto/lto.c:2637
#20 do_whole_program_analysis () at
/home/dimhen/src/gcc-current/gcc/lto/lto.c:3180
#21 lto_main () at /home/dimhen/src/gcc-current/gcc/lto/lto.c:3302
#22 0x0088b48c in compile_file () at
/home/dimhen/src/gcc-current/gcc/toplev.c:546
#23 0x0088d0aa in do_compile () at
/home/dimhen/src/gcc-current/gcc/toplev.c:1863
#24 toplev_main (argc=44, argv=0x1525c60) at
/home/dimhen/src/gcc-current/gcc/toplev.c:1939
#25 0x003536621735 in __libc_start_main (main=0x10638a0 main(int,
char**), argc=21, ubp_av=0x7fffddb8, init=optimized out, fini=optimized
out, rtld_fini=optimized out,
stack_end=0x7fffdda8) at libc-start.c:226
#26 0x004b10e9 in _start ()
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc-current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64 --enable-__cxa_atexit
--enable-shared --enable-checking=yes,df,fold,rtl,tree
--enable-gnu-unique-object --enable-linker-build-id
--enable-languages=c,c++,lto --enable-plugin
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.8.0 20121003 (experimental) [trunk revision 192029] (GCC)
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org 2012-10-03 13:46:44 UTC --- Constructors are working because they work without your big header. I would try using divide and conquer techniques to reduce the big header and find out what is interfering with constructors. It gives all appearances that it is due to the user code. Static constructors and destructors are run by functions generated at link time. A programmer wrapper around AIX ld called collect2 scans object files and libraries for constructors and generates functions that are invoked by AIX linker -binitfini feature. You can add -Wl,-debug to the link line to see the way the AIX linker is invoked and see the helper function. Is something in the big header changing the mangled names of constructors and destructors so that they do not use the standard pattern? Or inserting some illegal character like dollar sign ($)?
[Bug lto/54794] [4.8 regression] tree code '�F Hc���' is not supported in LTO streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54794 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-10-03 13:47:36 UTC --- Please see: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs
[Bug debug/54793] the location of a formal_parameter is not started from a function entry with -mfentry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-03 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 13:48:58 UTC --- Please provide preprocessed testcase and gcc options used to compile it.
[Bug lto/54794] [4.8 regression] tree code '�F Hc���' is not supported in LTO streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54794 --- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com 2012-10-03 14:04:06 UTC --- i have 23 src-files hence 23 ii-files with about 50Mb code if i remove any file from build then err not triggered (at beginning there were 29 files) i'll run creduce tonight. Oh, cycle throw 23 files :)
[Bug debug/54793] the location of a formal_parameter is not started from a function entry with -mfentry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC||aoliva at gcc dot gnu.org,
||jason at gcc dot gnu.org,
||rth at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03
14:12:20 UTC ---
That said, it can be reproduced even on:
int
foo (int a, int b)
{
asm volatile (nop);
a = 1;
return a + b;
}
with -g -O2 -mfentry -p -dA. The issue is that FUNCTION_PROFILER before
epilogue is emitted really very early, before processing any
NOTE_INSN_VAR_LOCATION that are before the first real insn.
If the targetm.asm_out.function_prologue hook is the default, outputting
nothing, perhaps we could consider as ugly hack to process the
NOTE_INSN_VAR_LOCATION notes before any non-note insn before calling the
FUNCTION_PROFILER, or, just forcefully use the function start label in
dwarf2out_var_location for notes that are before first real insn, perhaps limit
that to #ifdef HAVE_prologue if (HAVE_prologue) #endif to avoid damaging debug
info for !HAVE_prologue targets (if there are still any).
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Attachment #28304|0 |1 is obsolete|| --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org 2012-10-03 14:20:22 UTC --- Created attachment 28341 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28341 Updated OPTIONAL patch Current version of my OPTIONAL patch. Changes: - polymorphic scalar coarray to polymorphic noncoarrays work now - Much extended test case (and plenty of new FIXMEs) TODO: Fix those FIXMEs. Other TODO items: - Support packing of assumed-rank arrays (see just attached test case; but otherwise an unrelated issue) - Fix INTENT(OUT) handling for allocatable polymorphic arrays (cf. comment 0) - Analyse the old issue related to class_array_7.f03 (comment 11, comment 12)
[Bug c++/54777] [C++11] Comma operator in constexpr environment can cause ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54777 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 14:21:24 UTC --- Author: jakub Date: Wed Oct 3 14:21:20 2012 New Revision: 192036 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192036 Log: PR c++/54777 * semantics.c (cxx_eval_constant_expression) case COMPOUND_EXPR: If not ignoring the second operand, pass the original second operand and not one with stripped nops to cxx_eval_constant_expression. * g++.dg/cpp0x/constexpr-ref4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ref4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/54777] [C++11] Comma operator in constexpr environment can cause ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54777 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 14:27:35 UTC --- Author: jakub Date: Wed Oct 3 14:27:30 2012 New Revision: 192037 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192037 Log: PR c++/54777 * semantics.c (cxx_eval_constant_expression) case COMPOUND_EXPR: If not ignoring the second operand, pass the original second operand and not one with stripped nops to cxx_eval_constant_expression. * g++.dg/cpp0x/constexpr-ref4.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-ref4.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/semantics.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-03 14:27:50 UTC --- Daniel, what's the status of this issue? Is there some consensus that GCC is actually Ok, we don't really want to reject reinterpret_casts? Because I would find very useful a constexpr std::addressof. For the time being we could certainly have it constexpr anyway and change the implementation details when/if the C++ front-end starts rejecting reintepret_casts, but I would rather not.
[Bug rtl-optimization/54792] [4.8 Regression] -fcompare-debug failures introduced by r191493
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54792 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 14:28:32 UTC --- Author: jakub Date: Wed Oct 3 14:28:28 2012 New Revision: 192038 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192038 Log: PR rtl-optimization/54792 * sched-deps.c (find_modifiable_mems): Scan also TAIL insn. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c
[Bug c++/54777] [C++11] Comma operator in constexpr environment can cause ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54777 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 14:31:35 UTC --- Fixed for 4.7+.
[Bug rtl-optimization/54792] [4.8 Regression] -fcompare-debug failures introduced by r191493
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54792 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 14:32:15 UTC --- Fixed.
[Bug bootstrap/54795] New: [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 Bug #: 54795 Summary: [4.8 Regression] Random profiledbootstrap failure with LTO Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 191825 configured with --prefix=/usr/local --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --with-build-config=bootstrap-lto --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc failed to profiledbootstrap: /tmp/ccFJkgbJ.s: Assembler messages: /tmp/ccFJkgbJ.s:752755: Error: invalid character (0x83) in mnemonic make[7]: *** [/tmp/ccSxjzh4.ltrans14.ltrans.o] Error 1 It happens at random.
[Bug debug/54796] New: [4.8 Regression] Non-addressable stack parameter debug quality regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54796
Bug #: 54796
Summary: [4.8 Regression] Non-addressable stack parameter debug
quality regression
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: aol...@gcc.gnu.org
Target: i686-linux
/* PR debug/N */
/* { dg-do run } */
/* { dg-options -g } */
__attribute__((noinline, noclone)) void
bar (char *a, int b)
{
__asm volatile ( : +r (a), +r (b) : : memory);
}
__attribute__((noinline, noclone)) void
foo (int a, int b)
{
int c = a;
char d[b];/* { dg-final { gdb-test 17 a 5 } } */
bar (d, 2);/* { dg-final { gdb-test 17 b 6 } } */
bar (d, 4);/* { dg-final { gdb-test 17 c 5 } } */
}
int
main ()
{
foo (5, 6);
return 0;
}
(line 17 is the second call to bar) regressed for -m32 -Os -g on
{i686,x86_64}-linux supposedly with the
http://gcc.gnu.org/viewcvs?root=gccview=revrev=188871
change. I've mentioned this already in
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00262.html
but filing it now on a testcase that is not dependent on any GCC patches.
The problem is that vt_canon_true_dep/canon_true_dependence doesn't figure out
that the stack stores (after prologue where hard fp is initialized) can't alias
argp. Without the VLA or other reasons forcing use of frame pointer
var-tracking replaces sp accesses with argp + offset accesses and
canon_true_dependence then disambiguates it using the offsets.
[Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[OOP] allocation of |[4.7/4.8 Regression] [OOP] |extended types with |wrong code in polymorphic |polymorphic allocatable |allocation with SOURCE |members | --- Comment #7 from janus at gcc dot gnu.org 2012-10-03 16:09:03 UTC --- This even seems to be a regression: The test case in comment 1 runs without error when compiled with gfortran 4.6 (and also the dump looks ok).
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 --- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-10-03 16:22:24 UTC --- (In reply to comment #3) Daniel, what's the status of this issue? Is there some consensus that GCC is actually Ok, we don't really want to reject reinterpret_casts? My opinion is that gcc should start to implement the new core rules in regard to reinterpret_cast *except* for cases that are well-defined. Because I would find very useful a constexpr std::addressof. For the time being we could certainly have it constexpr anyway and change the implementation details when/if the C++ front-end starts rejecting reintepret_casts, but I would rather not. Exactly this usage of reinterpret_cast seems IMO to be well granted by the standard - at least by the way I read it.
[Bug debug/54796] [4.8 Regression] Non-addressable stack parameter debug quality regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54796 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 16:40:04 UTC --- I think the problem is that by the time these vt_canon_true_dep calls are made, mloc's addr is some VALUE for which alias.c unfortunately no longer can figure out that they are sp based, as sp REG has been removed from all the VALUE locs. If we could somehow somewhere preserve the information that some VALUEs are sp based (i.e. find_base_term (val) == static_reg_base_value[STACK_POINTER_REGNUM]), then we could disambiguate at least that the sp based stores can't clobber global vars or hard frame pointer based MEMs.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-03 16:46:30 UTC --- Ok, thanks. Sorry about the naive question: is it already clear what it means for reinterpret_cast uses to be well-defined in this sense?
[Bug middle-end/54782] [4.8 Regression] ICE: in change_scope, at final.c:1543 with -O -ffast-math -ftree-parallelize-loops=2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54782 --- Comment #2 from Dehao Chen dehao at google dot com 2012-10-03 16:47:23 UTC --- Thanks for reporting this problem. The root cause has been identified that phi_arg_location is not correctly updated in move_block_to_fn. A patch is on the way. BTW, how can I assign this patch to me? Looks like there is no such a button in my view.
[Bug middle-end/54782] [4.8 Regression] ICE: in change_scope, at final.c:1543 with -O -ffast-math -ftree-parallelize-loops=2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54782 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 16:54:47 UTC --- You need to log into bugzilla using your gcc.gnu.org account.
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 2012-10-03 17:32:01 UTC --- (In reply to comment #14) - Fix INTENT(OUT) handling for allocatable polymorphic arrays (cf. comment 0) Reminder: Check that this also handles (non)polymorphic assumed-rank arrays correctly.
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 Andrew W. Nosenko andrew.w.nosenko at gmail dot com changed: What|Removed |Added CC||andrew.w.nosenko at gmail ||dot com --- Comment #17 from Andrew W. Nosenko andrew.w.nosenko at gmail dot com 2012-10-03 17:32:51 UTC --- Sorry, but commited patch does NOT fixes the problem. It does just reverse -- disables AVX Co on systems the has OSXSAVE, XSTATE_SSE and XSTATE_YMM bits set, while the intention was to disable if any of these bits are not set. Proposed followup patch is attached.
[Bug debug/54796] [4.8 Regression] Non-addressable stack parameter debug quality regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54796 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 17:35:44 UTC --- Perhaps it would suffice to reserve another rtx flag bit on VALUE for SP_BASED_VALUE_P, and just from var-tracking if hard_frame_pointer_adjustment is != -1 (i.e. frame_pointer_needed and hfp = assignment has been seen) mark that way sp values that are created afterwards, and change find_base_term in alias.c so that it returns static_reg_base_value[STACK_POINTER_REGNUM] when seeing VALUEs marked that way.
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 --- Comment #18 from Andrew W. Nosenko andrew.w.nosenko at gmail dot com 2012-10-03 17:36:28 UTC --- Created attachment 28342 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28342 Followup patch for config/i386/driver-i386.c
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-03 Ever Confirmed|0 |1 --- Comment #6 from David Edelsohn dje at gcc dot gnu.org 2012-10-03 17:52:48 UTC --- Perry and I have been discussing this for a while. As others mentioned, the patch should be against mainline and this discussion of the path should happen on gcc-patches, not Bugzilla.
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 18:06:29 UTC --- The patch looks good to me, but patches should be posted to gcc-patches at gcc.gnu.org mailing list instead.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 --- Comment #6 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-10-03 18:46:09 UTC --- (In reply to comment #5) Ok, thanks. Sorry about the naive question: is it already clear what it means for reinterpret_cast uses to be well-defined in this sense? This is surely no naive question. I should have been more specific: I think only those reinterpret_cast operations that have a *specified* result, should be allowed (similar to relational or equality operations). For example An expression of integral, enumeration, pointer, or pointer-to-member type can be explicitly converted to its own type; such a cast yields the value of its operand. seems well specified and uncontroversial to me. Another example (and this is relevant for std::addressof) is the combination of p7 An object pointer can be explicitly converted to an object pointer of a different type. [..] Converting a prvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value. and p11 An lvalue expression of type T1 can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. That is, a reference cast reinterpret_castT(x) has the same effect as the conversion *reinterpret_castT*(x) with the built-in and * operators (and similarly for reinterpret_castT(x)). In other words, the whole expression reinterpret_castT*(const_castchar( reinterpret_castconst volatile char(t))) that is typically used for the real address deduction seems to have well-specified behaviour and should thus be constexpr-friendly.
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-03 18:48:30 UTC --- Seems H.J. has committed this already: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192044 http://gcc.gnu.org/viewcvs?root=gccview=revrev=192045 http://gcc.gnu.org/viewcvs?root=gccview=revrev=192046
[Bug fortran/54797] New: Gnu Fortran compiler does not recognize module file it created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54797 Bug #: 54797 Summary: Gnu Fortran compiler does not recognize module file it created Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: christopher.rom...@gmail.com I am trying to compile a library of module files using make for use later in codes, that may require mpi or on earlier created modules. I have tested the compilation with pgfortran and intel compilers on linux with open-mpi 1.4.5 and it works perfectly. I have additionally tested it on linux using open-mpi 1.4.5 and gfortran 4.2.1 and on Mac OSx 10.6 with open-mpi 1.4.3 and gfortran 4.6, with both failing with the following error: Fatal Error: File 'odesoldat.mod' opened at (1) is not a GFORTRAN module file I have checked to make sure that I throughly cleaned the folders to make sure the module file as well as the object file are deleted prior to compilation. I am using the following compilation flags: FLAGS = -O3 -fdefault-real-8 -fdefault-double-8 -J $(MODULE) If anyone has insights they would be most welcome.
[Bug fortran/54797] Gnu Fortran compiler does not recognize module file it created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54797 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2012-10-03 19:20:19 UTC --- (In reply to comment #0) I am trying to compile a library of module files using make for use later in codes, that may require mpi or on earlier created modules. I have tested the compilation with pgfortran and intel compilers on linux with open-mpi 1.4.5 and it works perfectly. I have additionally tested it on linux using open-mpi 1.4.5 and gfortran 4.2.1 and on Mac OSx 10.6 with open-mpi 1.4.3 and gfortran 4.6, with both failing with the following error: Fatal Error: File 'odesoldat.mod' opened at (1) is not a GFORTRAN module file I have checked to make sure that I throughly cleaned the folders to make sure the module file as well as the object file are deleted prior to compilation. I am using the following compilation flags: FLAGS = -O3 -fdefault-real-8 -fdefault-double-8 -J $(MODULE) If anyone has insights they would be most welcome. What is the first line in odesoldat.mod? Have you tried using the -I option?
[Bug fortran/54797] Gnu Fortran compiler does not recognize module file it created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54797 --- Comment #2 from christopher.romick at gmail dot com 2012-10-03 19:37:24 UTC --- I have indeed tried include -I but it makes no differences. The compilation returns the same error. The 1st line states GFORTRAN module created from /.../odesolver/LSODE/datodesol.f90 on Wed Oct 3 15:35:10 2012 of course the ... is the rest of the full path
[Bug c++/54798] New: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54798 Bug #: 54798 Summary: internal compiler error: Segmentation fault Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@boxie.eu Created attachment 28343 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28343 test case I'm getting an internal compiler error both on gcc 4.7.0 on Ubuntu 12.04.1 and an MinGW-w64 gcc 4.7.2 for Windows. A reduced source test case is attached. The error does not occur as soon as I use the captured this pointer. Output is as follows: $ g++ -std=c++11 ice.cpp -o ice ice.cpp: In lambda function: ice.cpp:47:24: internal compiler error: Segmentation fault
[Bug c++/54798] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54798 --- Comment #1 from gcc at boxie dot eu 2012-10-03 19:44:05 UTC --- Errr.. The error DOES occur as soon as I use the captured this pointer.
[Bug target/51518] ICE: in expand_call, at calls.c:3421 with -mno-accumulate-outgoing-args and __attribute__ ((ms_abi)) (after sorry)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51518 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-03 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-03 19:47:31 UTC --- Confirmed.
[Bug fortran/54797] Gnu Fortran compiler does not recognize module file it created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54797 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu 2012-10-03 19:55:46 UTC --- On Wed, Oct 03, 2012 at 07:37:24PM +, christopher.romick at gmail dot com wrote: I have indeed tried include -I but it makes no differences. The compilation returns the same error. The 1st line states GFORTRAN module created from /.../odesolver/LSODE/datodesol.f90 on Wed Oct 3 15:35:10 2012 of course the ... is the rest of the full path Which version of gfortran? With version 4.4.x and above you should have a version number. % gfc44 -c a.f90 head -1 a.mod GFORTRAN module version '0' created from a.f90 on Wed Oct 3 12:50:55 2012 % gfc45 -c a.f90 head -1 a.mod GFORTRAN module version '4' created from a.f90 on Wed Oct 3 12:51:00 2012 % gfc46 -c a.f90 head -1 a.mod GFORTRAN module version '6' created from a.f90 on Wed Oct 3 12:51:04 2012 % gfc47 -c a.f90 head -1 a.mod GFORTRAN module version '9' created from a.f90 % gfc4x -c a.f90 head -1 a.mod GFORTRAN module version '9' created from a.f90 Do you have more than one version of gfortran installed on the system? It appears as if you are building the module with an older gfortran and trying to use with a newer version.
[Bug ada/54799] New: Missing ; gives GNAT BUG DETECTED box with GPL 2012, GPL 2010, AUX 4.7.1, and AUX 4.6.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54799 Bug #: 54799 Summary: Missing ; gives GNAT BUG DETECTED box with GPL 2012, GPL 2010, AUX 4.7.1, and AUX 4.6.3 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: denkpa...@gmail.com A missing ; in a short .adb file generates a gnat bug box with GPL 2012 and GPL 2010, both on my Linux 3.2 i686 system, and with GNAT AUX 4.7.1 and 4.6.3 on FreeBSD 9.0 i386 and DragonFly BSD x86-64. On my FreeBSD 9.0 i386 system with GNAT AUX 4.6.3 and 4.7.1: $ gnatmake libthr3.adb ada -c libthr3.adb +===GNAT BUG DETECTED==+ | 4.7.1 20120614 (release) -= GNAT AUX [FreeBSD] (i386-aux-freebsd9.0)| | Assert_Failure nlists.adb:431| | Error detected at libthr3.adb:8:4| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). libthr3.adb libthr3.adb:10:18: missing ; compilation abandoned gnatmake: libthr3.adb compilation error $ gnatmake libthr2.adb gnatgcc -c libthr2.adb +===GNAT BUG DETECTED==+ | 4.6.3 20120301 (release) -= GNAT AUX [FreeBSD] (i386-aux-freebsd9.0)| | Assert_Failure nlists.adb:431| | Error detected at libthr2.adb:14:11 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). libthr2.adb libthr2.adb:16:31: missing ; compilation abandoned gnatmake: libthr2.adb compilation error On my Linux 3.2 i686 system with GNAT GPL 2010 I get this _without_ -gnat05: $ gnatmake libthr3.adb gcc -c libthr3.adb libthr3.adb:10:18: missing ; libthr3.adb:14:09: generalized use of anonymous access types is an Ada 2005 extension libthr3.adb:14:09: unit must be compiled with -gnat05 switch gnatmake: libthr3.adb compilation error With -gnat05 I get the gnat bug box: $ gnatmake -gnat05 libthr3.adb gcc -c -gnat05 libthr3.adb +===GNAT BUG DETECTED==+ | GPL 2010 (20100603) (i686-pc-linux-gnu) Storage_Error stack overflow (or erroneous memory access)| | Error detected at libthr3.adb:8:4| | Please submit a bug report by email to rep...@adacore.com. | | GAP members can alternatively use GNAT Tracker: | | http://www.adacore.com/ section 'send a report'. | | See gnatinfo.txt for full info on procedure for submitting bugs. | | Use a subject line meaningful to you and us to track the bug.| |
[Bug ada/54799] Missing ; gives GNAT BUG DETECTED box with GPL 2012, GPL 2010, AUX 4.7.1, and AUX 4.6.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54799 --- Comment #1 from denkpadje at gmail dot com 2012-10-03 19:59:06 UTC --- Created attachment 28344 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28344 The test file
[Bug c++/54798] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54798 --- Comment #2 from gcc at boxie dot eu 2012-10-03 20:01:32 UTC --- Created attachment 28345 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28345 minimal test case I further reduce the test case to a minimum. The ICE only happens if the nested class is a template.
[Bug tree-optimization/51238] ICE: SIGSEGV in find_uses_to_rename_use (tree-ssa-loop-manip.c:1267) with -Os -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51238 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-03 20:25:02 UTC --- This does not happen anymore with the trunk. (At least since r188409.)
[Bug middle-end/54782] [4.8 Regression] ICE: in change_scope, at final.c:1543 with -O -ffast-math -ftree-parallelize-loops=2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54782 --- Comment #4 from dehao at gcc dot gnu.org 2012-10-03 20:34:30 UTC --- Author: dehao Date: Wed Oct 3 20:34:26 2012 New Revision: 192049 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192049 Log: 2012-10-03 Dehao Chen de...@google.com gcc: PR middle-end/54782 * tree-cfg.c (move_block_to_fn): Update lexical block for phi_args. testsuite: PR middle-end/54782 * gcc.dg/pr54782.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr54782.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug middle-end/54782] [4.8 Regression] ICE: in change_scope, at final.c:1543 with -O -ffast-math -ftree-parallelize-loops=2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54782 dehao at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from dehao at gcc dot gnu.org 2012-10-03 20:35:42 UTC --- Fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=192049
[Bug middle-end/50211] ICE: verify_flow_info: Incorrect fallthru 11-12 with -funroll-all-loops --param case-values-threshold=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50211 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-03 20:41:00 UTC --- Does not seem to happen anymore.
[Bug c++/54798] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54798
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-10-03 21:20:01 UTC ---
This happens also with gcc 4.8 HEAD. Further simplifications and removal of
library dependencies:
//---
void use(int){}
template typename U
class C
{
public:
void f()
{
[]()
{
use(_member);
}();
}
private:
int _member;
};
//---
After this reduction it looks like a dup of bug 53921 to me.
[Bug other/54800] New: libiberty/simple-object-mach-o.c:704: possible optimisation ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54800 Bug #: 54800 Summary: libiberty/simple-object-mach-o.c:704: possible optimisation ? Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried the latest cppcheck over the source code of trunk and it said [trunk/libiberty/simple-object-mach-o.c:704] - [trunk/libiberty/simple-object-mach-o.c:705]: (performance) Buffer 'namebuf' is being written before its old content has been used. The source code is memset (namebuf, 0, MACH_O_NAME_LEN * 2 + 2); memcpy (namebuf, (char *) sechdr + segname_offset, MACH_O_NAME_LEN); Maybe something like memcpy (namebuf, (char *) sechdr + segname_offset, MACH_O_NAME_LEN); memset (namebuf[MACH_O_NAME_LEN], MACH_O_NAME_LEN + 2); might be faster and simpler ?
[Bug other/54800] libiberty/simple-object-mach-o.c:704: possible optimisation ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54800 --- Comment #1 from David Binderman dcb314 at hotmail dot com 2012-10-03 21:22:31 UTC --- Or if you want something that compiles memset (namebuf[MACH_O_NAME_LEN], 0, MACH_O_NAME_LEN + 2); might be closer ;-
[Bug target/50457] SH2A atomic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457 --- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-03 21:36:18 UTC --- Author: olegendo Date: Wed Oct 3 21:36:14 2012 New Revision: 192051 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192051 Log: PR target/50457 * config/sh/sh.c (parse_validate_atomic_model_option): Handle name strings in sh_atomic_model. * config/sh/sh.h (TARGET_CPU_CPP_BUILTINS): Move macro implementation to ... * config/sh/sh-c.c (sh_cpu_cpp_builtins): ... this new function. Add __SH1__ and __SH2__ defines. Add __SH_ATOMIC_MODEL_*__ define. * config/sh/sh-protos.h (sh_atomic_model): Add name and cdef_name variables. (sh_cpu_cpp_builtins): Declare new function. PR target/50457 * config/sh/linux-atomic.S: Delete. * config/sh/linux-atomic.c: New. * config/sh/t-linux (LIB2ADD): Replace linux-atomic.S with linux-atomic.c. Add cflags to disable warnings. Added: trunk/libgcc/config/sh/linux-atomic.c Removed: trunk/libgcc/config/sh/linux-atomic.S Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-c.c trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.h trunk/libgcc/ChangeLog trunk/libgcc/config/sh/t-linux
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #54 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-03 21:39:22 UTC --- Author: olegendo Date: Wed Oct 3 21:39:18 2012 New Revision: 192052 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192052 Log: PR target/51244 * config/sh/sh.md (*mov_t_msb_neg): New insn and two accompanying unnamed split patterns. PR target/51244 * gcc.target/sh/pr51244-12.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr51244-12.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug c++/54798] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54798 --- Comment #4 from Christian Maaser gcc at boxie dot eu 2012-10-03 21:42:30 UTC --- True, looks like the same bug. My workaround was to define auto self = this; outside the lambda function, but using this- bypasses the issue as well.
[Bug target/26472] Default path for libgcc_s.sl is build directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472 Anil Krishnan anilkris at hotmail dot com changed: What|Removed |Added CC||anilkris at hotmail dot com --- Comment #16 from Anil Krishnan anilkris at hotmail dot com 2012-10-03 22:18:59 UTC --- Hi I am getting the following error when I run a concurrent programs in Oracle R12.1.3, which calls a Pro *C executable. /usr/lib/dld.sl: Can't find path for shared library: libstdc++.sl.5 /usr/lib/dld.sl: No such file or directory /d701/oracle/cfo/bin/CFORPPL Program was terminated by signal 6 - more information : we have libstdc++.sl.5 available in the path /usr/lib/. An ls -ltr in /usr/lib/ gives ls -ltr libstdc++.sl.5 lrwx-- 1 root sys 35 Feb 28 2012 libstdc++.sl.5 - /usr/syncsort/lib/libstdc++.sl.5_32 similarly an ls -ltr in /usr/syncsort/lib/ gives -rwxr-xr-x 1 root sys5768296 Feb 8 2006 /usr/syncsort/lib/libstdc++.sl.5 I am not sure what is the issue?? For apps mgr /home/appsimd1echo $SHLIB_PATH /d701/oracle/apps/apps_st/appl/pay/12.0.0/vendor/quantum/lib: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0/server: /d701/oracle/apps/apps_st/appl/cz/12.0.0/bin: /d701/oracle/apps/tech_st/10.1.2/lib32: /d701/oracle/apps/tech_st/10.1.2/lib: /usr/dt/lib: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0/server: /d701/oracle/apps/apps_st/appl/sht/12.0.0/lib: /d701/oracle/apps/tech_st/10.1.2/lib: /usr/lib: /usr/syncsort/lib but for a normal user imd1 echo $SHLIB_PATH /d701/oracle/apps/apps_st/appl/pay/12.0.0/vendor/quantum/lib: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0/server: /d701/oracle/apps/apps_st/appl/cz/12.0.0/bin: /d701/oracle/apps/tech_st/10.1.2/lib32: /d701/oracle/apps/tech_st/10.1.2/lib: /usr/dt/lib: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0/server: /d701/oracle/apps/apps_st/appl/sht/12.0.0/lib: /usr/syncsort/lib: /opt/microfocus/cobol/lib I am not sure what is the unix user the Oracle Concurrent program is using. Is it a path issue? Please help
[Bug c++/54801] New: [c++11] static variables constructed with lambda params inside member functions cause undefined errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54801
Bug #: 54801
Summary: [c++11] static variables constructed with lambda
params inside member functions cause undefined errors
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@godbolt.org
Created attachment 28346
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28346
Test C file exhibiting the issue
In the attached code, there is static method with a static variable whose
constructor takes a function pointer. When a lambda is passed as the function
pointer, it seems the lambda's definition is dropped and the result is a
link-time error.
$ g++ -o test -std=c++0x test.cc
/tmp/ccpBFtG7.o: In function `Test::aFunc()::{lambda(int*)#1}::operator void
(*)(int*)() const':
test.cc:(.text._ZZN4Test5aFuncEvENKUlPiE_cvPFvS0_EEv[_ZZN4Test5aFuncEvENKUlPiE_cvPFvS0_EEv]+0x9):
undefined reference to `Test::aFunc()::{lambda(int*)#1}::_FUN(int*)'
collect2: error: ld returned 1 exit status
Making the variable non-static fixes the issue. The same code in a free
function does not exhibit the problem. Taking a std::functionvoid(int*) as
the constructor parameter also cures the issue. It seems to be something which
only throws away the lambda for static variables inside member functions.
More info:
g++ -v
Using built-in specs.
COLLECT_GCC=/site/apps/gcc-4.7.2-drw.patched.1/bin/g++
COLLECT_LTO_WRAPPER=/site/apps/gcc-4.7.2-drw.patched.1/libexec/gcc/x86_64-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ./configure --prefix /site/apps/gcc-4.7.2-drw.patched.1
--build=x86_64-linux-gnu --enable-clocale=gnu --enable-gold
--enable-languages=c,c++ --enable-ld=default --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugin --enable-shared --enable-threads=posix --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-pkgversion=DRW-internal-build
--with-plugin-ld=ld.gold --with-system-zlib
--with-gmp=/data/teamcity/work/sup-chietfbld02-002/8a981abc13d5c0c5/scratch/gcc/4.7.2/build/gmp-5.0.2
--with-mpfr=/data/teamcity/work/sup-chietfbld02-002/8a981abc13d5c0c5/scratch/gcc/4.7.2/build/mpfr-3.1.1
--with-mpc=/data/teamcity/work/sup-chietfbld02-002/8a981abc13d5c0c5/scratch/gcc/4.7.2/build/mpc-0.9
--with-libelf=/data/teamcity/work/sup-chietfbld02-002/8a981abc13d5c0c5/scratch/gcc/4.7.2/build/libelf-0.8.9
Thread model: posix
gcc version 4.7.2 (DRW-internal-build)
This issue was discovered when attempting to register lambda functions as the
cleanup function for static thread-local stored information using
boost::thread_specific_ptr. However, the issue is reproducible in the attached
source file with no external includes.
This appears to be a regression in 4.7.2: gcc versions 4.7.1, 4.7.0, 4.6.3 and
4.5.3 compile the source without issue.
[Bug target/26472] Default path for libgcc_s.sl is build directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472 --- Comment #17 from dave.anglin at bell dot net 2012-10-03 22:39:46 UTC --- On 3-Oct-12, at 6:18 PM, anilkris at hotmail dot com wrote: I am getting the following error when I run a concurrent programs in Oracle R12.1.3, which calls a Pro *C executable. /usr/lib/dld.sl: Can't find path for shared library: libstdc++.sl.5 /usr/lib/dld.sl: No such file or directory /d701/oracle/cfo/bin/CFORPPL Program was terminated by signal 6 This issue isn't related to bug. Whether SHLIB_PATH is used or not depends on how applications and libraries are linked. The chatr program can be used to see how an application or library has been linked, and the library paths. It may be possible to use chatr to adjust the settings so the error doesn't occur. Library paths are hardcoded during linking. -- John David Anglindave.ang...@bell.net
[Bug c/54802] New: Trivial code changes result in different assembly with respect to rotations and bswap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54802
Bug #: 54802
Summary: Trivial code changes result in different assembly with
respect to rotations and bswap.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jasongross9+bugzi...@gmail.com
Created attachment 28347
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28347
Code files
In some C code, manually inlining constants changes whether or not gcc compiles
things to rotations or to bswaps. In particular, the following code
uint64_t reverse0(uint64_t v) {
v = ((v 1) 0xULL) | ((v 0xULL) 1);
v = ((v 2) 0xULL) | ((v 0xULL) 2);
v = ((v 4) 0x0F0F0F0F0F0F0F0FULL) | ((v 0x0F0F0F0F0F0F0F0FULL) 4);
v = ((v 8) 0x00FF00FF00FF00FFULL) | ((v 0x00FF00FF00FF00FFULL) 8);
v = ((v 16) 0xULL) | ((v 0xULL)
16);
const uint64_t
va = ((v 32) 0xULL),
vb = ((v 0xULL) 32);
v = va | vb;
return v;
}
uint64_t reverse1(uint64_t v) {
v = ((v 1) 0xULL) | ((v 0xULL) 1);
v = ((v 2) 0xULL) | ((v 0xULL) 2);
v = ((v 4) 0x0F0F0F0F0F0F0F0FULL) | ((v 0x0F0F0F0F0F0F0F0FULL) 4);
v = ((v 8) 0x00FF00FF00FF00FFULL) | ((v 0x00FF00FF00FF00FFULL) 8);
v = ((v 16) 0xULL) | ((v 0xULL)
16);
v = ((v 32) 0xULL) | ((v 0xULL)
32);
return v;
}
compiles to
reverse0:
.LFB8:
.cfi_startproc
movq%rdi, %rdx
movabsq$6148914691236517205, %rax
movabsq$3689348814741910323, %rcx
shrq%rdx
andq%rax, %rdx
andq%rdi, %rax
addq%rax, %rax
orq%rdx, %rax
movq%rax, %rdx
andq%rcx, %rax
shrq$2, %rdx
salq$2, %rax
andq%rcx, %rdx
movabsq$1085102592571150095, %rcx
orq%rdx, %rax
movq%rax, %rdx
andq%rcx, %rax
shrq$4, %rdx
salq$4, %rax
andq%rcx, %rdx
orq%rdx, %rax
bswap%rax
ret
.cfi_endproc
.LFE8:
.sizereverse0, .-reverse0
.p2align 4,,15
.globlreverse1
.typereverse1, @function
reverse1:
.LFB9:
.cfi_startproc
movq%rdi, %rdx
movabsq$6148914691236517205, %rax
movabsq$3689348814741910323, %rcx
shrq%rdx
andq%rax, %rdx
andq%rdi, %rax
addq%rax, %rax
orq%rdx, %rax
movq%rax, %rdx
andq%rcx, %rax
shrq$2, %rdx
salq$2, %rax
andq%rcx, %rdx
movabsq$1085102592571150095, %rcx
orq%rdx, %rax
movq%rax, %rdx
andq%rcx, %rax
shrq$4, %rdx
salq$4, %rax
andq%rcx, %rdx
movabsq$71777214294589695, %rcx
orq%rdx, %rax
movq%rax, %rdx
andq%rcx, %rax
shrq$8, %rdx
salq$8, %rax
andq%rcx, %rdx
movabsq$281470681808895, %rcx
orq%rdx, %rax
movq%rax, %rdx
andq%rcx, %rax
shrq$16, %rdx
salq$16, %rax
andq%rcx, %rdx
orq%rdx, %rax
rorq$32, %rax
ret
.cfi_endproc
.LFE9:
.sizereverse1, .-reverse1
.p2align 4,,15
.globlreverse2
.typereverse2, @function
In the code that I'm using this in, reverse0 is 30% faster than reverse1. I
don't think that manual constant inlining, when each constant is used exactly
once, should change the assembly code that gcc compiles to.
The relevant (.c, .i, .s, and a log of the command line) files are attached.
[Bug c++/53921] [C++0x] ICE on lambda inside method of class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53921 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||gcc at boxie dot eu --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-03 23:53:39 UTC --- *** Bug 54798 has been marked as a duplicate of this bug. ***
[Bug c++/54798] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54798 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-03 23:53:39 UTC --- Dup. *** This bug has been marked as a duplicate of bug 53921 ***
[Bug c/54803] New: Manual constant unfolding breaks vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54803
Bug #: 54803
Summary: Manual constant unfolding breaks vectorization
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jasongross9+bugzi...@gmail.com
Created attachment 28348
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28348
code files
Manually unfolding constants sometimes prevents vectorization.
For example, these loops vectorize:
void multi_left_shift0(uint64_t *const array, size_t len, size_t num_bits) {
for (size_t i = 0; i len; i++) {
array[i] = (array[i] 31) | (array[i] 31);
}
}
void multi_left_shift2(uint64_t *const array, size_t len, size_t num_bits) {
for (size_t i = 0; i len; i++) {
const uint64_t tempa = array[i] 32;
const uint64_t tempb = array[i] 32;
array[i] = tempa | tempb;
}
}
but this loops does not:
void multi_left_shiftb0(uint64_t *const array, size_t len, size_t num_bits) {
for (size_t i = 0; i len; i++) {
array[i] = (array[i] 32) | (array[i] 32);
}
}
See attached file for the code, preprocessed code, gcc command line log, and
assembly.
[Bug libstdc++/53248] std::arrayT,0 doesn't work when T is not default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-10-04 00:02:33 UTC --- Author: paolo Date: Thu Oct 4 00:02:29 2012 New Revision: 192056 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192056 Log: 2012-10-03 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/53248 * include/std/array (__array_traits): Add. (array): Allow for zero-size arrays of non default-constructible elements. * testsuite/23_containers/array/requirements/ non_default_constructible.cc: New. * testsuite/23_containers/array/requirements/zero_sized_arrays.cc: Adjust. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust dg-error line numbers. * testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/array/requirements/non_default_constructible.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/array trunk/libstdc++-v3/testsuite/23_containers/array/requirements/zero_sized_arrays.cc trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/get_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
[Bug libstdc++/53248] std::arrayT,0 doesn't work when T is not default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-04 00:03:26 UTC --- Fixed.
[Bug c++/53921] [C++0x] ICE on lambda inside method of class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53921 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-04 Blocks||54367 Ever Confirmed|0 |1
[Bug tree-optimization/54803] Rotates are not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54803 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Summary|Manual constant unfolding |Rotates are not vectorized |breaks vectorization| --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-04 00:14:52 UTC --- D.1826_10 = D.1825_9 r 32; So the rotate by 32 is not being vectorizered into two shift followed by an or.
[Bug c/54804] New: -Wuninitialized fails to warn about uninitialized local union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54804
Bug #: 54804
Summary: -Wuninitialized fails to warn about uninitialized
local union
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: egg...@gnu.org
This problem stems from a proposed change to Bison to work
around a GCC bug. I'd rather get the GCC bug fixed, so I'm
filing this bug report.
Bison-generated parsers currently contain code that GCC incorrectly
generates a -Wuninitialized warning for. In trying to fix this, I
discovered that GCC sometimes does not warn when it should. Compile
the following program with 'gcc -O2 -Wall -S'.
union YYSTYPE { int ival; };
union YYSTYPE
yyparse (void)
{
union YYSTYPE yylval;
return yylval;
}
struct s { int ival; };
struct s
yyparse_with_struct (void)
{
struct s xxlval;
return xxlval;
}
Here's what I observe, for the above program:
$ gcc -O2 -Wall -S t.i
t.i: In function 'yyparse_with_struct':
t.i:15:6: warning: 'xxlval.ival' is used uninitialized in this function
[-Wuninitialized]
There should be a warning for yylval, but the warning is missing.
The (correct) warning for xxlval suggests that the problem has
to do with unions, not structs.
[Bug target/54805] New: __gthread* on VxWorks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54805 Bug #: 54805 Summary: __gthread* on VxWorks Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@verizon.net Created attachment 28349 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28349 patch I originally posted this on -help, but, not getting anything back, I'm still pretty convinced this is a bug. Compiling for powerpc-wrs-vxworks for downloadable kernel modules, there are issues in vxlib-tls.c, which still references __gthread*tsd*. The only remaining declarations, however, are to __gthread*tls*. I added a conditional declaration of the __gthread*tsd* functions, and also noticed that one of the calls to __gthread_tsd_leave_dtor_context doesn't pass tcb. Also, it says that these functions are provided by the kernel, but I haven't been able to find any documentation to confirm this. Can someone confirm that these are in fact provided by the kernel? I'm citing http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01314.html for the old prototypes. The attached patch adds both the conditional declarations (on __RTP__) and the minor change to the function call. I'm not sure if this is what it *should* do, and I have no experience in this area, so deferring to the experts here.
[Bug middle-end/50598] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598 --- Comment #32 from Matt Arsenault whatmannerofburgeristhis at gmail dot com 2012-10-04 00:57:42 UTC --- Created attachment 28350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28350 Test case using packaged_task
[Bug middle-end/50598] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598 Matt Arsenault whatmannerofburgeristhis at gmail dot com changed: What|Removed |Added CC||whatmannerofburgeristhis at ||gmail dot com --- Comment #33 from Matt Arsenault whatmannerofburgeristhis at gmail dot com 2012-10-04 00:58:37 UTC --- I'm seeing this problem on 4.7.2 when using c++11 packaged_task. The same code worked yesterday with 4.7.1 before I updated.
[Bug middle-end/54806] New: [4.7.2 Regression] Undefined symbols: ___emutls_v.*, ... on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806 Bug #: 54806 Summary: [4.7.2 Regression] Undefined symbols: ___emutls_v.*, ... on *-apple-darwin* Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: whatmannerofburgerist...@gmail.com Host: *-apple-darwin* Target: *-apple-darwin* Build: *-apple-darwin* Reopening of #50598 I'm seeing this problem on 4.7.2 when using c++11 packaged_task. The same code worked yesterday with 4.7.1 before I updated.
[Bug middle-end/54806] [4.7.2 Regression] Undefined symbols: ___emutls_v.*, ... on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806 --- Comment #1 from Matt Arsenault whatmannerofburgeristhis at gmail dot com 2012-10-04 01:10:34 UTC --- Created attachment 28351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28351 packaged_task test case
[Bug c++/53921] [C++0x] ICE on lambda inside method of class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53921 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-04 01:21:42 UTC --- Dup. Again an INDIRECT_REF with null TREE_TYPE in lvalue_kind. *** This bug has been marked as a duplicate of bug 54403 ***
[Bug c++/54403] [C++11] operator! applied to a member of a templated class in a lambda expression that captures 'this' pointer crashes compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54403 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||philipp at fb dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-04 01:21:42 UTC --- *** Bug 53921 has been marked as a duplicate of this bug. ***
[Bug c++/52619] ICE/segmentation fault in lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52619 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-04 01:31:22 UTC --- Probably Dup of PR54403.
[Bug c++/52613] [C++11] ICE with noexcept in lambda expression in member function of class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52613 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-04 01:32:27 UTC --- Again probably Dup of PR54403.
[Bug c++/54807] New: Names declared in a for's for-init-statement and condition should be in the same declarative region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54807 Bug #: 54807 Summary: Names declared in a for's for-init-statement and condition should be in the same declarative region Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ulfali...@gmail.com for (int i; int i = 0;) should give an error but currently doesn't. 14882:2003 6.5.3.1: ...except that names declared in the for-init-statement are in the same declarative-region as those declared in the condition.
[Bug c++/54807] Names declared in a for's for-init-statement and condition should be in the same declarative region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54807 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-04 04:54:35 UTC --- I think this was fixed for 4.7. Even the porting guide for 4.7 mentions it.
[Bug c++/54807] Names declared in a for's for-init-statement and condition should be in the same declarative region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54807 --- Comment #2 from Ulf Magnusson ulfalizer at gmail dot com 2012-10-04 04:57:42 UTC --- Could very well be the same problem, but I don't have 4.7 handy to confirm.
