[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2022-12-27 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|---

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2022-12-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #16 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:794af0d00b7086c9f0493f3a1aaac644e1fd50f6 commit r13-4851-g794af0d00b7086c9f0493f3a1aaac644e1fd50f6 Author: Harald Anlauf Date: T

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2022-12-22 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid,

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2017-10-05 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #14 from Dominique d'Humieres --- > The patch in comment 7 no longer applies: 'ts.type == BT_DERIVED' has been > replaced with 'ts.type == BT_DERIVED'. Updating the patch along this line > does not remove the ICE!-( Read "replaced wi

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2017-10-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #13 from Dominique d'Humieres --- The patch in comment 7 no longer applies: 'ts.type == BT_DERIVED' has been replaced with 'ts.type == BT_DERIVED'. Updating the patch along this line does not remove the ICE!-(

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2017-05-04 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #12 from Harald Anlauf --- (In reply to Harald Anlauf from comment #11) > While reducing PR 78290, I found another example giving a similar traceback: > > % gfc-trunk gfcbug136.f90 [...] While checking the status of the example in c

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-11-23 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #11 from Harald Anlauf --- While reducing PR 78290, I found another example giving a similar traceback: % gfc-trunk gfcbug136.f90 gfcbug136.f90:13:0: ip=>ta%i !!! Works if you comment this line out !!! internal compiler error: i

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-08-25 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #10

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-04-28 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #9 from Gerhard Steinmetz --- Update, using fresh new release gfortran-6 --version GNU Fortran (SUSE Linux) 6.1.0 20160427 [gcc-6-branch revision 235475] The error message has changed : $ gfortran-6 -c z1.f90 internal compiler er

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-03-23 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #8 from Harald Anlauf --- Independent of the modification in comment #7, there is an issue with wrong code for the native complex type. Consider: program p complex :: z[*], w = 1 real:: x[*], y = 2 type t complex :: c

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-03-19 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #7 from Harald Anlauf --- (In reply to Harald Anlauf from comment #6) All crashes for case 4 go away after the following change: Index: gcc/fortran/trans-expr.c === ---

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-03-19 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #6 from Harald Anlauf --- (In reply to Harald Anlauf from comment #5) > The problem in case for is in the l.h.s. of the assignment, not the r.h.s: Even simpler, it's just the complex assignment: program p complex :: z[*], w = 1

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-03-19 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #4 from Harald Anlauf --- Cases z1, z2 are invalid codes: ifort: pr69604-z1.f90(2): error #6579: A dummy argument of a statement function is invalid in this context. [N] x(n) = n() --^ compilation aborted for pr69604-z1

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-03-19 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #3 from

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-03-19 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #5 from Harald Anlauf --- The problem in case for is in the l.h.s. of the assignment, not the r.h.s: program p complex :: z[*] real:: x[*], y ! z = x / cmplx(0.0, x) z = 1 / cmplx(y) end pr69604-z4.f90:5:0: z = 1

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-02-01 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

2016-02-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #1 from Gerhard Steinmetz --- While playing around, one example from ./gcc/testsuite/gfortran.dg/ shows the same error with v6.0.0, but not with v5.3.1 : $ gfortran-6 -c complex_intrinsic_6.f90 internal compiler error: in gfc_add_