[Bug fortran/64381] New: ICE with initialization of procedure pointer in type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64381 Bug ID: 64381 Summary: ICE with initialization of procedure pointer in type Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Dear All the following code is producing an ICE with gcc 4.9.2. v cat gcc-4.9.2.f90 MODULE distribution_types_ IMPLICIT NONE ABSTRACT INTERFACE FUNCTION dist_map_proc_to_blk_raw_list_func ( ) RESULT( list ) INTEGER, DIMENSION(:,:), ALLOCATABLE :: list END FUNCTION dist_map_proc_to_blk_raw_list_func END INTERFACE TYPE, PUBLIC :: sm_type INTEGER, DIMENSION( : ), ALLOCATABLE :: proc_grid PROCEDURE( dist_map_proc_to_blk_raw_list_func ), NOPASS, POINTER :: map_proc_to_blk_raw_list = NULL( ) END TYPE sm_type CONTAINS SUBROUTINE sm_multiply ( ) TYPE(sm_type), ALLOCATABLE, DIMENSION(:) :: matrices_a ALLOCATE( matrices_a( 3 ) ) END SUBROUTINE sm_multiply END MODULE distribution_types_ gfortran-4.9.2 -c gcc-4.9.2.f90 gcc-4.9.2.f90: In function ‘sm_multiply’: gcc-4.9.2.f90:15:0: internal compiler error: in gfc_conv_descriptor_data_set, at fortran/trans-array.c:171 ALLOCATE( matrices_a( 3 ) ) ^ 0x5ebd56 gfc_conv_descriptor_data_set ../../gcc-4.9.2/gcc/fortran/trans-array.c:171 0x5ebd56 gfc_conv_descriptor_data_set(stmtblock_t*, tree_node*, tree_node*) ../../gcc-4.9.2/gcc/fortran/trans-array.c:166 0x5f370d structure_alloc_comps ../../gcc-4.9.2/gcc/fortran/trans-array.c:7785 0x5f305f structure_alloc_comps ../../gcc-4.9.2/gcc/fortran/trans-array.c:7646 0x5f4546 gfc_array_allocate(gfc_se*, gfc_expr*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node**, gfc_expr*, gfc_typespec*) ../../gcc-4.9.2/gcc/fortran/trans-array.c:5322 0x63c159 gfc_trans_allocate(gfc_code*) ../../gcc-4.9.2/gcc/fortran/trans-stmt.c:4952 0x5e8907 trans_code ../../gcc-4.9.2/gcc/fortran/trans.c:1794 0x6081f2 gfc_generate_function_code(gfc_namespace*) ../../gcc-4.9.2/gcc/fortran/trans-decl.c:5653 0x5e9e41 gfc_generate_module_code(gfc_namespace*) ../../gcc-4.9.2/gcc/fortran/trans.c:1995 0x5a7b60 translate_all_program_units ../../gcc-4.9.2/gcc/fortran/parse.c:4940 0x5a7b60 gfc_parse_file() ../../gcc-4.9.2/gcc/fortran/parse.c:5150 0x5e4be5 gfc_be_parse_file ../../gcc-4.9.2/gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug go/64005] make check FAIL: sync
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64005 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- Ian explained in an offline communication: It's more likely that with -O2 some dead pointers appears in a stack frame, and cause the garbage collector to think that the values are still live, and therefore they are not collected, and therefore they are not finalized. The gccgo garbage collector is not precise. Which pointers are left live in a stack frame varies a lot depending on processor and optimization level.
[Bug fortran/64173] [F03] ICE involving procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64173 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 64381 has been marked as a duplicate of this bug. ***
[Bug fortran/64381] ICE with initialization of procedure pointer in type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64381 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- I see the ICE with revision r218817, but is gone at r218817. I think this a duplicate of pr64173 fixed by r218834. *** This bug has been marked as a duplicate of bug 64173 ***
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 --- Comment #14 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Tue Dec 23 09:30:20 2014 New Revision: 219042 URL: https://gcc.gnu.org/viewcvs?rev=219042root=gccview=rev Log: Fix for PR ipa/63851 and ipa/63852. PR ipa/63851 PR ipa/63852 * ipa-icf.c (sem_function::merge): Ignore merge operation for a thunk created from static chain. * ipa-icf-gimple.c (func_checker::compatible_types_p): Verify that types have same restrict flag. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf-gimple.c trunk/gcc/ipa-icf.c
[Bug ipa/63852] [5 regression] acats failures on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63852 --- Comment #4 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Tue Dec 23 09:30:20 2014 New Revision: 219042 URL: https://gcc.gnu.org/viewcvs?rev=219042root=gccview=rev Log: Fix for PR ipa/63851 and ipa/63852. PR ipa/63851 PR ipa/63852 * ipa-icf.c (sem_function::merge): Ignore merge operation for a thunk created from static chain. * ipa-icf-gimple.c (func_checker::compatible_types_p): Verify that types have same restrict flag. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf-gimple.c trunk/gcc/ipa-icf.c
[Bug ipa/63852] [5 regression] acats failures on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63852 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug target/64379] VFP register restore in ARM epilogue can break indirect tailcalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379 --- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com --- I can reproduce the wrong-code with gcc-4.9.2 on armv7l-linux-gnueabi. Appears to need both -foptimize-sibling-calls and -mapcs-frame to trigger.
[Bug fortran/63640] move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|WAITING |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Joost VandeVondele from comment #4) seems more like an enhancement request to free allocatables at the end of main. I guess this is not mandated by the standard Right. The Fortran standard only requires the compiler to auto-deallocate variables which live inside a function/subroutine, but not those declared directly in the main program. Nevertheless gfortran did it up to version 4.8. I verified that compiling with 4.8.3. does not show any memory leaks. The auto-deallocation of variables in the main program was removed in 4.9, because it can alter the run-time behavior with FINAL routines, so one should better stick to the standard and *not* do it. It's the programmer's responsibility to deallocate variables in the main program, and the easiest way to get rid of the valgrind warnings is to do explicitly do this: program testmv3 type bar integer, allocatable :: ia(:), ja(:) end type integer, allocatable :: ia(:), ja(:) type(bar), allocatable :: sm,sm2 allocate(sm) allocate(sm2) allocate(sm%ia(100),sm%ja(100)) allocate(sm2%ia(1000),sm2%ja(1000)) allocate(ia(100),ja(1000)) call move_alloc(ja,ia) call move_alloc(sm%ia,sm2%ia) call move_alloc(sm%ja,sm2%ja) deallocate(ia,sm2%ia,sm2%ja) deallocate(sm,sm2) end program testmv3 This program does not show any leaks. The leaks you were seeing are definitely not due to any problem with MOVE_ALLOC.
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #13 from manfred.rudigier at omicron dot at --- (In reply to Dan Wilder from comment #12) I have a backport of the patches referenced in comment 4, which I applied to the gcc-4.8.3 we are using for e500v2. If anybody would care to look at it, comment whether it has any merit at all, try it etc, I'd be honored. I have applied your backported patches to gcc 4.8.4 and can confirm that they fix this issue. Thanks!
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #16 from janus at gcc dot gnu.org --- Author: janus Date: Tue Dec 23 10:51:32 2014 New Revision: 219043 URL: https://gcc.gnu.org/viewcvs?rev=219043root=gccview=rev Log: 2014-12-23 Janus Weil ja...@gcc.gnu.org Backport from mainline PR fortran/64244 * resolve.c (resolve_typebound_call): New argument to pass out the non-overridable attribute of the specific procedure. (resolve_typebound_subroutine): Get overridable flag from resolve_typebound_call. 2014-12-23 Janus Weil ja...@gcc.gnu.org Backport from mainline PR fortran/64244 * gfortran.dg/typebound_call_26.f90: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/typebound_call_26.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/resolve.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c++/64382] New: ICE due to use of `this` inside a lambda that captures everything by ref inside a member function of a class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64382
Bug ID: 64382
Summary: ICE due to use of `this` inside a lambda that captures
everything by ref inside a member function of a class
template
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
templatetypename T
struct my_queue {
void push(T){
}
void ice(){
trav([](auto v){ push(v); });
}
templatetypename F
void trav(F f){
f(T());
}
};
template class my_queueint;
-
E:\Desktopg++ -c test.cpp -std=c++14
test.cpp: In lambda function:
test.cpp:6:29: internal compiler error: Segmentation fault
trav([](auto v){ push(v); });
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://sourceforge.net/projects/mingw-w64 for instructions.
[Bug c++/64383] New: missed warning for unused variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64383
Bug ID: 64383
Summary: missed warning for unused variable.
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
#include memory
#include vector
int main()
{
std::vector std::shared_ptr int v1;
v1.push_back( std::make_shared int ( 7 ) );
for( auto p : v1 )
{
}
std::vector int v2;
v2.push_back( 7 );
for( auto i : v2 )
{
}
}
the 'p' variable is not reported as unused.
% LANG=C g++ -Wall -g2 t.cpp -o t -std=c++1y
t.cpp: In function 'int main()':
t.cpp:13:15: warning: unused variable 'i' [-Wunused-variable]
for( auto i : v2 )
^
[Bug target/64384] New: mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384 Bug ID: 64384 Summary: mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mity at morous dot org When using COM interface (i.e. calling stdcall function/method), aggregates are returned through an implicit parameter after the this/interface pointer, according to MS ABI. However it is not so when using gcc. This issue manifests itself when e.g. calling ID2D1RenderTarget::GetSize() from d2d1.h as discussed here: https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/?style=threadedviewmonth=201412viewday=23 Wine team encountered the issue too, they seem to solve the issue on their side by ugly hacks and changing prototypes of the relevant functions for now: https://www.winehq.org/pipermail/wine-patches/2014-September/134351.html
[Bug target/64384] mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384 Jacek Caban jacek at codeweavers dot com changed: What|Removed |Added CC||jacek at codeweavers dot com --- Comment #1 from Jacek Caban jacek at codeweavers dot com --- FWIW the issue is not specific to COM interfaces. It affects all stdcall functions.
[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372 --- Comment #7 from Harald van Dijk harald at gigawatt dot nl --- (In reply to Manuel López-Ibáñez from comment #6) Even that is probably too much right now. :) I do hope to be able to make some bigger contributions in the future (in code too), and I really appreciate your comment.
[Bug c++/64385] New: odd behaviour of std::is_move_constructible std::ostringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64385 Bug ID: 64385 Summary: odd behaviour of std::is_move_constructible std::ostringstream Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alan at birtles dot org.uk Created attachment 34320 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34320action=edit file to reproduce the bug When compiling the attached code without A defined the code outputs 0, 0 which is expected as std::ostringstream doesn't have a move constructor in gcc 4.9. However when A is defined the code outputs 1, 1 which is incorrect. Compiled with g++ test.cpp -std=c++11 -D A on Ubuntu 14.10. g++ --version: g++ (Ubuntu 4.9.1-16ubuntu6) 4.9.1
[Bug target/64384] mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- The attribute 'callee_pop_aggregate_return' should fix this issue for you. This is a general difference between sysv and ms ABIs. It has in general nothing to do with the stdcall-attribute.
[Bug fortran/35423] Implement OpenMP workshare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35423 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR is more than five years old and seems (mostly) fixed. Any reason to keep it open?
[Bug fortran/63640] move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to janus from comment #5) Right. The Fortran standard only requires the compiler to auto-deallocate variables which live inside a function/subroutine, but not those declared directly in the main program. On the other hand, allocated data should appear as still reachable at the end of the program; so the bug is we lose the pointers just before exiting?
[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is it fixed or not after r215293?
[Bug target/64379] VFP register restore in ARM epilogue can break indirect tailcalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com, ||vmakarov at gcc dot gnu.org --- Comment #6 from Mikael Pettersson mikpelinux at gmail dot com --- Started with r204752, still occurs with today's trunk. Author CC:d. Note this may turn out to be a target bug, like PR62662 which also started at this revision. Note 2: r204752 causes cc1 to crash and hang deep inside glibc on my system, I also have to apply r204771 to unbreak it.
[Bug target/64379] VFP register restore in ARM epilogue can break indirect tailcalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379 --- Comment #7 from Donn Seeley donn.seeley at windriver dot com --- Re -mapcs-frame: Yes, the failure is due to code in arm_expand_epilogue_apcs_frame() that explicitly requires / stomps on IP in order to restore VFP/NEON registers. Sorry, I should have mentioned that. The indirect tailcall register is chosen from CALLER_SAVE_REGS via the Cs constraint, and CALLER_SAVE_REGS contains the arg regs plus IP; if the arg regs are in use, then the tailcall register ends up being IP. Hence the conflict.
[Bug target/64386] New: ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64386 Bug ID: 64386 Summary: ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512bw Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34321 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34321action=edit reduced testcase (from gcc.dg/vect/vect-cond-7.c) Compiler output: $ gcc -O -ftree-vectorize -mavx512bw testcase.c testcase.c: In function 'fc': testcase.c:11:1: error: unrecognizable insn: } ^ (insn 13 12 14 2 (set (reg:DI 98) (eq:DI (reg:V64QI 88 [ vect__6.8 ]) (reg:V64QI 97))) testcase.c:9 -1 (nil)) testcase.c:11:1: internal compiler error: in extract_insn, at recog.c:2327 0xbd9d78 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl-error.c:110 0xbd9e08 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl-error.c:118 0xb903b8 extract_insn(rtx_insn*) /mnt/svn/gcc-trunk/gcc/recog.c:2327 0x96eecd instantiate_virtual_regs_in_insn /mnt/svn/gcc-trunk/gcc/function.c:1582 0x96eecd instantiate_virtual_regs /mnt/svn/gcc-trunk/gcc/function.c:1950 0x96eecd execute /mnt/svn/gcc-trunk/gcc/function.c:1999 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r219043 - ICE
[Bug bootstrap/25508] MULTILIB_OSDIRNAMES undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25508 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- The point isn't documenting the rationale for particular choices, it's documenting (in fragments.texi) the general semantics, including for the A=B and A=!B forms. It looks like the documentation was added by r193508 | doko | 2012-11-14 21:29:15 + (Wed, 14 Nov 2012) | 36 lines but without closing this bug.
[Bug target/64387] New: ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -ffloat-store -mavx512er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64387 Bug ID: 64387 Summary: ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -ffloat-store -mavx512er Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34322 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34322action=edit reduced testcase Compiler output: $ gcc -O2 -ftree-vectorize -ffloat-store -mavx512er testcase.c testcase.c: In function 'foo': testcase.c:12:1: error: unrecognizable insn: } ^ (insn 43 42 44 4 (set (reg:V8SF 121) (vec_select:V8SF (mem/c:V16SF (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -128 [0xff80])) [1 vect__10.6+0 S64 A512]) (parallel [ (const_int 8 [0x8]) (const_int 9 [0x9]) (const_int 10 [0xa]) (const_int 11 [0xb]) (const_int 12 [0xc]) (const_int 13 [0xd]) (const_int 14 [0xe]) (const_int 15 [0xf]) ]))) testcase.c:9 -1 (nil)) testcase.c:12:1: internal compiler error: in extract_insn, at recog.c:2327 0xbd9d78 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl-error.c:110 0xbd9e08 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl-error.c:118 0xb903b8 extract_insn(rtx_insn*) /mnt/svn/gcc-trunk/gcc/recog.c:2327 0x96eecd instantiate_virtual_regs_in_insn /mnt/svn/gcc-trunk/gcc/function.c:1582 0x96eecd instantiate_virtual_regs /mnt/svn/gcc-trunk/gcc/function.c:1950 0x96eecd execute /mnt/svn/gcc-trunk/gcc/function.c:1999 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r219043 - ICE 4_9 r219040 - OK
[Bug middle-end/64388] New: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 Bug ID: 64388 Summary: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: danglin at gcc dot gnu.org On Linux/x86-64, r219037 caused FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = (2|3) FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final insn[: ][^\n]*set \\(mem(?![^\n]*scratch)
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |5.0
[Bug tree-optimization/64277] [4.9/5.0 Regression] Incorrect warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #1 from Igor Zamyatin izamyatin at gmail dot com --- Warnings are issued by vrp2. It happens when we have both vector and scalar versions of code. Something seems to confuse VRP analysis, probably the reason is that m and nc are shorts. Changing them to int makes warnings disappear
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #12 from Mikael Pettersson mikpelinux at gmail dot com --- Created attachment 34323 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34323action=edit patch restricting the X % -Y - X % Y transformation to when it's safe This proposed patch restricts the X % -Y - X % Y transformation to cases when we can be certain that it doesn't result in undefined behaviour, i.e. when Y != 1 or X != INT_MIN. Passes bootstrap and testsuite on x86_64-linux so far.
[Bug bootstrap/64389] New: duplicate symbols in libstdc++.6.dylib on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64389 Bug ID: 64389 Summary: duplicate symbols in libstdc++.6.dylib on darwin Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: howarth at bromo dot med.uc.edu At r219042, I am unable to bootstrap on darwin due to a duplicate symbols linkage error when linking libstdc++.6.dylib in stage1-bubble. make[6]: Entering directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/src' /bin/sh ../libtool --tag CXX --mode=link /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/src -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/libsupc++/.libs -B/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/bin/ -B/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/lib/ -isystem /sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/include -isystem /sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/sys-include -Wl,-single_module -fno-common -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:21:0 -Wl,-exported_symbols_list,libstdc++-symbols.explist -lm -rpath /sw/lib/gcc5.0/lib compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-c++0x.lo compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la libtool: link: /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/src -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/libsupc++/.libs -B/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/bin/ -B/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/lib/ -isystem /sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/include -isystem /sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/sys-include-dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libstdc++.6.dylib .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-force_load,../libsupc++/.libs/libsupc++convenience.a -Wl,-force_load,../src/c++98/.libs/libc++98convenience.a -Wl,-force_load,../src/c++11/.libs/libc++11convenience.a -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/libsupc++/.libs -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/src -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/src/.libs -lm -Wl,-single_module -Wl,-exported_symbols_list -Wl,libstdc++-symbols.explist -install_name /sw/lib/gcc5.0/lib/libstdc++.6.dylib -compatibility_version 7 -current_version 7.21 -Wl,-single_module ... duplicate symbol std::__cxx11::time_getchar, std::istreambuf_iteratorchar, std::char_traitschar ::do_get(std::istreambuf_iteratorchar, std::char_traitschar , std::istreambuf_iteratorchar, std::char_traitschar , std::ios_base, std::_Ios_Iostate, tm*, char, char) const in: ../src/c++11/.libs/libc++11convenience.a(cxx11-locale-inst.o) ../src/c++11/.libs/libc++11convenience.a(string-inst.o) duplicate symbol std::__cxx11::time_getchar, std::istreambuf_iteratorchar, std::char_traitschar ::get(std::istreambuf_iteratorchar, std::char_traitschar , std::istreambuf_iteratorchar, std::char_traitschar , std::ios_base, std::_Ios_Iostate, tm*, char, char) const in: ../src/c++11/.libs/libc++11convenience.a(cxx11-locale-inst.o) ../src/c++11/.libs/libc++11convenience.a(string-inst.o) duplicate symbol std::__cxx11::time_getchar, std::istreambuf_iteratorchar, std::char_traitschar ::get(std::istreambuf_iteratorchar, std::char_traitschar , std::istreambuf_iteratorchar, std::char_traitschar , std::ios_base, std::_Ios_Iostate, tm*, char const*, char const*) const in: ../src/c++11/.libs/libc++11convenience.a(cxx11-locale-inst.o) ../src/c++11/.libs/libc++11convenience.a(string-inst.o) duplicate symbol
[Bug bootstrap/64389] duplicate symbols in libstdc++.6.dylib on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64389 howarth at bromo dot med.uc.edu changed: What|Removed |Added Target||x86_64-apple-darwin14 Host||x86_64-apple-darwin14 Build||x86_64-apple-darwin14 --- Comment #1 from howarth at bromo dot med.uc.edu --- Configured as... ../gcc-5-20141223/configure --prefix=/sw --prefix=/sw/lib/gcc5.0 --mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-5.0
[Bug ipa/64390] New: -shared does not resolve symbols from lto generated archives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64390 Bug ID: 64390 Summary: -shared does not resolve symbols from lto generated archives Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: htl10 at users dot sourceforge.net Upgrading to 4.9.2 from 4.8.x, building R (http://www.r-project.org) with fto fails. (./configure --enable-lto AR=gcc-ar). Specifically, it builds a few static archives of external libraries then tries build a shared libraries out of it. A simplified procedure is like this: gcc -flto -c -o routine1.o routine1.c ... gcc -flto -c -o used_by_routine1.o used_by_routine1.c ... gcc-ar cr libextra.a used_by_routine1.o ... ... gcc -shared -o liboutput.so routine1.o ... libextra.a ... the output shared library is not able to resolve any symbols with libextra.a's content. I found two workarounds: - putting all the dependent *.o on the command line instead of the archive itself. - prepending/appending the extra libraries with the whole archive linker directives: i.e. -Wl,--whole-archive ../extra/tre/libtre.a -Wl,--no-whole-archive I realise generating shared libraries from static archive is daft, but that's how R is built.
[Bug middle-end/64391] New: ICE: SIGSEGV in get_attrs_for (trans-mem.c:179) with -fgnu-tm and #pragma GCC ivdep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64391 Bug ID: 64391 Summary: ICE: SIGSEGV in get_attrs_for (trans-mem.c:179) with -fgnu-tm and #pragma GCC ivdep Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34324 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34324action=edit reduced testcase Compiler output: $ gcc -fgnu-tm testcase.c -wrapper valgrind,-q ==19617== Invalid read of size 2 ==19617==at 0xC5B0A4: get_attrs_for(tree_node const*) (trans-mem.c:179) ==19617==by 0xC5DE28: is_tm_may_cancel_outer(tree_node*) (trans-mem.c:320) ==19617==by 0xC5E147: diagnose_tm_1(gimple_stmt_iterator*, bool*, walk_stmt_info*) (trans-mem.c:668) ==19617==by 0x9FC9CE: walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.c:551) ==19617==by 0x9FCC08: walk_gimple_seq_mod(gimple_statement_base**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.c:66) ==19617==by 0x9FCAB2: walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.c:579) ==19617==by 0x9FCC08: walk_gimple_seq_mod(gimple_statement_base**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.c:66) ==19617==by 0x9FCCA6: walk_gimple_seq(gimple_statement_base*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) (gimple-walk.c:96) ==19617==by 0xC5DEC2: diagnose_tm_blocks (trans-mem.c:862) ==19617==by 0xC5DEC2: (anonymous namespace)::pass_diagnose_tm_blocks::execute(function*) (trans-mem.c:891) ==19617==by 0xB5E85E: execute_one_pass(opt_pass*) (passes.c:2311) ==19617==by 0xB5ECD5: execute_pass_list_1(opt_pass*) [clone .constprop.73] (passes.c:2363) ==19617==by 0xB5ED28: execute_pass_list(function*, opt_pass*) (passes.c:2374) ==19617== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==19617== testcase.c: In function 'foo': testcase.c:2:1: internal compiler error: Segmentation fault foo (void) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r219043 - ICE 4_9 r219040 - ICE 4_8 - ignoring #pragma GCC ivdep
[Bug ipa/64390] -shared does not resolve symbols from lto generated archives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64390 --- Comment #1 from Hin-Tak Leung htl10 at users dot sourceforge.net --- $ gcc -v Using built-in specs. COLLECT_GCC=/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) ar comes from: binutils-2.24-30.fc21.x86_64 There is a lto related build in binutils-2.24-29- .
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #17 from janus at gcc dot gnu.org --- Author: janus Date: Tue Dec 23 19:06:23 2014 New Revision: 219047 URL: https://gcc.gnu.org/viewcvs?rev=219047root=gccview=rev Log: 2014-12-23 Janus Weil ja...@gcc.gnu.org Backport from mainline PR fortran/64244 * resolve.c (resolve_typebound_call): New argument to pass out the non-overridable attribute of the specific procedure. (resolve_typebound_subroutine): Get overridable flag from resolve_typebound_call. 2014-12-23 Janus Weil ja...@gcc.gnu.org Backport from mainline PR fortran/64244 * gfortran.dg/typebound_call_26.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/typebound_call_26.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/resolve.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/64389] duplicate symbols in libstdc++.6.dylib on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64389 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-23 CC||redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Patch: jwakely dominiq: this should fix it http://paste.fedoraproject.org/162240/19281414 Still not committed after almost 24 hours.
[Bug middle-end/64392] New: ICE: in pdr_stride_in_loop, at graphite-interchange.c:261 (isl_val_gmp.c:47: expecting rational value) with -floop-interchange -floop-strip-mine --param=loop-block-tile-siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64392 Bug ID: 64392 Summary: ICE: in pdr_stride_in_loop, at graphite-interchange.c:261 (isl_val_gmp.c:47: expecting rational value) with -floop-interchange -floop-strip-mine --param=loop-block-tile-size=0 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34325 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34325action=edit reduced testcase Compiler output: $ gcc -O2 -floop-interchange -floop-strip-mine --param=loop-block-tile-size=0 testcase.c /var/tmp/portage/dev-libs/isl-0.12.2/work/isl-0.12.2/isl_val_gmp.c:47: expecting rational value testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: Aborted foo (void) ^ 0xc5819f crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:359 0x17581b9 pdr_stride_in_loop /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:261 0x17581b9 memory_strides_in_loop_1 /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:293 0x17627d4 lst_interchange_profitable_p /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:410 0x17627d4 lst_try_interchange_loops /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:547 0x17627d4 lst_interchange_select_inner /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:610 0x17655bf lst_interchange_select_outer /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:636 0x176560d lst_interchange_select_outer /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:646 0x176567b scop_do_interchange(scop*) /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:658 0x168c65a apply_poly_transforms(scop*) /mnt/svn/gcc-trunk/gcc/graphite-poly.c:272 0x1687783 graphite_transform_loops() /mnt/svn/gcc-trunk/gcc/graphite.c:302 0x1687db0 graphite_transforms /mnt/svn/gcc-trunk/gcc/graphite.c:331 0x1687db0 execute /mnt/svn/gcc-trunk/gcc/graphite.c:412 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r219043 - ICE
[Bug target/64393] New: ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64393 Bug ID: 64393 Summary: ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512vbmi Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34326 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34326action=edit reduced testcase Compiler output: $ gcc -O -mavx512vbmi testcase.c testcase.c: In function 'foo': testcase.c:9:1: error: unrecognizable insn: } ^ (insn 63 60 61 4 (set (reg:SI 69 k0 [orig:124 D.2715 ] [124]) (xor:SI (reg:SI 70 k1 [orig:105 ivtmp.6 ] [105]) (reg:SI 71 k2 [orig:111 ivtmp.9 ] [111]))) testcase.c:7 -1 (nil)) testcase.c:9:1: internal compiler error: in extract_insn, at recog.c:2327 0xbd9d78 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl-error.c:110 0xbd9e08 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl-error.c:118 0xb903b8 extract_insn(rtx_insn*) /mnt/svn/gcc-trunk/gcc/recog.c:2327 0xb90467 extract_insn_cached(rtx_insn*) /mnt/svn/gcc-trunk/gcc/recog.c:2218 0x924569 cleanup_subreg_operands(rtx_insn*) /mnt/svn/gcc-trunk/gcc/final.c:3124 0xb8be79 split_insn /mnt/svn/gcc-trunk/gcc/recog.c:2937 0xb9406d split_all_insns() /mnt/svn/gcc-trunk/gcc/recog.c:2991 0xb94188 rest_of_handle_split_after_reload /mnt/svn/gcc-trunk/gcc/recog.c:3938 0xb94188 execute /mnt/svn/gcc-trunk/gcc/recog.c:3967 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r219043 - ICE
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from janus at gcc dot gnu.org --- By now I have backported the fix to the 4.9 and 4.8 branches. Closing. Thanks again for the report!
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Mikael Pettersson from comment #12) Created attachment 34323 [details] patch restricting the X % -Y - X % Y transformation to when it's safe This proposed patch restricts the X % -Y - X % Y transformation to cases when we can be certain that it doesn't result in undefined behaviour, i.e. when Y != 1 or X != INT_MIN. Passes bootstrap and testsuite on x86_64-linux so far. Shouldn't disabling this be language dependent ? I.e. in Fortran this transformation is always valid (as integers in conforming programs are always in the symmetric range).
[Bug middle-end/64391] ICE: SIGSEGV in get_attrs_for (trans-mem.c:179) with -fgnu-tm and #pragma GCC ivdep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64391 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz --- Many gfortran testcases fail with the same backtrace when -fgnu-tm is used.
[Bug target/64386] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64386 Kirill Yukhin kyukhin at gcc dot gnu.org changed: What|Removed |Added CC||kyukhin at gcc dot gnu.org --- Comment #1 from Kirill Yukhin kyukhin at gcc dot gnu.org --- We'll look at this. Thanks for catching!
[Bug middle-end/64394] New: ICE: in build_linearized_memory_access, at graphite-interchange.c:121 (isl_constraint.c:558: expecting integer value) with -floop-interchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64394 Bug ID: 64394 Summary: ICE: in build_linearized_memory_access, at graphite-interchange.c:121 (isl_constraint.c:558: expecting integer value) with -floop-interchange Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34327 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34327action=edit reduced testcase Compiler output: $ gcc -O2 -floop-interchange testcase.c /var/tmp/portage/dev-libs/isl-0.12.2/work/isl-0.12.2/isl_constraint.c:558: expecting integer value testcase.c: In function 'foo': testcase.c:10:1: internal compiler error: Aborted foo (void) ^ 0xc5819f crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:359 0x1757f91 build_linearized_memory_access /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:121 0x1757f91 pdr_stride_in_loop /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:207 0x1757f91 memory_strides_in_loop_1 /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:293 0x17627d4 lst_interchange_profitable_p /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:410 0x17627d4 lst_try_interchange_loops /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:547 0x17627d4 lst_interchange_select_inner /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:610 0x17655bf lst_interchange_select_outer /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:636 0x176560d lst_interchange_select_outer /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:646 0x176567b scop_do_interchange(scop*) /mnt/svn/gcc-trunk/gcc/graphite-interchange.c:658 0x168c65a apply_poly_transforms(scop*) /mnt/svn/gcc-trunk/gcc/graphite-poly.c:272 0x1687783 graphite_transform_loops() /mnt/svn/gcc-trunk/gcc/graphite.c:302 0x1687db0 graphite_transforms /mnt/svn/gcc-trunk/gcc/graphite.c:331 0x1687db0 execute /mnt/svn/gcc-trunk/gcc/graphite.c:412 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r219043 - ICE
[Bug c++/64395] New: void_t doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64395
Bug ID: 64395
Summary: void_t doesn't work as expected
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: benzejaa at gmail dot com
Hey all!
I have what I *think* is a bug in gcc-4.9.2. I haven't tested it against the
development version (mostly due to a lack of free time).
I was messing around with void_t concepts, and GCC didn't give me the
expected behavior. I compared to clang, which did give me what I expected, so
my assumption is that of a bug in GCC.
This may be a duplicate under a different name (I find it hard to believe I was
the first person to find the bug), but I couldn't find one.
Here's my test code:
#includeiostream
#includeutility
#includetype_traits
template class... using void_t = void;
template class, class = void
struct hasSize : std::false_type {};
template class T
struct hasSize T, void_t decltype( std::declvalconst T().size()) :
std::true_type {};
int main()
{
std::cout hasSize std::string ::value std::endl;
std::cout hasSize char ::value std::endl;
return 0;
}
compiled as g++ -std=c++11 main.cpp, I get the output:
1
1
and compiled as clang++ -std=c++11 main.cpp, I get the output:
1
0
As one would expect the second value to be false, this to me indicates a bug
in g++.
Cheers!
[Bug tree-optimization/64277] [4.9/5.0 Regression] Incorrect warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I cannot reproduce this in GCC 5.0 with or without -msse3 (on x86_64-linux-gnu). I always get: test.c: In function ‘foo’: test.c:12:14: warning: ‘f1’ may be used uninitialized in this function [-Wmaybe-uninitialized] f1[i] = f1[i] + 1; ^ which seems correct. In any case, warning about f1[i] being above array bounds would be correct: there is no check that i 10.
[Bug target/64393] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64393 Kirill Yukhin kyukhin at gcc dot gnu.org changed: What|Removed |Added CC||kyukhin at gcc dot gnu.org --- Comment #1 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Thanks for catching! We'll look at this.
[Bug ipa/64390] -shared does not resolve symbols from lto generated archives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64390 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-23 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Can you try binutils 2.25?
[Bug c/64396] New: Missed optimization in post-loop register handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64396
Bug ID: 64396
Summary: Missed optimization in post-loop register handling
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
I noticed a missed opportunity in GCC that Clang and ICC seem to take advantage
of. All versions of GCC I tested (up to 4.9.0) seem to have the same trouble.
The following source (for x86_64) shows up the problem:
-
#include stdint.h
#define add_carry32(sum, v) __asm__(addl %1, %0 ; \
adcl $0, %0 ; \
: =r (sum) \
: g ((uint32_t) v), 0 (sum))
unsigned sorta_checksum(const void* src, int n, unsigned sum)
{
const uint32_t *s4 = (const uint32_t*) src;
const uint32_t *es4 = s4 + (n 2);
while( s4 != es4 ) {
add_carry32(sum, *s4++);
}
add_carry32(sum, *(const uint16_t*) s4);
return sum;
}
-
$ g++ -O3 path-to-file -c
$ objdump file.o
...
10:74 24je 36 _Z14sorta_checksumPKvij+0x36
12:66 0f 1f 44 00 00nopw 0x0(%rax,%rax,1)
18:03 11add(%rcx),%edx
1a:83 d2 00 adc$0x0,%edx
1d:48 83 c1 04 add$0x4,%rcx
21:48 39 c8 cmp%rcx,%rax
24:75 f2jne18 _Z14sorta_checksumPKvij+0x18
26:48 8d 4f 04 lea0x4(%rdi),%rcx
2a:48 29 c8 sub%rcx,%rax
2d:48 c1 e8 02 shr$0x2,%rax
31:48 8d 4c 87 04 lea0x4(%rdi,%rax,4),%rcx
...
(the example is a contrived version of the original code, which comes
from Solarflare's OpenOnload project).
GCC optimizes the loop but then re-calculates the s4 variable outside of the
loop (offsets 26 through 31 in the above code) before the last add_carry32.
ICC and Clang both realise that the 's4' value in the loop is fine to re-use.
GCC has an extra four instructions to calculate the same value known to be in a
register upon loop exit.
Compiler explorer links:
GCC 4.9.0: http://goo.gl/fi3p2J
ICC 13.0.1: http://goo.gl/PRTTc6
Clang 3.4.1: http://goo.gl/95JEQc
[Bug c++/64383] missed warning for unused variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64383 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- A minimized testcase would be helpful. Using delta would probably remove already a lot: https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
[Bug middle-end/64396] Missed optimization in post-loop register handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64396
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
The reason is GCC tries to be smart of calculating s4 outside of the loop
because the iv that might be selected is not related at all to s4. That is it
might do:
int limit = es4-s4;
int i = 0;
for(i=0;ilimit;i++) {
add_carry32(sum, *s4[i]);
}
[Bug tree-optimization/64277] [4.9/5.0 Regression] Incorrect warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277 --- Comment #3 from Alexander Ivchenko aivchenk at gmail dot com --- You need to specify -mssse3 (not -msse3). Warning about array bounds is not correct, because gcc does not know how this function is being called.
[Bug c/38716] Undocumented __attribute__((optimize)) behaviour when the attribute specifies no optimisation level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38716 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Probably a dup of PR63401
[Bug fortran/64397] New: memory allocation failed with parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 Bug ID: 64397 Summary: memory allocation failed with parenthesis Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Hi all, I want to report a bug which i describe orignially here, https://gcc.gnu.org/ml/fortran/2014-12/msg00117.html . The expression (a+b) works well, while ((a)+(b)) triggers a memory allocation issue. And its works fine, if there is no allocatable components in the type. Janus Weil worked out a reduce test case below, and can reproduce the segfault with various versions of gfortran (4.7, 4.8, 4.9 and trunk) : module num type :: my_integer real, allocatable :: x(:) contains procedure :: ass generic :: assignment(=) = ass end type contains subroutine ass(a,b) class(my_integer), intent(out) :: a class(my_integer), intent(in) :: b select type (b) type is (my_integer) allocate(a%x(size(b%x))) a%x = b%x end select print *,'called ass' end subroutine end module program main use num type(my_integer) :: a, c a=my_integer([1]) write (*,*) C: ,c%x c = a write (*,*) C: ,c%x c = (a) write (*,*) C: ,c%x end Thanks Pat.
[Bug bootstrap/64389] duplicate symbols in libstdc++.6.dylib on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64389 --- Comment #3 from howarth at bromo dot med.uc.edu --- (In reply to Dominique d'Humieres from comment #2) Patch: jwakely dominiq: this should fix it http://paste.fedoraproject.org/162240/19281414 Still not committed after almost 24 hours. I can confirm the proposed patch resolves the bootstrap failure here on darwin14.
[Bug fortran/64397] [OOP] Runtime segfault with type-bound assignment and parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-23 CC||janus at gcc dot gnu.org Summary|memory allocation failed|[OOP] Runtime segfault with |with parenthesis|type-bound assignment and ||parenthesis Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I'm not actually sure that the segfault is related to memory allocation. In any case, the output of the test case in comment 0 is: $ ./a.out called ass C: called ass C:1. called ass Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F73005265F7 #1 0x7F7300526C3E #2 0x7F72FFA23D9F #3 0x7F72FFA85B5E #4 0x401926 in MAIN__ at c0.f90:32 (discriminator 1) Speicherzugriffsfehler (Speicherabzug geschrieben) This means that the call to 'ass' generated from 'c = (a)' is performed alright, but something goes wrong after that. Possibly related to cleaning up a temporary which is generated for '(a)'?
[Bug fortran/64397] [OOP] Runtime segfault with type-bound assignment and parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397
--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The difference in the dumps for
program main
use num
type(my_integer) :: a, c
a=my_integer([1])
c = a ! -
end
and
program main
use num
type(my_integer) :: a, c
a=my_integer([1])
c = (a) ! +
end
is
--- pr64397_red.f90.003t.original2014-12-23 22:44:37.0 +0100
+++ pr64397_red_1.f90.003t.original2014-12-23 22:45:12.0 +0100
@@ -276,7 +276,7 @@ ass (struct __class_num_My_integer_t r
{
if (a-_data-x.data != 0B)
{
- _gfortran_runtime_error_at (At line 17 of file
pr64397_red.f90[1]{lb: 1 sz: 1}, Attempting to allocate already allocated
variable \'%s\'[1]{lb: 1 sz: 1}, a[1]{lb: 1 sz: 1});
+ _gfortran_runtime_error_at (At line 17 of file
pr64397_red_1.f90[1]{lb: 1 sz: 1}, Attempting to allocate already allocated
variable \'%s\'[1]{lb: 1 sz: 1}, a[1]{lb: 1 sz: 1});
}
else
{
@@ -445,14 +445,40 @@ MAIN__ ()
class.11._data-x.data = 0B;
}
{
+void * restrict D.3563;
+integer(kind=8) D.3562;
+integer(kind=8) D.3561;
+integer(kind=8) D.3560;
+struct __class_num_My_integer_t D.3559;
+struct my_integer D.3558;
struct __class_num_My_integer_t class.16;
struct __class_num_My_integer_t class.15;
class.15._vptr = (struct __vtype_num_My_integer * {ref-all})
__vtab_num_My_integer;
class.15._data = (struct my_integer *) c;
class.16._vptr = (struct __vtype_num_My_integer * {ref-all})
__vtab_num_My_integer;
-class.16._data = (struct my_integer *) a;
+D.3558 = a;
+class.16._data = (struct my_integer *) D.3558;
+D.3559 = class.16;
ass (class.15, class.16);
+if ((void *) D.3559.x.data != 0B)
+ {
+D.3560 = (D.3559.x.dim[0].ubound - D.3559.x.dim[0].lbound) + 1;
+D.3561 = NON_LVALUE_EXPR D.3560;
+ }
+if (class.16._data-x.data != 0B)
+ {
+__builtin_free ((void *) class.16._data-x.data);
+ }
+class.16._data-x.data = 0B;
}
}
[Bug fortran/64397] [OOP] Runtime segfault with type-bound assignment and parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #3 from janus at gcc dot gnu.org --- Actually one can reduce it even further: program main type :: my_integer real, allocatable :: x(:) end type type(my_integer) :: a a=my_integer([1]) write (*,*) A call ass(a) write (*,*) B call ass((a)) write (*,*) C contains subroutine ass(b) class(my_integer), intent(in) :: b print *,'called ass' end subroutine end This program does not do anything useful any more, but it still shows the same segfault at/after the call to ass((a)): $ ./a.out A called ass B called ass Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Making 'b' a TYPE instead of a CLASS makes the error go away.
[Bug c++/64398] New: decltype in different contexts with similar expressions triggers segfault in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64398
Bug ID: 64398
Summary: decltype in different contexts with similar
expressions triggers segfault in GCC
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: florian.we...@sfz-bw.de
The following code triggers an internal segmentation-fault in GCC:
templatetypename T struct template1;
templatetypename T, typename // second param required
struct struct1{
using type1 = decltype(T::x);
using type2 = template1type1;
};
templatetypename T using alias1 = template1decltype(T::x);
// just for instantiation:
templatetypename T using alias2 = alias1T;
$ uname -a
Linux terra 3.14.27-1-lts #1 SMP Wed Dec 17 19:29:45 CET 2014 x86_64 GNU/Linux
$ g++ -v -save-temps -std=c++11 -c demo.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9.2/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-isl-version-check
--disable-cloog-version-check --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -E -quiet -v -D_GNU_SOURCE
demo.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o demo.ii
ignoring nonexistent directory
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/backward
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
/usr/local/include
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -fpreprocessed demo.ii
-quiet -dumpbase demo.cpp -mtune=generic -march=x86-64 -auxbase demo -std=c++11
-version -o demo.s
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p10,
MPC version 1.0.2
warning: MPFR header version 3.1.2-p10 differs from library version 3.1.2-p11.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p10,
MPC version 1.0.2
warning: MPFR header version 3.1.2-p10 differs from library version 3.1.2-p11.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f6f21876c758a79b914bd8c6a01f7890
demo.cpp: In substitution of 'templateclass T using alias1 =
template1struct1T, template-parameter-1-2 ::type1 [with T = T]':
demo.cpp:12:45: required from here
demo.cpp:9:62: internal compiler error: Segmentation fault
templatetypename T using alias1 = template1decltype(T::x);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.archlinux.org/ for instructions.
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[OOP] Runtime segfault with |[OOP] Runtime segfault with
|type-bound assignment and |parenthesis expression
|parenthesis |passed to polymorphic dummy
||argument
--- Comment #4 from janus at gcc dot gnu.org ---
As shown by -fdump-tree-original, the first call to 'ass' is translated to:
{
struct __class_main_My_integer_t class.11;
class.11._vptr = (struct __vtype_main_My_integer * {ref-all})
__vtab_main_My_integer;
class.11._data = (struct my_integer *) a;
ass (class.11);
}
The second call, however, is translated to:
{
void * restrict D.3514;
integer(kind=8) D.3513;
integer(kind=8) D.3512;
integer(kind=8) D.3511;
struct __class_main_My_integer_t D.3510;
struct my_integer D.3509;
struct __class_main_My_integer_t class.13;
class.13._vptr = (struct __vtype_main_My_integer * {ref-all})
__vtab_main_My_integer;
D.3509 = a;
class.13._data = (struct my_integer *) D.3509;
D.3510 = class.13;
ass (class.13);
if ((void *) D.3510.x.data != 0B)
{
D.3511 = (D.3510.x.dim[0].ubound - D.3510.x.dim[0].lbound) + 1;
D.3512 = NON_LVALUE_EXPR D.3511;
D.3513 = D.3512 * 4;
D.3514 = (void * restrict) __builtin_malloc (MAX_EXPR (unsigned long)
D.3513, 1);
class.13.x.data = D.3514;
__builtin_memcpy ((real(kind=4)[0:] * restrict) class.13.x.data,
(real(kind=4)[0:] * restrict) D.3510.x.data, (unsigned long) (D.3512 * 4));
}
else
{
class.13.x.data = 0B;
}
if (class.13._data-x.data != 0B)
{
__builtin_free ((void *) class.13._data-x.data);
}
class.13._data-x.data = 0B;
}
While nothing is done after the call itself in the first case, quite a bit of
cleanup-code is added in the second case (which is also seen in comment 2.
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #5 from patnel97269-gfortran at yahoo dot fr --- (In reply to janus from comment #3) Actually one can reduce it even further: program main type :: my_integer real, allocatable :: x(:) end type type(my_integer) :: a a=my_integer([1]) write (*,*) A call ass(a) write (*,*) B call ass((a)) write (*,*) C contains subroutine ass(b) class(my_integer), intent(in) :: b print *,'called ass' end subroutine end This program does not do anything useful any more, but it still shows the same segfault at/after the call to ass((a)): $ ./a.out A called ass B called ass Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Making 'b' a TYPE instead of a CLASS makes the error go away. I agree that this example still trigger a bug, but I remember in my original (more complicated) code, the segfault appears when it tries to access the allocatable components of the type in the subroutine before computation and before returning. So the problem might be at entrance and not necessarily after the call. This need to be confirmed.
[Bug libstdc++/64399] New: g++ does not diagnose when upcasting owning pointer (e.g. unique_ptr) with non-virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399
Bug ID: 64399
Summary: g++ does not diagnose when upcasting owning pointer
(e.g. unique_ptr) with non-virtual destructor
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mw_triad at users dot sourceforge.net
Consider the following code:
#include memory
struct X { ~X(); };
struct Y : X { ~Y(); };
std::unique_ptrY f();
void g()
{
std::unique_ptrX x = f();
}
This code is almost certainly broken; ownership of the constructed Y is
transferred to an owning unique_ptr in a way that will most likely (in general;
always in this specific example) result in Y's destructor never being called.
It seems pretty silly that there is no diagnostic for this. There ought to be a
warning in unique_ptr's conversion operator converting from Derived to Base if
~Base is not virtual. (Arranging at the library level to trip
-Wnon-virtual-dtor seems logical.)
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to patnel97269-gfortran from comment #5) I agree that this example still trigger a bug, but I remember in my original (more complicated) code, the segfault appears when it tries to access the allocatable components of the type in the subroutine Are you sure? In my debugging sessions, it always seemed like the segfault happened after the subroutine call.
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #7 from patnel97269-gfortran at yahoo dot fr --- (In reply to janus from comment #6) (In reply to patnel97269-gfortran from comment #5) I agree that this example still trigger a bug, but I remember in my original (more complicated) code, the segfault appears when it tries to access the allocatable components of the type in the subroutine Are you sure? In my debugging sessions, it always seemed like the segfault happened after the subroutine call. My bad, can't reproduce that. Appears to be in between the a multiplication call and the assignment call, so at the return.
[Bug bootstrap/64389] duplicate symbols in libstdc++.6.dylib on darwin due to r219012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64389 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Dec 23 23:30:33 2014 New Revision: 219050 URL: https://gcc.gnu.org/viewcvs?rev=219050root=gccview=rev Log: Compile locale-inst.cc and wlocale-inst.cc as C++11. PR libstdc++/64389 * src/c++11/Makefile.am: Add locale-inst.cc and wlocale-inst.cc. * src/c++11/Makefile.in: Regenerate. * src/c++11/locale-inst.cc: Move from src/c++98/. * src/c++11/wlocale-inst.cc: Likewise. * src/c++11/cxx11-locale-inst.cc: Adjust path to locale-inst.cc. * src/c++11/string-inst.cc: Remove time_get instantiations. * src/c++98/Makefile.am: Remove locale-inst.cc and wlocale-inst.cc. * src/c++98/Makefile.in: Regenerate. * src/c++98/locale-inst.cc: Move to src/c++11/. * src/c++98/wlocale-inst.cc: Likewise. Added: trunk/libstdc++-v3/src/c++11/locale-inst.cc - copied, changed from r219049, trunk/libstdc++-v3/src/c++98/locale-inst.cc trunk/libstdc++-v3/src/c++11/wlocale-inst.cc - copied, changed from r219049, trunk/libstdc++-v3/src/c++98/wlocale-inst.cc Removed: trunk/libstdc++-v3/src/c++98/locale-inst.cc trunk/libstdc++-v3/src/c++98/wlocale-inst.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/Makefile.am trunk/libstdc++-v3/src/c++11/Makefile.in trunk/libstdc++-v3/src/c++11/cxx11-locale-inst.cc trunk/libstdc++-v3/src/c++11/string-inst.cc trunk/libstdc++-v3/src/c++98/Makefile.am trunk/libstdc++-v3/src/c++98/Makefile.in
[Bug bootstrap/64389] duplicate symbols in libstdc++.6.dylib on darwin due to r219012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64389 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- I committed a different fix, which gets rid of the TODO in string-inst.cc, let me know if it still doesn't bootstrap!
[Bug libstdc++/64399] g++ does not diagnose when upcasting owning pointer (e.g. unique_ptr) with non-virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- PR 58876
[Bug c++/64395] void_t doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64395 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Already fixed on trunk (I don't remember the commit that fixed it)
[Bug libstdc++/64399] g++ does not diagnose when upcasting owning pointer (e.g. unique_ptr) with non-virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399 --- Comment #2 from Matthew Woehlke mw_triad at users dot sourceforge.net --- (In reply to Jonathan Wakely from comment #1) PR 58876 *Almost*, except I am proposing that -Wnon-virtual-dtor should trip even if X does not otherwise have virtual methods. (Just why you'd be writing such code, I'm not sure, but...) Odd that didn't turn up in my search for existing bugs...
[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
Matthew Woehlke mw_triad at users dot sourceforge.net changed:
What|Removed |Added
CC||mw_triad at users dot
sourceforge.
||net
--- Comment #5 from Matthew Woehlke mw_triad at users dot sourceforge.net ---
See also bug 64399, which proposes that a) the conversion itself should
generate a warning, and b) the presence of other virtual methods in A should
not be required for the warning to trip. (This could be achieved by something
like static_assert except to emit a warning, combined with
std::has_virtual_destructor, without otherwise having to fiddle with pragmas.)
Actually, this may be required for 'make_uniqueA(new B)' to warn, since the
conversion of a B* ('new B') to an A* (which is what is passed to make_unique /
unique_ptr::unique_ptr) should not warn. (IOW, unique_ptr / make_unique would
need overloads taking any pointer type and doing the conversion inside STL so
that std::has_virtual_destructor can be checked against the actual pointer
type.)
...or alternatively gcc would need to detect when a converted pointer is passed
to unique_ptr / make_unique, which seems like it would be harder.
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) program testerprog use testmod Type(A) :: Me allocate(Me%y) Me = A(X=1, y=2) print *, Me%y end program gives Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Confirmed. However, this segfault is not related to the original bug (nor to the patch I posted). It's a separate issue.
[Bug c++/64395] void_t doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64395 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed by r217250
[Bug libstdc++/64399] g++ does not diagnose when upcasting owning pointer (e.g. unique_ptr) with non-virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399 Thiago Macieira thiago at kde dot org changed: What|Removed |Added CC||thiago at kde dot org --- Comment #3 from Thiago Macieira thiago at kde dot org --- Because it's not a bug. This is a totally valid scenario.
[Bug bootstrap/64389] duplicate symbols in libstdc++.6.dylib on darwin due to r219012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64389 howarth at bromo dot med.uc.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from howarth at bromo dot med.uc.edu --- Fixed at r219053 by r219050.
