[Bug c++/85976] [8/9 Regression] ICE in cp_tree_equal when building Blitz. May be nested templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85976 --- Comment #6 from Sylwester Arabas --- BTW, according to this gcc www entry, Blitz++ seems to listed as a part of GCC test suite: https://gcc.gnu.org/testing/testing-blitz.html Is this information up to date? Was this issue somehow triggered in automatic tests?
[Bug c++/61774] New: ICE (regression?) in lra_update_insn_recog_data, at lra.c:1219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61774 Bug ID: 61774 Summary: ICE (regression?) in lra_update_insn_recog_data, at lra.c:1219 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: slayoo at staszic dot waw.pl Created attachment 33103 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33103action=edit single .ii file that triggers the ICE Hi, Trying out current Debian's gcc-snapshot (20140708) with a code that compiled fine with gcc-snapshot from a few weeks ago, I got: internal compiler error: in lra_update_insn_recog_data, at lra.c:1219 Sorry, but I have no time now to narrow the cause :( It can be reproduced with the attached .ii file and /usr/lib/gcc-snapshot/bin/g++ -std=c++11 -fopenmp -pthread -Wfatal-errors -DNDEBUG -Ofast -march=native over_the_pole_2d.ii The native march seems to mean here (echo | /usr/lib/gcc-snapshot/bin/gcc -### -E - -march=native): ... /usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.10.0/cc1 -E -quiet -imultiarch x86_64-linux-gnu - -march=amdfam10 -mmmx -m3dnow -msse -msse2 -msse3 -mno-ssse3 -msse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 ... HTH, Sylwester
[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267 --- Comment #13 from Sylwester Arabas slayoo at staszic dot waw.pl --- Just confirming it solved the problem with compilation of Blitz++ with the ivdep pragmas. Thanks, Sylwester P.S. Turning them on, causes a slowdown in this case, though :).
[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267 --- Comment #7 from Sylwester Arabas slayoo at staszic dot waw.pl --- Created attachment 32172 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32172action=edit preprocessed source trigerring ICE with g++ snapshot 20140212 Thanks a lot for looking at it. I'm attaching the source proprocessed with g++ 4.8.2. It gives the tsubst_copy ICE with the 20140212 g++ snapshot. HTH, Sylwester
[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267 --- Comment #8 from Sylwester Arabas slayoo at staszic dot waw.pl --- BTW, I have initially reported it as a comment to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60198 (the same file/line in ICE error message). S.
[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267 --- Comment #12 from Sylwester Arabas slayoo at staszic dot waw.pl --- Thanks a lot! I'll try it as soon as it will get into Debian's gcc-snapshot package. Sylwester
[Bug c++/60198] ICE with _Cilk_spawn in expression within template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60198 Sylwester Arabas slayoo at staszic dot waw.pl changed: What|Removed |Added CC||slayoo at staszic dot waw.pl --- Comment #2 from Sylwester Arabas slayoo at staszic dot waw.pl --- Hi, I've just got the same error with current Debian's gcc-snapshot (20140212) when trying to compile a code that uses the Blitz++ library, and after replacing all #pragma ivdep with #pragma GCC ivdep in that library... /usr/include/blitz/globeval.cc:466:12: internal compiler error: in tsubst_copy, at cp/pt.c:12887 for (; i uneven_start; ++i) ^ Please submit a full bug report, with preprocessed source if appropriate. I can provide more details if needed. HTH, Sylwester
[Bug c++/60267] New: ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267
Bug ID: 60267
Summary: ICE in c_pp_lookup_pragma, at
c-family/c-pragma.c:1232; ICE in tsubst_copy, at
cp/pt.c:12887
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slayoo at staszic dot waw.pl
Hi All,
The Blitz++ library (http://sf.net/projects/blitz) contains some #pragma
ivdep macros intended for the Intel C++ compiler. Having learnt that GCC now
supports a corresponding GCC ivdep pragma, I've tried changing all occurances
of pragma ivdep in Blitz++ with the GCC ones (encapsulating them in some
define-checks to detect the compiler).
Trying then just to parse the include files with:
#define BZ_USE_ALIGNMENT_PRAGMAS
#include blitz/array-impl.h
int main() {}
using the Debian's gcc-snapshot (20140212) I've got an ICE:
**
In file included from /usr/include/blitz/globeval.cc:34:0,
from /usr/include/blitz/array/ops.cc:38,
from /usr/include/blitz/array.cc:13,
from /usr/include/blitz/array-impl.h:2559,
from bug.cpp:2:
/usr/include/blitz/tvevaluate.h: In instantiation of 'static void
blitz::_tv_evaluatorunroll, N_length::evaluate_aligned(T_numtype*, const
T_expr, T_update) [with T_numtype = bool; T_expr =
blitz::_bz_ArrayExprblitz::_bz_ArrayExprConstantbool ; T_update =
blitz::_bz_updatebool, bool; bool unroll = false; int N_length = 1]':
/usr/include/blitz/tvevaluate.h:88:85: required from 'static void
blitz::_tv_evaluatorunroll,
N_length::select_evaluation(blitz::TinyVectorT_numtype2, N_length, const
T_expr, T_update) [with T = bool; T_expr =
blitz::_bz_ArrayExprblitz::_bz_ArrayExprConstantbool ; T_update =
blitz::_bz_updatebool, bool; bool unroll = false; int N_length = 1]'
/usr/include/blitz/tvevaluate.h:195:81: required from 'void
blitz::TinyVectorT, N::_tv_evaluate(const T_expr, T_update) [with T_expr =
blitz::_bz_ArrayExprblitz::_bz_ArrayExprConstantbool ; T_update =
blitz::_bz_updatebool, bool; P_numtype = bool; int N_length = 1]'
/usr/include/blitz/tinyvec2.cc:89:57: required from 'blitz::TinyVectorT, N
blitz::TinyVectorT, N::operator=(const blitz::ETBaseT_expr) [with T_expr =
blitz::_bz_ArrayExprblitz::_bz_ArrayExprConstantbool ; P_numtype = bool;
int N_length = 1]'
/usr/include/blitz/tinyvec2.cc:77:13: required from 'blitz::TinyVectorT, N
blitz::TinyVectorT, N::initialize(blitz::TinyVectorT, N::T_numtype) [with
P_numtype = bool; int N_length = 1; blitz::TinyVectorT, N::T_numtype = bool]'
/usr/include/blitz/listinit.h:90:13: required from
'blitz::ListInitializationSwitchT_array,
T_iterator::~ListInitializationSwitch() [with T_array =
blitz::TinyVectorbool, 1; T_iterator = bool*]'
/usr/include/blitz/array/storage.h:93:24: required from
'blitz::GeneralArrayStorageN_rank::GeneralArrayStorage(blitz::paddingPolicy)
[with int N_rank = 1]'
/usr/include/blitz/array/storage.h:228:47: required from here
/usr/include/blitz/tvevaluate.h:108:17: internal compiler error: in
tsubst_copy, at cp/pt.c:12887
for (int i=0; i N_length; ++i)
^
Please submit a full bug report,
**
Trying to better prepare the bug report and executing gcc with -save-temps
results in another ICE:
**
In file included from /usr/include/blitz/globeval.cc:34:0,
from /usr/include/blitz/array/ops.cc:38,
from /usr/include/blitz/array.cc:13,
from /usr/include/blitz/array-impl.h:2559,
from bug.cpp:2:
/usr/include/blitz/tvevaluate.h:38:0: internal compiler error: in
c_pp_lookup_pragma, at c-family/c-pragma.c:1232
^
Please submit a full bug report,
**
How to best help in tracking those down?
Sylwester
[Bug c++/60198] ICE with _Cilk_spawn in expression within template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60198 --- Comment #4 from Sylwester Arabas slayoo at staszic dot waw.pl --- Here it is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267 HTH, Sylwester
[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267 --- Comment #2 from Sylwester Arabas slayoo at staszic dot waw.pl --- As I've mentioned, trying to use -save-temps results in another ICE and an abruptly cut .ii file (last line ends with an unfinished #pragma). The .ii file fails to compile and does not give the ICE. S.
[Bug c++/57041] New: ICE in lookup_field_1, at cp/search.c:376 (with dot-prefixed structure initialisation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57041
Bug #: 57041
Summary: ICE in lookup_field_1, at cp/search.c:376 (with
dot-prefixed structure initialisation)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sla...@staszic.waw.pl
Hi,
$ cat bug.cpp
#include map
#include string
template class T
void setopts(T p)
{
p.outvars = {{0, {.name = psi, .unit = 1}}};
}
int main()
{
struct
{
struct info { std::string name, unit; };
std::mapint, info outvars;
} p;
setopts(p);
}
$ /usr/lib/gcc-snapshot/bin/g++ -std=c++11 bug.cpp
bug.cpp: In instantiation of 'void setopts(T) [with T = main()::anonymous
struct]':
bug.cpp:17:12: required from here
bug.cpp:7:13: error: 'name' was not declared in this scope
p.outvars = {{0, {.name = psi, .unit = 1}}};
^
bug.cpp:7:13: error: 'unit' was not declared in this scope
bug.cpp:7:13: internal compiler error: in lookup_field_1, at cp/search.c:376
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccLInnuE.out file, please attach this to
your bugreport.
$ /usr/lib/gcc-snapshot/bin/g++ --version
g++ (Debian 20130209-1) 4.8.0 20130209
Clang compiles it with no warnings or errors.
HTH,
Sylwester
[Bug fortran/55983] [4.7/4.8 Regression] ICE in find_typebound_proc_uop, at fortran/class.c:2711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55983 --- Comment #3 from Sylwester Arabas slayoo at staszic dot waw.pl 2013-01-15 09:03:28 UTC --- Hi Janus, Re .f90 - it's not valid f90 code after all :) Re missing use bcd_m - I was aware of this case, and I submitted the Bad statement code ICE as a separate issue yesterday: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55984 Regards, Sylwester
[Bug fortran/55983] New: ICE in find_typebound_proc_uop, at fortran/class.c:2711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55983 Bug #: 55983 Summary: ICE in find_typebound_proc_uop, at fortran/class.c:2711 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl First, sorry for not reducing the test case further. Second, here's the way to reproduce it: $ cat bug2.f module bcd_m type, abstract :: bcd_t contains procedure(bcd_fill_halos), deferred :: fill_halos end type abstract interface subroutine bcd_fill_halos(this) import :: bcd_t class(bcd_t ) :: this end subroutine end interface end module module solver_mpdata_m type :: mpdata_t class(bcd_t), pointer :: bcx, bcy contains procedure :: advop = mpdata_advop end type contains subroutine mpdata_advop(this) class(mpdata_t) :: this associate ( bcx = this%bcx, bcy = this%bcy ) call bcx%fill_halos() end associate end subroutine end module $ /usr/lib/gcc-snapshot/bin/gfortran -ffree-form -std=f2008 bug2.f f951: internal compiler error: in find_typebound_proc_uop, at fortran/class.c:2711 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20130113-1) 4.8.0 20130113 (experimental) [trunk revision 195136] ... HTH, Sylwester
[Bug fortran/55984] New: ICE: gfc_trans_code(): Bad statement code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55984 Bug #: 55984 Summary: ICE: gfc_trans_code(): Bad statement code Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl First, sorry for not reducing the test case further more. Second, here's a recipe to reproduce the ICE: $ cat bug1.f module bcd_m type, abstract :: bcd_t contains procedure(bcd_fill_halos), deferred :: fill_halos end type abstract interface subroutine bcd_fill_halos(this) import :: bcd_t class(bcd_t ) :: this end subroutine end interface end module module solver_m use bcd_m type, abstract :: solver_t integer :: n, hlo class(bcd_t), pointer :: bcx, bcy contains procedure(solver_advop), deferred :: advop end type abstract interface subroutine solver_advop(this) import solver_t class(solver_t) :: this end subroutine end interface contains end module module solver_mpdata_m use solver_m type :: mpdata_t class(bcd_t), pointer :: bcx, bcy contains procedure :: advop = mpdata_advop end type contains subroutine mpdata_advop(this) class(mpdata_t) :: this associate ( bcx = this%bcx, bcy = this%bcy ) call bcx%fill_halos() end associate end subroutine end module $ /usr/lib/gcc-snapshot/bin/gfortran -ffree-form -std=f2008 bug1.f bug1.f: In function 'mpdata_advop': bug1.f:42:0: internal compiler error: gfc_trans_code(): Bad statement code call bcx%fill_halos() ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20130113-1) 4.8.0 20130113 (experimental) [trunk revision 195136] ... HTH, Sylwester
[Bug fortran/54940] New: ICE in gfc_build_intrinsic_call, at fortran/expr.c:4609
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54940 Bug #: 54940 Summary: ICE in gfc_build_intrinsic_call, at fortran/expr.c:4609 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl :( $ cat bug.f95 module bug_m contains function bug() integer :: j(:), bug(size(j-1)) end function end module $ /usr/lib/gcc-snapshot/bin/gfortran bug.f95 f951: internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4609 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20120930-1) 4.8.0 20120930 (experimental) [trunk revision 191865] HTH, Sylwester
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 --- Comment #2 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-10-12 09:48:12 UTC --- Hi, I've came across it after simply switching the order of module definitions in a file (i.e. no preprocessor - I've used the preprocessor to simplify the test case). I would then answer: definitely YES! - fixing it might save someone a lot of time. Due to the ICE, and due the fact that the presence of the .mod file influences gfortran's behaviour here, figuring out what's wrong is really tricky and time consuming. Sylwester
[Bug fortran/54788] ICE on pointer-array element assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788 --- Comment #5 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-10-09 18:57:42 UTC --- Created attachment 28404 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28404 testcase The bug report got cluttered with non-relevant discussion and code (thanks again for you answers to my question!), so I'm submitting the testcase in a separate file as attachment. S.
[Bug fortran/54880] New: ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 Bug #: 54880 Summary: ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl Created attachment 28405 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28405 testcase to trigger the ICE Running the attached testcase with the current Debian's gcc-snapshot gfortran I get: $ cat m1.f95 module solver_2D_m use adv_m type :: solver_2D_t class(adv_t), pointer :: adv contains end type contains subroutine solver_2D_solve(this) class(solver_2D_t) :: this end subroutine end module $ cat m2.f95 module adv_m type, abstract :: adv_t contains procedure(op_2D_i), deferred :: op_2D end type abstract interface subroutine op_2D_i(this) import :: adv_t class(adv_t) :: this end subroutine end interface end module $ cat m12.f95 #include m1.f95 #include m2.f95 $ cat m21.f95 #include m2.f95 #include m1.f95 program m21 end $ cat trigger.sh #!/bin/bash /usr/lib/gcc-snapshot/bin/gfortran -cpp m21.f95 /usr/lib/gcc-snapshot/bin/gfortran -cpp m12.f95 $ ./trigger.sh m1.f95:10:0: internal compiler error: in gfc_create_module_variable, at fortran/trans-decl.c:4013 end subroutine ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions.
[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 fortran/54778] New: an ICE on invalid OO code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54778 Bug #: 54778 Summary: an ICE on invalid OO code Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl Hi, Enclosing below the steps to reproduce an ICE on an invalid OO code. HTH, Sylwester $ cat bug.f95 module bug_m implicit none type :: arr_t real, dimension(:,:), pointer :: at end type type :: bug_t class(arr_t), allocatable :: elements(:) end type contains function elem(this, i) type(bug_t), intent(in) :: this integer, intent(in) :: i class(arr_t) :: elem elem = this%elements(i) end function end module $ /usr/lib/gcc-snapshot/bin/gfortran bug.f95 bug.f95:14.2: function elem(this, i) 1 Error: CLASS variable 'elem' at (1) must be dummy, allocatable or pointer f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20120930-1) 4.8.0 20120930 (experimental) [trunk revision 191865] Copyright (C) 2012 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
[Bug fortran/54788] New: ICE on pointer-array element assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788 Bug #: 54788 Summary: ICE on pointer-array element assignment Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl Hello, I'm sending below a short code causing an ICE of gfortran. HTH, Sylwester P.S. BTW, could you help me in understanding the following error message: $ cat question.f90 program question type :: arr_t real, pointer :: arr(:,:) end type class(arr_t), pointer :: vec(:) allocate(vec(2)) allocate(vec(0)%arr(4,4)) vec(1) = vec(0) end $ gfortran question.f90 question.f90:8.2: vec(1) = vec(0) 1 Error: Expected bounds specification for 'vec' at (1) In principle, I'm trying to define a vector of pointers to arrays, and make two elements of this vector point to the same array. -- $ cat bug.f90 program bug integer, pointer :: a(:) integer :: b allocate(a(0:0)) a(0:0) = b end $ /usr/lib/gcc-snapshot/bin/gfortran bug.f90 f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20120930-1) 4.8.0 20120930 (experimental) [trunk revision 191865] Copyright (C) 2012 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
[Bug fortran/54243] New: f951: internal compiler error: Segmentation fault (trying to compile errorneous code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54243 Bug #: 54243 Summary: f951: internal compiler error: Segmentation fault (trying to compile errorneous code) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl With Deabian's gcc-snapshot gfortran (4.8.0 20120714) trying to compile to code below: module aqq_m type :: aqq_t contains procedure :: aqq_init end type contains subroutine aqq_init(this) class(aqq_t) :: this end subroutine end module program bug2 use aqq_m class(aqq_t) :: aqq call aqq%aqq_init end program I get: $ /usr/lib/gcc-snapshot/bin/gfortran -std=f2008 -ffree-form bug2.f bug2.f:24.21: class(aqq_t) :: aqq 1 Error: CLASS variable 'aqq' at (1) must be dummy, allocatable or pointer f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. HTH, Sylwester
[Bug fortran/54244] New: f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:210
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54244 Bug #: 54244 Summary: f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:210 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl With Deabian's gcc-snapshot gfortran (4.8.0 20120714) trying to compile to code below: module aqq_m type :: arr_t end type type :: aqq_t class(arr_t), allocatable :: psi(:) contains procedure :: aqq_init end type contains subroutine aqq_init(this) class(aqq_t) :: this end subroutine end module program bug1 use aqq_m class(aqq_t) :: aqq call aqq%aqq_init end program I get: $ /usr/lib/gcc-snapshot/bin/gfortran -std=f2008 -ffree-form bug1.f bug1.f:32.21: class(aqq_t) :: aqq 1 Error: CLASS variable 'aqq' at (1) must be dummy, allocatable or pointer bug1.f:33.10: call aqq%aqq_init 1 Error: Type mismatch in argument 'this' at (1); passed CLASS(__class_aqq_m_Arr_t_1_0a) to CLASS(aqq_t) f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:210 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. HTH, Sylwester
[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094 Sylwester Arabas slayoo at staszic dot waw.pl changed: What|Removed |Added CC||slayoo at staszic dot ||waw.pl --- Comment #6 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-24 08:50:52 UTC --- Perhaps that's somehow related to the issue described in this message: http://gcc.gnu.org/ml/fortran/2012-04/msg00122.html Sylwester
[Bug fortran/53077] suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 --- Comment #5 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-23 11:13:21 UTC --- Thanks for quick replies. Why can't you just pass the -cpp option to gfortran if you want to enable the preprocessor? Of course you can, but first you need to know that the Illegal preprocessor directive warning actually means that the preprocessor is off :) Untested patch. I guess Used -cpp to should read Use -cpp to. Thanks, Sylwester
[Bug fortran/53077] New: suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
Bug #: 53077
Summary: suggestion to add the .f extension to the list of file
extensions that trigger enabling of the preprocessor
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sla...@staszic.waw.pl
Hello,
$ cat test.f
#define print(x) print*, x
program test
print('aqq')
end
$ gfortran -ffree-form test.f
Warning: test.f:1: Illegal preprocessor directive
test.f:3.8:
print('aqq')
1
Error: Missing leading left parenthesis in format string at (1)
$ mv test.f test.F
$ gfortran-mp-4.6 -ffree-form test.F echo OK
OK
This behavior is consistent with the docs but it's quite misleading, especially
as the warning message might be understood as if there was something wrong
within the macro definition, and not with the fact that the macro is there at
all.
Why not turning on the preprocessor with .f extensions as well?
(currently only the .F extension turns it on by default)
HTH,
Sylwester
[Bug fortran/53077] suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 --- Comment #1 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-22 20:35:49 UTC --- The gfortran-mp-4.6 vs. gfortran difference in the code above is not relevant to the issue.
[Bug fortran/53077] suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 --- Comment #2 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-22 21:36:33 UTC --- Hmm... apparently the PGI compiler uses the same rule for enabling preprocessor with .f and .F extensions. Then, if there's some important reason behind it (?) perhaps at least the warning message could be improved by indicating that the preprocessor is off.
[Bug fortran/52994] New: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994 Bug #: 52994 Summary: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl $ /usr/lib/gcc-snapshot/bin/gfortran -std=f2008 -ffree-form test.f test.f: In function 'test': test.f:43:0: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20120407-1) 4.8.0 20120407 (experimental) [trunk revision 186212] Hope that helps, Sylwester
[Bug fortran/52994] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994 --- Comment #1 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-15 11:40:49 UTC --- Created attachment 27159 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27159 Fortran source file with minimal example to reproduce the descibed behaviour
[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994 --- Comment #3 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-15 19:28:22 UTC --- pointer-valued (and dimensionful) type-bound procedure. Phew. Thanks for the nice test case :) That's what I've got trying to reimplement quite verbosely a piece of C++ code in Fortran :) Sylwester
[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994 --- Comment #8 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-15 20:23:18 UTC --- Just out of curiosity: Are you aware of any compiler which swallows this? No. I've just tried it with PGI (pgf95) but it chokes on contains within a derived type definition. That's what I've got trying to reimplement quite verbosely a piece of C++ code in Fortran :) That seems like a rare intention. There are certainly more people doing it the other way around ;) Indeed, but there're also lots of people (around me) dead sure of Fortran being faster than anything :) I.e. it prints only one number, where it actually should print three. Isn't arr(-1:-1) meaning a[-1], i.e. just one element? Sylwester
