Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
Calling ieee_set_halting_mode only affects the master thread if other threads
already exist and the
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
The following code causes an out-of bounds access in array ni(1) when optimized
with -O1 or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #5 from Vladimir Fuka ---
In that case some compiler or linker magic happens after that, because the
correct code is executed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #2 from Vladimir Fuka ---
As mentioned, the correct function is called in case everything is REAL
a = floor(5.0)
print *, a
contains
RECURSIVE FUNCTION FLOOR(Z) RESULT(RES)
REAL,INTENT(IN) :: Z
REAL :: RES
if (z>0) then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #1 from Vladimir Fuka ---
For after naming LOG one gets
RECURSIVE FUNCTION LOG(Z) RESULT(RES)
COMPLEX,INTENT(IN) :: Z
COMPLEX :: RES
RES = LOG(Z);
END FUNCTION LOG
> gfortran-12 -c shadow.f90
/tmp/ccbpyhxl.s: Assembler mes
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
Reported at Stackoverflow by Denis Cousineau
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59202
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411
--- Comment #7 from Vladimir Fuka ---
This sounds like good progress and I thank you for the patch. However,
shouldn't implicitly SAVE'd variables, as e.g. the program local variable in
the original report, be included as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127
--- Comment #9 from Vladimir Fuka ---
I see now, it was fixed on the 8 branch, but not on the trunk! It ought to be
applied at least to the 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
This program
program p
dimension a(10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94975
--- Comment #1 from Vladimir Fuka ---
It is probably discussed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 but that was not possible to
find it by the search as the title is not directly related.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
With GCC 7-10 (bit libasan from 10)
class(*), allocatable :: p
p = "abc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #4 from Vladimir Fuka ---
It would be really strange if even expressions like below were not possible.
implicit none
integer, allocatable :: a(:)
allocate(a, source=[1])
call assign(a, (min(a(1)**2,0)))
print *, alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #1 from Vladimir Fuka ---
It also crashes with passing just a(1) instead of (a(1)) and when removing the
value attribute.
: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
This code crashes at the allocated() call with GCC 7,8,9
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
subroutine s(a)
use iso_fortran_env
type field_names_a
class(*), pointer :: var(:) =>n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
Reported at
https://stackoverflow.com/questions/50459234/fortran-pointer-dummy-argument
This code returns
program aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85855
--- Comment #2 from Vladimir Fuka ---
Yes, that is quite possible, although I tried to search first, because I had
this problem without reporting for a long time, but may main compiler version
to use was an older one so I didn't car that much fo
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
This code does not issue any warning in GCC 4.8 to 6 but does for GCC 7.3.1:
module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074
--- Comment #3 from Vladimir Fuka ---
The bug has been around for so long that I already forgot I saw these problems
before.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
Base on
https://stackoverflow.com/questions/48468922/creating-a-subset-of-an-array-of-derived
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
The following gives random garbage results:
select type (tmp => getValue())
type is (integer)
pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78797
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
Based on report
https://stackoverflow.com/questions/48331223/fortran-elemental-function-is-this-behavior-normal
. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386
Vladimir Fuka changed:
What|Removed |Added
Version|4.8.0 |7.1.1
--- Comment #6 from Vladimir Fuka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386
--- Comment #5 from Vladimir Fuka ---
Probably not a duplicate of pr64674 because this bug is still present in 7.1.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618
Vladimir Fuka changed:
What|Removed |Added
Version|4.8.0 |7.1.1
--- Comment #3 from Vladimir Fuka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58861
--- Comment #6 from Vladimir Fuka ---
Still present in GCC 7.1.1.
Cab bug70231 be related?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70231
--- Comment #2 from Vladimir Fuka ---
Still present in GCC 7 and people are complaining
https://stackoverflow.com/questions/44385909/adding-to-an-array-of-characters-in-fortran
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
The following:
module m1
type :: base
contains
procedure :: fun
end type
type, extends(base) :: child
end type
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
Reported at
http://stackoverflow.com/questions/42189625/renaming-a-subroutine-in-a-fortran-module-when-using-iso-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77746
--- Comment #3 from Vladimir Fuka ---
Indeed, 4.9 crashes as well, my first description is incorrect. It was running
well in 4.8.5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77746
--- Comment #1 from Vladimir Fuka ---
-fdump-tree-original
random_name ()
{
}
p_execute (integer(kind=4) & restrict i)
{
p_execute ();
}
MAIN__ ()
{
{
static integer(kind=4) C.3388 = 1;
p_execute (&C.3388);
}
}
main (intege
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
This program finishes successfully with 4.9 and crashes with 5.3.1
The generic resolution selects wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71967
--- Comment #7 from Vladimir Fuka ---
I think we can mark this as INVALID then. The protected attribute is indeed not
an access attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71967
--- Comment #5 from Vladimir Fuka ---
OMG, I forgot implicit none and the only clause. Sorry. So is ifort wrong
in treating protected like an access statement?
Dne 22. 7. 2016 13:04 napsal uživatel "dominiq at lps dot ens.fr" <
gcc-bugzi...@gcc.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71967
--- Comment #3 from Vladimir Fuka ---
OK, protected is not an access-stmt.
But in that case, why is the private access-stmt ignored?
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
This program compiles
module m
protected :: k
private :: k
integer k
end module
use m
print *, k
end
but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71795
--- Comment #6 from Vladimir Fuka ---
(In reply to Thomas Koenig from comment #4)
> (In reply to Vladimir Fuka from comment #3)
> > I suppose it should not be P4 critical?
>
> All Fortran regressions are classified below P3.
> Fortran is not con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71795
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
print *, f()
contains
function f()
integer :: f(iargc()*10)
end
end
ICE's with gcc version
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
function f(o)
optional o
end function
causes
gfortran -Wall -Wextra -Wno-unused-dummy-argument
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
integer, parameter :: char_len = 32
character(char_len), allocatable :: ch_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68101
--- Comment #2 from Vladimir Fuka ---
Definitely similar, but the link is about failure to align to the required
alignment for that datatype.
This feature request is about higher than required alignment for performance
reasons (SIMD vectorizati
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
This is an extension of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24261
which is claimed to be RESOLVED FIXED, but is not when `-m32` is used.
There should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61337
--- Comment #3 from Vladimir Fuka ---
The crash is at line 22:
allocate(a(size(tmp)+1)%items(size(e)), source = e)
ASAN:SIGSEGV
=
==5902==ERROR: AddressSanitizer: SEGV on unknown a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61337
--- Comment #2 from Vladimir Fuka ---
The first is fixed on trunk apparently by
https://gcc.gnu.org/ml/fortran/2015-07/msg00038.html
The modification
call add_item(a_list, [1, 2])
call add_item(a_list, [1, 2])
do i = 1, size(a_list)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695
--- Comment #1 from Vladimir Fuka ---
Anyone can confirm this behaviour?
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Target Milestone: ---
The following code compiles with 4.8.5, and 4.9.0 and causes ICE with 4.9.2 and
5.1.1
module mod
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
layzrc raised this problem on comp.lang.fortran
https://groups.google.com/forum/#!topic/comp.lang.fortran/lVzeHW_X1aw
module
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
module array_list
type container
class(*), allocatable :: items(:)
end type
contains
subroutine add_item(a, e)
type(container
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
John Harper reports on comp.lang.fortran:
! A recursive function in a specification expression
module recur
implicit none
contains
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60717
--- Comment #3 from Vladimir Fuka ---
Could there be a connection http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58085 ?
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
subroutine sub(str)
character(*) :: str
character(:), allocatable :: tmp
tmp = str
print *,allocated(tmp)
end
gfortran-4.9 uninit.f90 -c -Wall
uninit.f90: In function ‘sub
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
reported on comp.lang.fortran by Thomas Schnurrenberger
The output of the two parts of the following program should be the same, as
they are
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
The code is quite possibly non-standard or totally buggy, but prints the
expected answer without -flto.
bigend.c:
#include
#include
static bool
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
This compiles fine with the trunk and crashes at runtime:
print *, f(g(x))
contains
real function f(fun)
procedure(g) :: fun
f = fun(1.)
end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447
--- Comment #4 from Vladimir Fuka ---
I see, but I just wanted to print the content or pipe it somewhere, so I don't
think that resolves it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447
--- Comment #2 from Vladimir Fuka ---
-o option for what?
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
> touch test.f90
> gfortran -E -cpp test.f90
# 1 "test.f90"
# 1 ""
# 1 "test.f90"
> ls -l test.s
-rw-r--r-- 1 lada users 0 6. bře 13.47 test.s
C and C++ fr
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
type refptr
class(*), allocatable :: data
end type
type(refptr),pointer :: x
print *,null(mold=x)
end
gfortran null.f90
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
bind(C) test_bind
end
is compiled without error or warning with
gfortran -std=f2008
but
C519 A variable with the BIND attribute shall be declared in the specification
part of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58916
--- Comment #7 from Vladimir Fuka ---
Sorry, didn't remember that.
oduct: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
> cat assoc.f90
associate (x=>trim("abc
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Connected or duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618 ?
>cat assoc.f90
associate (x=>"abc")
end associate
end
> gfortran assoc.f90
f951: inte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58947
--- Comment #2 from Vladimir Fuka ---
Yes, also on my other computer with a more recent version (4.8.2 20131003) it
works right. I have more computers and I sometimes loose track of when did I
recompile gcc last time there. I assumed it is from fi
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
type t
integer i
end type
type(t) a
select type (x=>a%i)
type is (integer)
print *,x
end select
end
> gfortran seltype.f90
f951: in
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
allocatable :: a
real b(1)
allocate(a, source=b)
end
gfortran -v alloc3.f90
Driving: gfortran -v alloc3.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
class(*),allocatable :: a
real b(1)
allocate(a, source=b)
end
Does not cause any error.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
program test
real(8), allocatable :: a(:,:)
real(4),allocatable :: b(:,:)
allocate(b(100,100))
b = 0
!both lines below create problem
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
subroutine sub(a)
class(*),allocatable :: a
a => null()
end subroutine
is accepted by
gfortran -v
Using built-in specs.
COLLECT_GCC=gfort
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58652
--- Comment #1 from Vladimir Fuka ---
maybe connected:
module gen_lists
type list_node
class(*),allocatable :: item
contains
procedure :: move_alloc => list_move_alloc
end type
contains
subroutine list_move_alloc(self,i
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
class(*),allocatable :: a
class(*),allocatable :: c
call move_alloc(a,c)
end
gfortran starallocatable.f90
starallocatable.f90: In function ‘MAIN__’:
starallocatable.f90:4:0: internal
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
character(1) :: s(1)
associate (x=>s(1)(1:1))
end associate
end
gfortran ice11.f90
f951: internal compiler error: Neoprávněný přístup do paměti (SIGSEGV)
0x8ba79f crash_sig
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
> gfortran -c ice3.f90
ice3.f90: In function ‘sub’:
ice3.f90:29:0: internal compiler error: Segmentation fault
call add(b())
^
0x87d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410
--- Comment #1 from Vladimir Fuka ---
Created attachment 30815
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30815&action=edit
uninit.f90
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
gfortran -c -Wall -O2 uninit.f90
uninit.f90: In function ‘sub’:
uninit.f90:22:0: warning: ‘new.dim[0].ubound’ may be used
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Program:
real c(3,3)
associate (x=>shape(c))
print *,lbound(x)
print *,ubound(x)
print *,x(1),x(2)
end associate
end
Expected result:
1
2
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
This code:
subroutine read_command_line(line,a,b)
character(*),intent(in) :: line
intent(inout) :: a,b
namelist /cmd/ a,b
read(line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57354
--- Comment #1 from Vladimir Fuka ---
valgrind ./a.out
==17600== Memcheck, a memory error detector
==17600== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==17600== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright in
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Created attachment 30154
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30154&action=edit
realloc.f90
: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
This function produces ICE with gcc-4.8 from 20130509:
function avg(a)
integer :: avg
integer,intent(in) :: a(..)
avg = sum(a)/size(a)
end function
gfortran -c ice9.f90
ice9.f90: In function ‘avg’:
ice9
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
integer,allocatable :: a(:)
integer :: e
allocate(a,source=[e])
end
produces:
gfortran -c ice8.f90
f951: internal compiler error: NeoprĂĄvnÄĂ˝ pĹĂstup do pamÄi (SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
--- Comment #3 from Vladimir Fuka ---
The first one is incorrect code, the other one compiles with ifort 13.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
--- Comment #2 from Vladimir Fuka ---
Connected error:
gfortran -Wall -c ice7.f90
ice7.f90: In function âadd_element_polyâ:
ice7.f90:25:0: internal compiler error: in lhd_incomplete_type_error, at
langhooks.c:203
dummy = memcpy(loc(a(si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
--- Comment #1 from Vladimir Fuka ---
Created attachment 30136
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30136&action=edit
ice7.f90 (second source)
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
Created attachment 30135
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30135&action=edit
source
The attached code produces ICE with recent build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57022
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57000
--- Comment #1 from Vladimir Fuka 2013-04-18
19:20:38 UTC ---
Created attachment 29899
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29899
Preprocessed was too long, is at
http://artax.karlin.mff.cuni.cz/~fukav1am/polyhedron-preproc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57000
Bug #: 57000
Summary: 4.8 Regression?, ICE with -Ofast and -frounding-math
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386
--- Comment #3 from Vladimir Fuka 2013-04-16
17:40:04 UTC ---
Thanks, I didn't realize they might be connected. I even forgotten I have
this bug opened when I asked.
Vladimir
Dne 16.4.2013 19:17 "burnus at gcc dot gnu.org"
napsal(a)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471
Bug #: 56471
Summary: Program crashes when allocating a derived type with a
character allocatable array component.
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386
Bug #: 56386
Summary: ICE with ASSOCIATE construct and an derived type array
component
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56385
Bug #: 56385
Summary: ICE with allocatable function result in a type-bound
procedure
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
100 matches
Mail list logo
