[Bug fortran/85840] Memory leak in write.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #9 from Joshua Cogliati --- Looking at write.c, there are multiple places where things like the pattern: result = select_string (dtp, f, str_buf, _len, kind); ... get_float_string (dtp, f, source , kind, 0, buffer, precision, buf_size, result, _len); ... if (res_len > BUF_STACK_SZ) free (result); appear (such as write_complex, write_real etc). So either they all need to be fixed, or get_float_string needs to never change the length compared to select_string. I could look into either method of fixing this if you want. (And for what it is worth, I do have copyright assignment paperwork from both myself and my employer for GCC filed)
[Bug fortran/85840] Memory leak in write.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #8 from Joshua Cogliati --- Created attachment 44186 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44186=edit Patch by keeping original length This patches the problem by storing the allocated length in a separate variable. This also fixes the problem with the free not being called. Both these patches are against svn 260704.
[Bug fortran/85840] Memory leak in write.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #7 from Joshua Cogliati --- Created attachment 44185 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44185=edit Patch by checking against original buffer This is one possible patch for this problem, it just checks if the buffer is at a different address than the stack buffer. It does fix the problem in my test case.
[Bug fortran/85840] Memory leak in write.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #4 from Joshua Cogliati --- And to replicate it with the simple program: gfortran -Wall -g -o simple simple.f90 valgrind --leak-check=full ./simple and you get things like: ==19171== 323 bytes in 1 blocks are definitely lost in loss record 4 of 4 ==19171==at 0x4C2CB6B: malloc (vg_replace_malloc.c:299) ==19171==by 0x4E53454: _gfortrani_xmalloc (memory.c:42) ==19171==by 0x4FD637A: write_float_0 (write.c:1593) ==19171==by 0x4FCD98C: formatted_transfer_scalar_write (transfer.c:2041) ==19171==by 0x4FCDF9C: formatted_transfer (transfer.c:2279) ==19171==by 0x4008A5: MAIN__ (simple.f90:10) ==19171==by 0x4008EB: main (simple.f90:11)
[Bug fortran/85840] Memory leak in write.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #3 from Joshua Cogliati --- Created attachment 44150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44150=edit simple program to demonstrate problem
[Bug fortran/85840] Memory leak in write.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 Joshua Cogliati changed: What|Removed |Added CC||jjcogliati-r1 at yahoo dot com --- Comment #2 from Joshua Cogliati --- I haven't found a short reproducer yet. Here is how I can reproduce it. Get marbles from: http://jjc.freeshell.org/marbles/marbles.tar.gz tar -xzf marbles.tar.gz cd marbles/src cat > short <
[Bug fortran/85840] New: Memory leak in write.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 Bug ID: 85840 Summary: Memory leak in write.c Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jjcogliati-r1 at yahoo dot com Target Milestone: --- This bug comes from trying to find a memory leak in my own program. gfortran --version GNU Fortran (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5) Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The line in my code was: print '(A16,I7,6E25.16E3)',"start line print",i,a,b,c,d,e,f where a,b,c,d,e,f are complicated real kinds. The valgrind trace was: ==23064== 142,120 bytes in 440 blocks are definitely lost in loss record 39 of 49 ==23064==at 0x4C2CB6B: malloc (vg_replace_malloc.c:299) ==23064==by 0x4E53454: _gfortrani_xmalloc (memory.c:42) ==23064==by 0x4FD637A: write_float_0 (write.c:1593) ==23064==by 0x4FCD98C: formatted_transfer_scalar_write (transfer.c:2041) ==23064==by 0x4FCDF9C: formatted_transfer (transfer.c:2279) Looking at write.c, we have: /* String buffer to hold final result. */ result = select_string (dtp, f, str_buf, _len, kind); //line 1593 buffer = select_buffer (dtp, f, precision, buf_stack, _size, kind); get_float_string (dtp, f, source , kind, 0, buffer, precision, buf_size, result, _len); write_float_string (dtp, result, res_len); if (buf_size > BUF_STACK_SZ) free (buffer); if (res_len > BUF_STACK_SZ) free (result); Notice that we assign to the value of res_len from select_string AND from get_float_string, and get_float_string can assign to the length in functions called from it such as in build_float_string So I think what is happening is res_len is getting assigned a number that is smaller than BUF_STACK_SZ, and then result is not getting freed. I haven't come up with a small test case yet, but I certainly can if needed.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001
--- Comment #30 from Joshua Cogliati jjcogliati-r1 at yahoo dot com ---
Yes, it is fixed so far as I am concerned. I checked out gcc trunk 205109, and
bootstraped it and tried it out on:
int main(int argc, char ** argv) {
int i = 3.14;
return i;
}
int foo(double x)
{
return x;
}
float foo2(double x) {
return x;
}
and without the flag it didn't warn, but with the flag it did:
gcc -Wall -Wfloat-conversion -o float_test float_test.c
float_test.c: In function ‘main’:
float_test.c:2:3: warning: conversion to ‘int’ alters ‘double’ constant value
[-Wfloat-conversion]
int i = 3.14;
^
float_test.c: In function ‘foo’:
float_test.c:8:3: warning: conversion to ‘int’ from ‘double’ may alter its
value [-Wfloat-conversion]
return x;
^
float_test.c: In function ‘foo2’:
float_test.c:12:3: warning: conversion to ‘float’ from ‘double’ may alter its
value [-Wfloat-conversion]
return x;
^
I think there are two things remaining to be done.
1. http://gcc.gnu.org/gcc-4.9/changes.html does not yet list it as a change,
2. for gcc 4.10 (or what ever the next gcc version is) I think it might be
worth considering as a -Wextra or -Wall. That however would be a separate bug
number and would require something like the Patch to fixup gcc float
conversions in GCC and another patch to turn it on with the flag.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #27 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 31097 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31097action=edit Patch to add -Wfloat-conversion option against trunk with new testcase and detailed warnings This uses a detailed warnings in the testcase. I am not sure if this is a good idea or not since it might get invalidated if the types change. It bootstraps and the new testcase works on x86_64-unknown-linux-gnu
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #26 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 31065 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31065action=edit Patch to add -Wfloat-conversion option against trunk with new testcase This adds a new testcase instead of using existing testcases.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added Attachment #30979|0 |1 is obsolete|| --- Comment #24 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30994 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30994action=edit Patch to add -Wfloat-conversion option against trunk with testcases This version modifies a few more testcases.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added Attachment #30899|0 |1 is obsolete|| --- Comment #22 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30979 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30979action=edit Patch to add -Wfloat-conversion option against trunk This version only does the -Wfloat-conversion. It does not do the -Wextra or the changes needed to get -Wextra to bootstrap. It starts to change the test cases. This work is to satisfy the request on the gcc-patch list.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #23 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30980 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30980action=edit Patch to fixup gcc float conversions in GCC This changes the float conversions in gcc so that gcc bootstraps if float conversions are warned about with -Wextra. Splitting the patch was requested on gcc-patches. (Note to self: patches were created with svn diff --diff-cmd diff -x -up )
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added Attachment #30913|0 |1 is obsolete|| --- Comment #20 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30937 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30937action=edit Patch to add -Wfloat-conversion option against trunk Added one more changed needed to get it to compile (which only occured if I did an rm -Rf in the build directry, the make bootstrap didn't catch the libcpp warning found.) The only thing I have left is to possibly modify the test scripts (to use -Wfloat-conversion instead of -Wconversion for the relevant tests) and recompile against the current trunk.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #19 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30913 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30913action=edit Patch to add -Wfloat-conversion option against trunk This version is against gcc trunk (rev 202818). It now bootstraps. It adds about ten casts so that the existing float conversions in gcc are now explicit instead of implicit so that gcc can bootstrap even with the new warning.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #18 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- (In reply to Manuel López-Ibáñez from comment #17) (In reply to Joshua Cogliati from comment #16) This does not bootstrap trunk yet, because gcc has floating conversion issues and with this being enabled by -Wextra and with -Werror, gcc fails to build. Are those real bugs or normal code? So far they seem to be normal code. I'll try eliminating the warning on a few, but if there are too many I'll just split the patch into the basic warning and one that occurs on -Wextra.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added Attachment #30873|0 |1 is obsolete|| --- Comment #16 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30899 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30899action=edit Patch to add -Wfloat-conversion option against trunk This version is against gcc trunk (rev 202818). For trunk, I had to unmake unsafe_conversion_p being static (it is now extern again.) This does not bootstrap trunk yet, because gcc has floating conversion issues and with this being enabled by -Wextra and with -Werror, gcc fails to build.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added Attachment #30870|0 |1 is obsolete|| Attachment #30871|0 |1 is obsolete|| --- Comment #15 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30882 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30882action=edit Patch to add -Wfloat-conversion option Adding documentation, formating better, removing assignment from test. Still based on 4.8.1 (which will be fixed later) Still a static function, C++ seems to be bootstraped fine.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added CC||jjcogliati-r1 at yahoo dot com --- Comment #8 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30870 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30870action=edit Patch to add -Wfloat-conversion option This patch add a -Wfloat-conversion option. It adds an enumeration type called conversion_safety, with a SAFE_CONVERSION being 0, and unsafe ones being non-zero. It changes the unsafe_conversion_p to return this enumeration. This allows the floating point conversions to be handled separately. Someone who understands the c.opt file better than I should check that I did it correctly. -Wconversion implies -Wfloat-conversion. -Wall does not, but it might possibly be worth considering.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #9 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30871 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30871action=edit some floating conversion issues This tests three of the floating conversion reduction in precision issues. P.S. Copyright assignment paperwork from both myself and my employer for GCC has been sent to copyright-clerk
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #11 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30873 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30873action=edit Patch to add -Wfloat-conversion option This version also is enabled with -Wextra. $ gcc -o float_test float_test.c $ gcc -Wfloat-conversion -o float_test float_test.c float_test.c: In function ‘main’: float_test.c:2:3: warning: conversion to ‘int’ alters ‘double’ constant value [-Wfloat-conversion] int i = 3.14; ^ float_test.c: In function ‘foo’: float_test.c:8:3: warning: conversion to ‘int’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ float_test.c: In function ‘foo2’: float_test.c:12:3: warning: conversion to ‘float’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ $ gcc -Wconversion -o float_test float_test.c float_test.c: In function ‘main’: float_test.c:2:3: warning: conversion to ‘int’ alters ‘double’ constant value [-Wfloat-conversion] int i = 3.14; ^ float_test.c: In function ‘foo’: float_test.c:8:3: warning: conversion to ‘int’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ float_test.c: In function ‘foo2’: float_test.c:12:3: warning: conversion to ‘float’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ $ gcc -Wextra -o float_test float_test.c float_test.c: In function ‘main’: float_test.c:2:3: warning: conversion to ‘int’ alters ‘double’ constant value [-Wfloat-conversion] int i = 3.14; ^ float_test.c: In function ‘foo’: float_test.c:8:3: warning: conversion to ‘int’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ float_test.c: In function ‘foo2’: float_test.c:12:3: warning: conversion to ‘float’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #14 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Manuel López-Ibáñez, thank you for the patch review. I will make the changes you requested, and rebase it against svn trunk, and run bootstrap and testsuite. It may be a few weeks before I get this all done (depending on available time). UNSAFE_SIGN is unused, but when I was doing the patch, I noticed that unsafe_conversion_p basically does not report sign conversion errors, instead it does the warning directly inside the function. So there definitely is a distinct unsafe conversion type, but I am not sure if I should remove the constant entirely or not. Either way I will try and document the behavior better.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #7 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- I wrote the patch for 4.8.1 (which is the easy part), now I will see if I can get approval to submit it through the bureaucracies (the hard part).
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #5 from Joshua Cogliati jjcogliati-r1 at yahoo dot com 2012-06-22 12:29:14 UTC --- (In reply to comment #3) (In reply to comment #2) I should have time to create a patch for this before 4.8 goes into stage 3. Do you think it needs a copyright assignment and if so what paperwork would you need from my employer? I am afraid so. See: https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters Write to g...@gcc.gnu.org asking for the documents. There are several people there dealing with this matter. Also, let us know if you find any problems. I have written to to g...@gcc.gnu.org, and submitted the Employer disclaimer to my employer, but my employer is reluctant to sign it. I may not be able to create the patch because of that.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001
--- Comment #2 from Joshua Cogliati jjcogliati-r1 at yahoo dot com 2012-04-16
12:16:45 UTC ---
Yes, it should also warn for non-constants, and also for other floating
decreases in accuracy such as:
float foo(double x) {
return x;
}
I should have time to create a patch for this before 4.8 goes into stage 3. Do
you think it needs a copyright assignment and if so what paperwork would you
need from my employer?
[Bug c/53001] New: -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001
Bug #: 53001
Summary: -Wfloat-conversion should be available to warn about
floating point errors
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jjcogliati...@yahoo.com
This is a request to add a new warning that warns on the subset of -Wconversion
warnings that involve floating point numbers. For example, with
-Wfloat-conversion this would cause a warning:
int main(int argc, char ** argv) {
int i = 3.14;
return i;
}
I think this could mostly be done by modifying gcc/c-family/c-common.c
unsafe_conversion_p to add the ability to only warn on conversions where
REAL_TYPE or REAL_CST are involved.
The reason -Wconversion is not sufficient is that using it can cause hundreds
of warnings, almost all of which are integer size warnings (many of which are
in libraries (such as libMesh)). I would like to be able to enable something
like -Wfloat-conversion that would catch errors involving floating point number
conversions, while ignoring the integer size conversions.
[Bug fortran/49324] Deep copy missing for array constructors of DT w/ allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added Known to fail||4.6.1 --- Comment #11 from Joshua Cogliati jjcogliati-r1 at yahoo dot com 2011-07-11 16:37:28 UTC --- Still in 4.6.1, using original test case.
[Bug fortran/49324] New: iso_varying_string and reshape fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324
Summary: iso_varying_string and reshape fail
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jjcogliati...@yahoo.com
Iso varying string seems to fail with reshape.
I am using the iso_varying_string module available from
http://www.fortran.com/iso_varying_string.f95
My test case is:
!--
program test_ivs
use iso_varying_string
implicit none
type(varying_string),dimension(:,:),allocatable :: array2d
type(varying_string) :: extra
integer :: i,j
allocate(array2d(2,3))
extra = four
array2d(:,:) = reshape((/ var_str(1),
var_str(2), var_str(3),
extra, var_str(5),
var_str(six) /), (/ 2, 3 /))
print *,array2d second ,ubound(array2d),(('//char(array2d(i,j))//'
,i=1,size(array2d,1)),j=1,size(array2d,2))
end program test_ivs
!-
With this test case, I get the output:
array2d second2 3 '' '0' 'P' 'P!' '0' '!'
If I modify it to:
!-
program test_ivs_no_reshape
use iso_varying_string
implicit none
type(varying_string),dimension(:,:),allocatable :: array2d
type(varying_string) :: extra
integer :: i,j
allocate(array2d(2,3))
extra = four
array2d(:,1) = (/ var_str(1), var_str(2) /)
array2d(:,2) = (/ var_str(3), extra /)
array2d(:,3) = (/ var_str(5), var_str(six) /)
print *,array2d first ,ubound(array2d),(('//char(array2d(i,j))//'
,i=1,size(array2d,1)),j=1,size(array2d,2))
end program test_ivs_no_reshape
!--
I get the following output:
array2d first2 3 '1' '2' '3' 'four' '5' 'six'
which is what I expected.
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/jjc/gcc/gcc_460_install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6.0/configure --prefix=/home/jjc/gcc/gcc_460_install/
Thread model: posix
gcc version 4.6.0 (GCC)
Compiling:
$ gfortran -Wall -c iso_varying_string.f95
$ gfortran -Wall -o test_ivs.f90 test_ivs.f90 iso_varying_string.o
$ ./test_ivs
array2d second2 3 '' '0' 'P' 'PQ�' '0' 'Q�'
[Bug fortran/49324] iso_varying_string and reshape fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 --- Comment #2 from Joshua Cogliati jjcogliati-r1 at yahoo dot com 2011-06-08 16:30:16 UTC --- (In reply to comment #1) Not an analysis, just some observations ... I get different results with different compilers: gfortran 4.7: array2d second2 3 '' '@' '`' '`A�▒' '@' 'A�' [Neither NAG with -C=all -C=undefined, nor ifort -check all, nor gfortran -fcheck=all show an error.] I tried also the other ISO Varying String implementations at ftp://ftp.nag.co.uk/sc22wg5/ISO_VARYING_STRING/Sample_Module/ , but I fail to get a consistent result with those. gfortran, g95, NAG, pgf90 and pathf95 with iso_vst.f90 and with g95, pgf90 and pathf95 for iso_vsta.f90: array2d second2 3 '1' '2' '3' 'four' '5' 'six' gfortran with iso_vsta.f90: array2d second2 3 '' '�' '�' '�jb' '�' 'b' Hm. http://www.fortran.com/iso_varying_string.f95 and iso_vsta.f90 use: TYPE VARYING_STRING PRIVATE CHARACTER,DIMENSION(:),ALLOCATABLE :: chars ENDTYPE VARYING_STRING iso_vst.f90 uses: TYPE VARYING_STRING PRIVATE CHARACTER,DIMENSION(:),POINTER :: chars = NULL() ENDTYPE VARYING_STRING so for gfortran at least, it seems to happen when there is a allocatable character array, but not a pointer.
[Bug c++/47367] internal compiler error: verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47367 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added CC||jjcogliati-r1 at yahoo dot ||com --- Comment #3 from Joshua Cogliati jjcogliati-r1 at yahoo dot com 2011-01-20 18:00:17 UTC --- It is fixed in gcc-4.6-20110115. I also get it gcc 4.5.1, so I would like to check in gcc 4.5.2 before this gets closed.
[Bug c++/47367] internal compiler error: verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47367 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #4 from Joshua Cogliati jjcogliati-r1 at yahoo dot com 2011-01-20 18:52:41 UTC --- Also fixed in gcc 4.5.2. Closing.
[Bug c++/47367] New: internal compiler error: verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47367 Summary: internal compiler error: verify_cgraph_node failed Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jjcogliati...@yahoo.com Created attachment 23038 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23038 preprocessed source from VTK. Internal compiler error found. /home/jjc/gcc/gcc_install/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/jjc/gcc/gcc_install/bin/g++ COLLECT_LTO_WRAPPER=/home/jjc/gcc/gcc_install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6-20101218/configure --prefix=/home/jjc/gcc/gcc_install Thread model: posix gcc version 4.6.0 20101218 (experimental) (GCC) command line: /home/jjc/gcc/gcc_install/bin/g++ -DvtkCommon_EXPORTS -DVTK_IN_VTK -m64 -fPIC -Wno-deprecated -O3 -DNDEBUG -fPIC -c vtkMultiThreader.ii Output: /home/jjc/visit_dir/VTK/Common/vtkMultiThreader.cxx: In static member function ‘static int vtkMultiThreader::ThreadsEqual(vtkMultiThreaderIDType, vtkMultiThreaderIDType)’: /home/jjc/visit_dir/VTK/Common/vtkMultiThreader.cxx:746:30: error: inline clone is needed int pthread_equal(pthread_t, pthread_t)/50(42) @0x7fdc3335d9a0 (asm: pthread_equal) (inline copy in static int vtkMultiThreader::ThreadsEqual(vtkMultiThreaderIDType, vtkMultiThreaderIDType)/332) availability:available analyzed 3 time, 15 benefit 4 size, 7 benefit needed reachable body finalized always_inline called by: static int vtkMultiThreader::ThreadsEqual(vtkMultiThreaderIDType, vtkMultiThreaderIDType)/332 (1.00 per call) (inlined) calls: References: Refering this function: /home/jjc/visit_dir/VTK/Common/vtkMultiThreader.cxx:746:30: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug libfortran/43298] New: fortran library does not read in NaN -Inf or Inf
As I understand it, fortran should be able to read in a NaN or Inf value.
See 10.6.1.2.1 F editing in the Fortran 2003 specification. This is a new
Fortran 2003 feature and is not in the Fortran 95 specification.
gfortran properly prints out the NaN values, but cannot read them in, thus
causing the following program to fail:
program nan_test
character(15) :: nan = ' NAN -INF INF'
real :: a,b,c, d = 0.0
print ('(3F5.2)'),0.0/d,-1.0/d,1.0/d
read (nan,'(3F5.2)'),a,b,c
print *,f
end program nan_test
I have tried with both 4.5.0 20100121 and 4.4.3.
--
Summary: fortran library does not read in NaN -Inf or Inf
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jjcogliati-r1 at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43298
[Bug libfortran/43298] fortran library does not read in NaN -Inf or Inf
--- Comment #1 from jjcogliati-r1 at yahoo dot com 2010-03-08 21:17 ---
program should be: (both exhibit the bug though, but this works if bug is not
present)
program nan_test
implicit none
character(15) :: nan = ' NAN -INF INF'
real :: a,b,c, d = 0.0
print ('(3F5.2)'),0.0/d,-1.0/d,1.0/d
read (nan,'(3F5.2)'),a,b,c
print *,a,b,c
end program nan_test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43298
[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp
--- Comment #15 from jjcogliati-r1 at yahoo dot com 2010-01-13 23:27
---
(In reply to comment #14)
I am testing the workaround
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 155860)
+++ gcc/gimple.c(working copy)
@@ -3707,8 +3707,12 @@ iterative_hash_gimple_type (tree type, h
/* For integer types hash the types min/max values and the string flag. */
if (TREE_CODE (type) == INTEGER_TYPE)
{
- v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
- v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
+ /* OMP lowering can introduce error_mark_node in place of
+random local decls in types. */
+ if (TYPE_MIN_VALUE (type) != error_mark_node)
+ v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
+ if (TYPE_MAX_VALUE (type) != error_mark_node)
+ v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
}
With the above patch, my code now both compiles, and runs its testcases
correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42665
[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp
--- Comment #12 from jjcogliati-r1 at yahoo dot com 2010-01-12 21:14
---
(In reply to comment #10)
Subject: Re: Internal compiler exception in with gfortran
when using -fwhole-program -flto -fopenmp
On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
--- Comment #9 from jjcogliati-r1 at yahoo dot com 2010-01-11 17:15
---
My hunch, (and I could be wrong since my knowledge of gcc's tree code was
zero
as of Friday morning) is that it is trying to find the array's min and max
size, but that only the min location is available, and that the max value is
undefined. Since this is fortran code, there are a number of places that I
do
that. Is that plausible, and if so, how would I check this hunch?
It should never be error_mark_node ...
Getting permission for me to get you the full code would involve a lot of
bureaucracy (weeks to months).
Oh, I see ...
You could try putting an assert in
lto-streamer-out.c:lto_output_ts_type_tree_pointers so that
the TYPE_MIN/MAXVAL are not error_mark_node.
That would point you to the file and function.
Richard.
That did the trick. Thank you.
Added lto-streamer-out.c:lto_output_ts_type_tree_pointers:
else if (TREE_CODE (expr) == ARRAY_TYPE) {
+gcc_assert(TYPE_MAX_VALUE (TYPE_DOMAIN (expr) ) == NULL ||
+ TREE_CODE (TYPE_MAX_VALUE (TYPE_DOMAIN (expr) )) != ERROR_MARK
);
lto_output_tree_or_ref (ob, TYPE_DOMAIN (expr), ref_p);
}
I can now trigger the original ice with the following valid (I think) code:
!list_use.f90
program list_use
use list_test
implicit none
integer, dimension(10) :: a_list
a_list = 1
call loop_list(a_list)
end program list_use
!list_test.f90
module list_test
!$ use omp_lib
implicit none
contains
subroutine loop_list(list)
integer, intent(in), dimension(:) :: list
integer :: ii
!$ integer :: chunk_size
!$ chunk_size = 4
!$OMP PARALLEL DO SCHEDULE(dynamic,chunk_size)
do ii=1,size(list)
call do_things(list, ii)
end do
end subroutine loop_list
subroutine do_things(list, index)
integer, intent(in),dimension(:) :: list
integer, intent(in) :: index
print *,size(list),index
end subroutine do_things
end module list_test
$ ~/gcc/old4_gcc45/bin/gfortran -Wall -o list_use -fopenmp -fwhole-program
-flto list_test.f90 list_use.f90
lto1: internal compiler error: in iterative_hash_expr, at tree.c:6592
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: /home/jjc/gcc/old4_gcc45/bin/gfortran returned 1 exit status
collect2: lto-wrapper returned 1 exit status
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42665
[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp
--- Comment #7 from jjcogliati-r1 at yahoo dot com 2010-01-11 15:50 ---
(In reply to comment #6)
Try
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 155739)
+++ gcc/gimple.c(working copy)
@@ -3707,8 +3707,10 @@ iterative_hash_gimple_type (tree type, h
/* For integer types hash the types min/max values and the string flag.
*/
if (TREE_CODE (type) == INTEGER_TYPE)
{
- v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
- v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
+ if (TYPE_MIN_VALUE (type))
+ v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
+ if (TYPE_MAX_VALUE (type))
+ v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
}
I tried that patch. Still errors out with backtrace:
#0 iterative_hash_expr (t=0x71e96b70, val=154387133)
at ../../gcc-4.5-20100107/gcc/tree.c:6592
#1 0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888,
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3713
#2 0x005ee843 in visit (t=0x71df3888, state=0x126b4b0,
v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#3 0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0,
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3722
#4 0x005ee843 in visit (t=0x71df37e0, state=0x126b4a0,
v=4237831805, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#5 0x005ee180 in iterative_hash_gimple_type (type=0x71df3bd0,
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3703
#6 0x005ee6eb in gimple_type_hash (p=0x71df3bd0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3831
#7 0x00bfb821 in htab_find_slot (htab=0x11de980,
element=0x71df3bd0, insert=INSERT)
at ../../gcc-4.5-20100107/libiberty/hashtab.c:681
#8 0x005f76e3 in gimple_register_type (t=0x71df3bd0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3873
#9 0x005f76c6 in gimple_register_type (t=0x71df3738)
at ../../gcc-4.5-20100107/gcc/gimple.c:3868
#10 0x0048cbb7 in lto_read_in_decl_state (data=value optimized out,
state=value optimized out) at ../../gcc-4.5-20100107/gcc/lto/lto.c:174
#11 0x0048f036 in lto_read_decls (resolutions=value optimized out,
data=value optimized out, decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:237
#12 lto_file_read (resolutions=value optimized out,
data=value optimized out, decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:377
#13 read_cgraph_and_symbols (resolutions=value optimized out,
data=value optimized out, decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:1839
#14 lto_main (resolutions=value optimized out, data=value optimized out,
decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:2061
#15 0x0073fc26 in compile_file ()
at ../../gcc-4.5-20100107/gcc/toplev.c:1053
#16 do_compile () at ../../gcc-4.5-20100107/gcc/toplev.c:2405
#17 toplev_main () at ../../gcc-4.5-20100107/gcc/toplev.c:2447
#18 0x00378c01eb1d in __libc_start_main (main=value optimized out,
argc=value optimized out, ubp_av=value optimized out,
init=value optimized out, fini=value optimized out,
rtld_fini=value optimized out, stack_end=value optimized out)
at libc-start.c:220
Same generally looking types as above (ERROR_MARK, INTEGER_TYPE ...)
Is there anyway for me to find out what filename and line number are being
compiled at this point? That would help me figure out a smaller testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42665
[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp
--- Comment #9 from jjcogliati-r1 at yahoo dot com 2010-01-11 17:15 ---
My hunch, (and I could be wrong since my knowledge of gcc's tree code was zero
as of Friday morning) is that it is trying to find the array's min and max
size, but that only the min location is available, and that the max value is
undefined. Since this is fortran code, there are a number of places that I do
that. Is that plausible, and if so, how would I check this hunch?
Getting permission for me to get you the full code would involve a lot of
bureaucracy (weeks to months).
(gdb) p type-base
$32 = {code = ARRAY_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0,
nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0,
protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0,
lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0,
visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
(gdb) list
3717 /* For array types hash their domain and the string flag. */
3718 if (TREE_CODE (type) == ARRAY_TYPE
3719 TYPE_DOMAIN (type))
3720{
3721 v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
3722 v = visit (TYPE_DOMAIN (type), state, v,
3723 sccstack, sccstate, sccstate_obstack);
3724}
3725
3726 /* Recurse for aggregates with a single element type. */
(gdb) where
#0 iterative_hash_expr (t=0x71e96b70, val=154387133)
at ../../gcc-4.5-20100107/gcc/tree.c:6592
#1 0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888,
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3713
#2 0x005ee843 in visit (t=0x71df3888, state=0x126b4b0,
v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#3 0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0,
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3722
(gdb) down
#2 0x005ee843 in visit (t=0x71df3888, state=0x126b4b0,
v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
3599 tem = iterative_hash_gimple_type (t, v,
(gdb) down
#1 0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888,
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3713
3713 v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
(gdb) p type-type.minval
$33 = (tree) 0x71d995c8
(gdb) p (type-type.minval)-base
$34 = {code = INTEGER_CST, side_effects_flag = 0, constant_flag = 1,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0,
nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0,
protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0,
lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0,
visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
(gdb) p (type-type.maxval)-base
$35 = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0,
nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0,
protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0,
lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0,
visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42665
[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp
--- Comment #11 from jjcogliati-r1 at yahoo dot com 2010-01-11 18:58
---
(In reply to comment #10)
Subject: Re: Internal compiler exception in with gfortran
when using -fwhole-program -flto -fopenmp
On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
--- Comment #9 from jjcogliati-r1 at yahoo dot com 2010-01-11 17:15
---
My hunch, (and I could be wrong since my knowledge of gcc's tree code was
zero
as of Friday morning) is that it is trying to find the array's min and max
size, but that only the min location is available, and that the max value is
undefined. Since this is fortran code, there are a number of places that I
do
that. Is that plausible, and if so, how would I check this hunch?
It should never be error_mark_node ...
Okay, so:
(gdb) down
#3 0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0,
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3722
3722 v = visit (TYPE_DOMAIN (type), state, v,
(gdb) p type-type.values-type.maxval-base
$67 = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0,
nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0,
protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0,
lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0,
visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
That should not have happened, since it is ERROR_MARK
I think the assert that would have triggered would need to check:
TREE_CODE (TYPE_MAX_VALUE (TYPE_DOMAIN (type) )) != ERROR_MARK
tho it would probably need to check a few of the intermediate values.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42665
[Bug lto/42665] New: Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp
When using -fwhole-program -flto -fopenmp on a program with gcc-4.5-20100107, I
get an internal compiler exception. If I remove the -fopenmp, the program
compiles fine. If I remove the -flto -fwhole-program, the program compiles
fine.
I have only been able to trigger this in a multi-thousand line program
proprietary program, and have not yet figured out a small test case that causes
this. If you have any hints as to how to create a small test case, I will try
them. I cannot provide the full program source code.
Approximate command line:
gfortran -march=native -std=f95 -g -Wall -pedantic -O3 -Wline-truncation
-fopenmp -fbounds-check -fwhole-program -flto -o program lots.o of.o dot.o
files.o
Error:
lto1: internal compiler error: in iterative_hash_expr, at tree.c:6592
Relevant portion of gcc/tree.c:
/* FALL THROUGH */
default:
tclass = TREE_CODE_CLASS (code);
if (tclass == tcc_declaration)
{
/* DECL's have a unique ID */
val = iterative_hash_host_wide_int (DECL_UID (t), val);
}
else
{
gcc_assert (IS_EXPR_CODE_CLASS (tclass));
val = iterative_hash_object (code, val);
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jjc/gcc/gcc45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20100107/configure --prefix=/home/jjc/gcc/gcc45
--enable-languages=c,c++,fortran,lto,objc --disable-multilib
Thread model: posix
gcc version 4.5.0 20100107 (experimental) (GCC)
--
Summary: Internal compiler exception in with gfortran when using
-fwhole-program -flto -fopenmp
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jjcogliati-r1 at yahoo dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42665
[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp
--- Comment #2 from jjcogliati-r1 at yahoo dot com 2010-01-08 21:27 --- (In reply to comment #1) Can you run it in a debugger and print what 'code' actually is? Can you check if removing -g fixes the ICE? The ICE still happens when -g is removed. I'm working on trying it in a debugger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42665
[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp
--- Comment #3 from jjcogliati-r1 at yahoo dot com 2010-01-08 21:38 --- (In reply to comment #1) Can you run it in a debugger and print what 'code' actually is? Can you check if removing -g fixes the ICE? Code is: ERROR_MARK (gdb) break tree.c:6592 Breakpoint 1 at 0x89a063: file ../../gcc-4.5-20100107/gcc/tree.c, line 6592. (gdb) run Starting program: /home/jjc/gcc/gcc45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto1 -quiet -dumpbase program -dumpdir ./ -mtune=generic -auxbase-strip /tmp/ccxQqVMb.lto.o -O3 -Wall -pedantic -Wline-truncation -std=f95 -version -fopenmp -fbounds-check -fwhole-program @/tmp/cce2vBEb -o program.s GNU GIMPLE (GCC) version 4.5.0 20100107 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20100107 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU GIMPLE (GCC) version 4.5.0 20100107 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20100107 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Breakpoint 1, iterative_hash_expr (t=0x71e96b70, val=154387133) at ../../gcc-4.5-20100107/gcc/tree.c:6592 6592 gcc_assert (IS_EXPR_CODE_CLASS (tclass)); (gdb) p tclass $1 = 0 '\000' (gdb) p code $2 = ERROR_MARK (gdb) c Continuing. lto1: internal compiler error: in iterative_hash_expr, at tree.c:6592 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Program exited with code 04. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42665
[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp
--- Comment #5 from jjcogliati-r1 at yahoo dot com 2010-01-08 22:28 ---
(In reply to comment #4)
Subject: Re: Internal compiler exception in with gfortran
when using -fwhole-program -flto -fopenmp
On Fri, 8 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
--- Comment #3 from jjcogliati-r1 at yahoo dot com 2010-01-08 21:38
---
(In reply to comment #1)
Can you run it in a debugger and print what 'code' actually is? Can you
check if removing -g fixes the ICE?
Code is:
ERROR_MARK
Hm, ok. I guess we need a testcase anyway. A tarball with all
preprocessed sources is probably enough. You can also try reducing
the set of files required by performing incremental linking with
-r and omit files one-by-one.
Richard.
(gdb) p *t
$16 = {base = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0,
used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0, protected_flag = 0, deprecated_flag = 0,
saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0,
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0,
user_align = 0, spare = 0, address_space = 0}, common = {base = {
code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0,
used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0, protected_flag = 0, deprecated_flag = 0,
saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0,
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0,
user_align = 0, spare = 0, address_space = 0}, chain = 0x0,
if we go up 1 to:
(gdb) up
#1 0x005ee1cc in iterative_hash_gimple_type (type=0x71df3888,
val=value optimized out, sccstack=0x7fffda38, sccstate=0x1269440,
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3711
3711 v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
(gdb) p type
$17 = (union tree_node *) 0x71df3888
(gdb) p *type
$18 = {base = {code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0,
used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0, protected_flag = 0, deprecated_flag = 0,
saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0,
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0,
user_align = 0, spare = 0, address_space = 0}, common = {base = {
code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0,
used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0, protected_flag = 0, deprecated_flag = 0,
saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0,
Maybe that helps. If I have inspiration over the weekend I will try to make a
test case on Monday.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42665
[Bug libfortran/38097] New: gfortran does not allow blanks in exponent in float (even with BN)
The following program works in g77, but gets an 'Bad value during floating point read' error in gfortran. c blank_test.f program character(11) :: a = ' 2.0030e+ 3' real :: f read (a,'(BN,E11.0)'),f print *,f end c end of program I think that ' 2.0030e+ 3' should be a proper floating point value when BN editing is enabled. I am not sure what this should do when blank processing is unspecified. -- Summary: gfortran does not allow blanks in exponent in float (even with BN) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jjcogliati-r1 at yahoo dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38097
[Bug bootstrap/29316] gcc-4.1.1 fails to bootstrap again
--- Comment #3 from jjcogliati-r1 at yahoo dot com 2006-11-13 04:35 --- (In reply to comment #2) Use --disable-multilib as ppc-darwin is configured by default to also build the 64bit libraries. Why is this not a bug? --disable-multilib is not mentioned in http://gcc.gnu.org/install/specific.html#powerpc-x-x Either fix the documentation or fix the default. -- jjcogliati-r1 at yahoo dot com changed: What|Removed |Added CC||jjcogliati-r1 at yahoo dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29316
[Bug fortran/27470] [4.1 regression] wrong memory allocator for derived types
--- Comment #14 from jjcogliati-r1 at yahoo dot com 2006-06-28 18:02 --- This works in 4.1.0, so only 4.1.1 has this bug so far as I can tell. -- jjcogliati-r1 at yahoo dot com changed: What|Removed |Added CC||jjcogliati-r1 at yahoo dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27470
[Bug fortran/23375] show location for runtime errors
--- Comment #5 from jjcogliati-r1 at yahoo dot com 2006-05-24 12:49 --- (In reply to comment #4) (In reply to comment #3) So in GCC 4.1.0, the only problem seems to be that _gfortran_runtime_error is not printing the filename and the line number and the line number seems to be the line number of the previous statement, not the one that errors. runtime_error is also called from lots of places from within libgfortran, and there is currently no way to pass line number information to intrinsics. So, make a new function like runtime_error_with_lineinfo, and have that called instead when there is line information. I believe that gfor_fndecl_runtime_error declared in gcc-4.1.0/gcc/fortran/trans-decl.c is only used by trans.c in gfc_trans_runtime_check which always has line number information. So, how to make a patch for this: Create a runtime_error_with_loc in gcc-4.1.0/libgfortran/runtime/error.c that uses the a line number and filename. Change the gfor_fndecl_runtime_error to call runtime_error_with_loc instead of runtime_error in gcc-4.1.0/gcc/fortran/trans-decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug fortran/23375] show location for runtime errors
--- Comment #3 from jjcogliati-r1 at yahoo dot com 2006-05-10 13:54 ---
(In reply to comment #1)
Confirmed. Though sometimes I wonder if this is an over use of printf style
debugging.
rantWell, I have a fortran program. It ran fine for the first 10 and a half
hours. Then it died with the error: Fortran runtime error: Array reference
out of bounds Any hints on debugging it?/rant
The front end seems to support filenames and line numbers. bad_array.f90:
program bad_array
integer,dimension(8) :: array
array(9) = 123
array(10) = 321
end program bad_array
gfortran -fdump-tree-all -fbounds-check bad_array.f90
bad_array.f90.t02.original:
MAIN__ ()
{
int4 array[8];
_gfortran_set_std (86, 127, 0);
_gfortran_runtime_error (Array reference out of bounds, bad_array.f90,
1);
array[8] = 123;
_gfortran_runtime_error (Array reference out of bounds, bad_array.f90,
3);
array[9] = 321;
}
So in GCC 4.1.0, the only problem seems to be that _gfortran_runtime_error is
not printing the filename and the line number and the line number seems to be
the line number of the previous statement, not the one that errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug fortran/26787] New: Assigning to function causes ice in gfortran
The following incorrect code causes: simple.f90: In function bar: simple.f90:4: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:355 Code: module simple implicit none contains integer function foo() foo = 10 end function foo subroutine bar() foo = 10 end subroutine bar end module simple This should cause an error, rather than an internal compiler error. -- Summary: Assigning to function causes ice in gfortran Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jjcogliati-r1 at yahoo dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26787
[Bug fortran/26791] New: Array reference out of bounds runtime error should print more information
Take the program: program bad_array integer,dimension(8) :: array array(9) = 123 end program bad_array Compile with: gfortran -g -fbounds-check -o bad_array bad_array.f90 Run: ./bad_array Fortran runtime error: Array reference out of bounds I would expect that this sould print the program location that caused the array out of bounds error like: Fortran runtime error: Array reference out of bounds at bad_array.f90:3 A workaround is to run in gdb and break on _gfortrani_runtime_error and then look at the stack trace. -- Summary: Array reference out of bounds runtime error should print more information Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jjcogliati-r1 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26791
[Bug fortran/26682] New: gfortran fails with -fwhole-program optimization
The following simple.f90 program: PROGRAM hello_world PRINT *,Hello, World! END PROGRAM hello_world does not compile with the following arguments: gfortran -fwhole-program -O2 -o simple simple.f90 ~/gcc_install/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../libgfortranbegin.a(fmain.o)(.text+0x23): In function `main': ../../../gcc-4.1.0/libgfortran/fmain.c:18: undefined reference to `MAIN__' collect2: ld returned 1 exit status The program compiles fine with just -O2 or -fwhole-program and prints out the expected Hello, World! I think the problem roughly is that -fwhole-program combined with -O2 is optimizing out the main function since it is not getting called internally. I was unable to find in the documentation any method of forcing external visiblity in a fortran 90 program. There was also no mention of gfortran not having -fwhole-program working in http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Optimize-Options.html -- Summary: gfortran fails with -fwhole-program optimization Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jjcogliati-r1 at yahoo dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26682
