[Bug fortran/41219] libgfortran build warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #27 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-01 22:31:00 UTC --- Fixed now.
[Bug fortran/41219] libgfortran build warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219 --- Comment #26 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-10-14 01:29:41 UTC --- *** Bug 45998 has been marked as a duplicate of this bug. ***
[Bug fortran/41219] libgfortran build warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org
[Bug fortran/41219] libgfortran build warnings
--- Comment #23 from dfranke at gcc dot gnu dot org 2010-05-07 16:00 --- My build log seems to be clean (i686-pc-linux-gnu). Is this PR still needed? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #24 from nightstrike at gmail dot com 2010-05-07 17:18 --- This is for mingw, not linux. I can test again when our buildbot farm is back up. Should be in the next few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #25 from sezeroz at gmail dot com 2010-05-07 17:44 --- (In reply to comment #23) My build log seems to be clean (i686-pc-linux-gnu). Is this PR still needed? The commit from comment #14 (as inlined in comment #9) introduces a new warning of passing argument 2 of 'write_default_char4' discards qualifiers from pointer target type, because write_default_char4() accepts a gfc_char4_t* but we are sending it a const gfc_char4_t*. Easiest solution would be constifying the second arg of write_default_char4(), as well as that of write_utf8_char4() for that matter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #22 from fxcoudert at gcc dot gnu dot org 2009-12-29 15:48 --- *** Bug 29313 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #21 from jb at gcc dot gnu dot org 2009-10-30 22:37 --- Subject: Bug 41219 Author: jb Date: Fri Oct 30 22:37:47 2009 New Revision: 153769 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153769 Log: PR libfortran/41219 Fix build warnings Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/iso_c_binding.c trunk/libgfortran/intrinsics/unpack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #15 from nightstrike at gmail dot com 2009-09-21 16:30 --- Current list: ../../../../../build/gcc/gcc/libgfortran/io/list_read.c:1847:10: warning: variable 'elem' might be clobbered by 'longjmp' or 'vfork' ../../../../../build/gcc/gcc/libgfortran/io/list_read.c:1849:10: warning: variable 'stride' might be clobbered by 'longjmp' or 'vfork' ../../../../../build/gcc/gcc/libgfortran/io/write.c:328:8: warning: passing argument 2 of 'write_default_char4' discards qualifiers from pointer target type ../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24: warning: 'str' may be used uninitialized in this function ../../../../../build/gcc/gcc/libgfortran/intrinsics/unpack_generic.c:60:32: warning: unused parameter 'fsize' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #16 from nightstrike at gmail dot com 2009-09-21 16:33 --- (In reply to comment #14) Subject: Bug 41219 Author: jvdelisle Date: Sat Sep 12 15:08:27 2009 New Revision: 151653 As of r151914, this warning still exists when the host=linux64 and the target=win64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #17 from burnus at gcc dot gnu dot org 2009-09-21 17:01 ---
../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
warning: 'str' may be used uninitialized in this function
I think this warning is bogus:
index_type size, str;
for (i = 0; i shapeSize; i++)
{
if (i == 0)
str = 1;
else
str = str * GFC_DESCRIPTOR_EXTENT(f_ptr_out,i-1);
But one could add a str = 1 to silence the compiler ...
../../../../../build/gcc/gcc/libgfortran/io/write.c:328:8: warning: passing
argument 2 of 'write_default_char4' discards qualifiers from pointer target
crlf is const while write_default_char4 takes a normal char4 *. (The
question is whether we can't simply make that const char4 * - ditto for
write_char etc.) If not, I think one can silent this warning (I somewhere had a
note how to do this).
../../../../../build/gcc/gcc/libgfortran/io/list_read.c:1847:10: warning:
variable 'elem' might be clobbered by 'longjmp' or 'vfork'
../../../../../build/gcc/gcc/libgfortran/io/list_read.c:1849:10: warning:
variable 'stride' might be clobbered by 'longjmp' or 'vfork'l
I think this comes due to list_formatted_read_scalar which uses
setjmp(). I currently do not see whether there is a real problem or not;
volatile should help, but one should first search for another solution.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #18 from nightstrike at gmail dot com 2009-09-21 17:36 ---
(In reply to comment #17)
../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
warning: 'str' may be used uninitialized in this function
I think this warning is bogus:
index_type size, str;
for (i = 0; i shapeSize; i++)
{
if (i == 0)
str = 1;
else
str = str * GFC_DESCRIPTOR_EXTENT(f_ptr_out,i-1);
But one could add a str = 1 to silence the compiler ...
This looks dumb to begin with. Just initialize str to 1 and run the for-loop
from 1 to shapeSize. Starting at 0 and special casing zero is absurd.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #19 from kargl at gcc dot gnu dot org 2009-09-21 18:01 ---
(In reply to comment #18)
(In reply to comment #17)
../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
warning: 'str' may be used uninitialized in this function
I think this warning is bogus:
index_type size, str;
for (i = 0; i shapeSize; i++)
{
if (i == 0)
str = 1;
else
str = str * GFC_DESCRIPTOR_EXTENT(f_ptr_out,i-1);
But one could add a str = 1 to silence the compiler ...
This looks dumb to begin with. Just initialize str to 1 and run the for-loop
from 1 to shapeSize. Starting at 0 and special casing zero is absurd.
Are you basing your comment on the code posted above or have you
actually looked at the code in iso_c_biniding.c?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #20 from nightstrike at gmail dot com 2009-09-21 18:12 ---
(In reply to comment #19)
(In reply to comment #18)
(In reply to comment #17)
../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
warning: 'str' may be used uninitialized in this function
I think this warning is bogus:
index_type size, str;
for (i = 0; i shapeSize; i++)
{
if (i == 0)
str = 1;
else
str = str * GFC_DESCRIPTOR_EXTENT(f_ptr_out,i-1);
But one could add a str = 1 to silence the compiler ...
This looks dumb to begin with. Just initialize str to 1 and run the
for-loop
from 1 to shapeSize. Starting at 0 and special casing zero is absurd.
Are you basing your comment on the code posted above or have you
actually looked at the code in iso_c_biniding.c?
The code above. I can't access the source tree atm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-09-12 14:48 --- I will do the write.c one. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #12 from nightstrike at gmail dot com 2009-09-12 05:36 --- Current warning list as of revision 151630: ../../../../../build/gcc/gcc/libgfortran/io/write.c:328:8: warning: passing argument 2 of 'write_default_char4' from incompatible pointer type ../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24: warning: 'str' may be used uninitialized in this function ../../../../../build/gcc/gcc/libgfortran/intrinsics/unpack_generic.c:60:32: warning: unused parameter 'fsize' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #10 from sezeroz at gmail dot com 2009-09-07 11:27 ---
(In reply to comment #6)
(In reply to comment #2)
Janne, I think the warning about unix.c:750:15: warning:
#65533;statbuf.st_mode#65533; may
be used uninitialized is spurious, but can you have a look?
Yes, it's spurious, and I submitted a patch
(http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00419.html), but maybe the
middle-end shouldn't warn about it anyway (see the reply by Richard Guenther).
The warning must be due to the inline fstat() implementation in
mingw-w64. Excerpt from stat.h:
__CRT_INLINE int __cdecl
fstat(int _Desc,struct stat *_Stat) {
struct _stat64 st;
int ret=_fstat64(_Desc,st);
if (ret == -1) {
memset(_Stat,0,sizeof(struct stat));
return -1;
}
/* rest of the code */
Note that the memset() in the failure case was only recently added in our svn,
at rev. 1306, so this warning shouldn't be experienced with mingw-w64 rev.1306
or later. Older revisions didn't touch the input buffer on failure which should
be the reason for the warning.
--
sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-09-08 00:59 --- Subject: Bug 41219 Author: jvdelisle Date: Tue Sep 8 00:59:05 2009 New Revision: 151495 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151495 Log: 2009-09-07 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/41192 * io/list_read.c (eat_line): Enable eat_line to function on internal units. PR libgfortran/41219 * io/list_read.c (nml_read_obj): Replace GFC_DTYPE_UNKNOWN with BT_NULL to get rid of warning. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #6 from jb at gcc dot gnu dot org 2009-09-06 13:55 --- (In reply to comment #2) Janne, I think the warning about unix.c:750:15: warning: statbuf.st_mode may be used uninitialized is spurious, but can you have a look? Yes, it's spurious, and I submitted a patch (http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00419.html), but maybe the middle-end shouldn't warn about it anyway (see the reply by Richard Guenther). Jerry, there is some inconsistency regarding st_parameter_dt's saved_type. One finds both bt and dtype assignments, which does not make sense. Does one need both types in a union? Or can one consolidate them? list_read.c: dtp-u.p.saved_type = BT_LOGICAL; list_read.c: dtp-u.p.saved_type = GFC_DTYPE_UNKNOWN; etc. I looked into this when I redid the lower layer I/O library, and I gave up in exasperation. This dichotomy between BT_* and GFC_DTYPE_* extends into the frontend, and would require lots of tedious work and an ABI change to fix. Perhaps at the same time we change the array descriptor we could fix this too (the descriptor also needs some form of type tag, and if we adopt the TR29113 descriptor that then also influences the type tag). I added a note about this to http://gcc.gnu.org/wiki/LibgfortranAbiCleanup . As an additional bonus, note that the bt enum is different in the frontend and the library, and some of the library entry points take bt enums as arguments, which makes one one wonder how the heck all this works.. :) In write_a_char4, one has: const char crlf[] = \r\n; write_default_char4 (dtp, crlf, 2, 0); but the second argument should be gfc_char4_t* Right. So what is \r\n in terms of gfc_char4_t? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-09-06 18:17 --- Let me fix this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-09-03 06:55:42 |2009-09-06 18:17:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-09-06 21:21
---
The following patch gets rid of the two warnings in list_read.c. The two
enumerators have equivalent value. Regression tests fine.
@@ -2377,7 +2377,7 @@
/* GFC_TYPE_UNKNOWN through for nulls and is detected
after the switch block. */
- dtp-u.p.saved_type = GFC_DTYPE_UNKNOWN;
+ dtp-u.p.saved_type = BT_NULL;
free_saved (dtp);
switch (nl-type)
@@ -2467,7 +2467,7 @@
return SUCCESS;
}
- if (dtp-u.p.saved_type == GFC_DTYPE_UNKNOWN)
+ if (dtp-u.p.saved_type == BT_NULL)
{
dtp-u.p.expanded_read = 0;
goto incr_idx;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-09-07 02:57
---
Regarding comment #6.
In write_a_char4, one has:
const char crlf[] = \r\n;
write_default_char4 (dtp, crlf, 2, 0);
but the second argument should be gfc_char4_t*
Right. So what is \r\n in terms of gfc_char4_t?
I believe the following is the correct fix for this. I have partially tested
this but need to do some more testing.
Index: write.c
===
--- write.c (revision 151441)
+++ write.c (working copy)
@@ -293,7 +293,7 @@
Standard sections 10.6.3 and 9.9 for further information. */
if (is_stream_io (dtp))
{
- const char crlf[] = \r\n;
+ const gfc_char4_t crlf[] = {0x000d,0x000a};
int i, bytes;
gfc_char4_t *qq;
bytes = 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #5 from burnus at gcc dot gnu dot org 2009-09-04 09:25 --- Subject: Bug 41219 Author: burnus Date: Fri Sep 4 09:25:00 2009 New Revision: 151417 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151417 Log: 2009-09-04 Tobias Burnus bur...@net-b.de PR fortran/41219 * intrinsics/getlog.c: Define _POSIX for MINGW32. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/getlog.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #1 from burnus at gcc dot gnu dot org 2009-09-03 06:55 --- Thomas, I think do to your changes one now gets a warning (unused argument) for libgfortran/intrinsics/unpack_generic.c. The last argument of unpack_internal (index_type fsize) is no longer used; as the function is static, one can simply remove it and update the callers (where some __attribute__((unused)) has then to be added). Is there really no need for the argument? Any any case, can you have a look and create a patch? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-03 06:55:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #2 from burnus at gcc dot gnu dot org 2009-09-03 07:12 --- Nightstrike: I do not understand libgfortran/intrinsics/getlog.c:85:3: warning: implicit declaration of function getlogin There is a #if defined __MINGW32__ !defined HAVE_GETLOGIN block which should make sure that it is defined. Can you try to find out what goes wrong? * * * Janne, I think the warning about unix.c:750:15: warning: statbuf.st_mode may be used uninitialized is spurious, but can you have a look? * * * Jerry, there is some inconsistency regarding st_parameter_dt's saved_type. One finds both bt and dtype assignments, which does not make sense. Does one need both types in a union? Or can one consolidate them? list_read.c: dtp-u.p.saved_type = BT_LOGICAL; list_read.c: dtp-u.p.saved_type = GFC_DTYPE_UNKNOWN; etc. Currently, one gets a compile-time warning (see comment 0). In write_a_char4, one has: const char crlf[] = \r\n; write_default_char4 (dtp, crlf, 2, 0); but the second argument should be gfc_char4_t* -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org, ||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #3 from burnus at gcc dot gnu dot org 2009-09-03 07:36 --- Subject: Bug 41219 Author: burnus Date: Thu Sep 3 07:36:36 2009 New Revision: 151371 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151371 Log: 2009-09-03 Tobias Burnus bur...@net-b.de PR fortran/41219 * intrinsics/iso_c_binding.c (c_f_pointer_u0): Move variable declaration out of the loop. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/iso_c_binding.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41219] libgfortran build warnings
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-03 08:36 --- The getlogin function is getting prototyped in headers only, if the _POSIX define was set. So a bug-fix here would be for w64 to define before including headers the _POSIX macro. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
