[Bug fortran/13615] g77 -Wuninitialized doesn't produce warning on characters

[Bug fortran/13615] g77 -Wuninitialized doesn't produce warning on characters

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-01-09 04:29 -------
This is basicially fixed now after PR 12456:
t.f: In function 'warn_integer':
t.f:19: warning: 'a' is used uninitialized in this function
'c[1]{lb: 1 sz: 1}t.f: In function 'warn_character':
t.f:33: warning: ' is used uninitialized in this function


But there is only a diagnostic issue now and not just a missed optimization.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615

[Bug fortran/13615] g77 -Wuninitialized doesn't produce warning on characters

[paul dot richard dot thomas at cea dot fr]

------- Comment #7 from paul dot richard dot thomas at cea dot fr  2006-06-01 08:17 -------
This is still the case; Is this a gfortran issue or a gcc one?

If I give the characters length, using any format, even the anonymous warning
goes away.  In fact, any array expression that I have tried is the same; eg.

      real d(8), c(8) 
      d = c 

is ignored.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615

[Bug fortran/13615] -Wuninitialized produces wrong error message for characters

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
           Severity|enhancement                 |minor
  GCC build triplet|i686-pc-linux-gnu           |
   GCC host triplet|i686-pc-linux-gnu           |
 GCC target triplet|i686-pc-linux-gnu           |
   Last reconfirmed|2005-12-30 18:42:58         |2006-09-25 12:31:32
               date|                            |
            Summary|gfortran -Wuninitialized    |-Wuninitialized produces
                   |doesn't produce warning on  |wrong error message for
                   |characters                  |characters
            Version|3.3.2                       |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615

[Bug fortran/13615] -Wuninitialized produces wrong error message for characters

[fxcoudert at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]



------- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-11-21 18:58 -------
$ cat z.f
      subroutine warn_character(d)
      character c, d
      d = c
      end
$ gfortran -O2 -Wall z.f -c
z.f: In function ‘warn_character’:
z.f:3: warning: ‘c[1]{lb: 1 sz: 1}’ is used uninitialized in this function


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-09-29 08:14:43         |2007-11-21 18:58:59
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615

[Bug fortran/13615] -Wuninitialized produces wrong error message for characters

[manu at gcc dot gnu dot org]

------- Comment #9 from manu at gcc dot gnu dot org  2008-08-18 16:53 -------
To assess whether this is a middle-end issue, the alias dump (with VOPS and
linenumbers) would be relevant.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |24639
              nThis|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615

[Bug fortran/13615] -Wuninitialized produces wrong error message for characters

[dfranke at gcc dot gnu dot org]

------- Comment #10 from dfranke at gcc dot gnu dot org  2009-04-10 21:53 -------
> To assess whether this is a middle-end issue, the alias dump (with VOPS 
> and linenumbers) would be relevant.

The testcase in #8 still gives the same warning.
Manuel, you refer to the output of -fdump-tree-alias or another one?


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615

[Bug fortran/13615] -Wuninitialized produces wrong error message for characters

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |mikael at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> ---
gfortran outputs with the original testcase:

$ gfortran comment_0.f -O -Wall
comment_0.f: In function 'warn_integer':
comment_0.f:17:0: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
comment_0.f: In function 'warn_character':
comment_0.f:31:0: warning: 'c[1]{lb: 1 sz: 1}' is used uninitialized in this
function [-Wuninitialized]

-Wall is necessary to trigger the warning, but now 'c' is correctly diagnosed
as unitialized.  Closing as FIXED.

[Bug fortran/13615] -Wuninitialized produces wrong error message for characters

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615

--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #11)
> At revision 200321, I still get no warning for tests as in comment #7 and
> 
> pr13615_1.f90:3:0: warning: 'c[1]{lb: 1 sz: 1}' is used uninitialized in
> this function [-Wuninitialized]
> 
> as in comment #8. What dump(s) would be necessary for any progress for this
> PR?

The SSA built is:

warn_character (character(kind=1)D.24[1:1] & restrict dD.1877,
integer(kind=4)D.8 _dD.1876)
{
  character(kind=1)D.24 cD.1878[1:1];
  character(kind=1)D.24 _2;

;;   basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;    prev block 0, next block 1, flags: (NEW, REACHABLE)
;;    pred:       ENTRY (FALLTHRU)
;;   starting at line 3
  [z.f : 3:0] # VUSE <.MEM_1(D)>
  _2 = [z.f : 3] cD.1878[1]{lb: 1 sz: 1};
  [z.f : 3:0] # .MEM_4 = VDEF <.MEM_1(D)>
  [z.f : 3] [z.f : 3] *d_3(D)[1]{lb: 1 sz: 1} = _2;
  # .MEM_5 = VDEF <.MEM_4>
  cD.1878 ={v} {CLOBBER};
  [z.f : 4:0] # VUSE <.MEM_5>
  return;
;;    succ:       EXIT

}

as you can see, the middle-end somehow thinks that the function reads from
uninitialized memory. If this is the fault of gfortran or the middle-end, I
really don't know. Perhaps Richard or Jakub have better idea of what is going
on.
>From gcc-bugs-return-424831-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 22 15:10:39 2013
Return-Path: <gcc-bugs-return-424831-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14587 invoked by alias); 22 Jun 2013 15:10:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14530 invoked by uid 48); 22 Jun 2013 15:10:32 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
Date: Sat, 22 Jun 2013 15:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-57631-4-KMkA9i2JYD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57631-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57631-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01210.txt.bz2
Content-length: 1119

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to pebbles from comment #9)
> I would like to learn to find out if this is a bug and contribute a fix to
> the gcc sources.  At the moment building gcc loads my computer for a day,
> and it is difficult to develop on.  I plan to pursue this when I am set up
> better, but if anybody else ever cares about it they should look at it.

You can use the GCC Farm for gcc development for free.
http://gcc.gnu.org/wiki/CompileFarm

There are scripts that simplify building and testing patches. See
contrib/patch_test.sh and other scripts in that directory.

You can also use my own script
http://gcc.gnu.org/wiki/ManuelL%C3%B3pezIb%C3%A1%C3%B1ez?action=AttachFile&do=view&target=gccfarming
>From gcc-bugs-return-424832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 22 15:11:43 2013
Return-Path: <gcc-bugs-return-424832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15615 invoked by alias); 22 Jun 2013 15:11:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15571 invoked by uid 48); 22 Jun 2013 15:11:41 -0000
From: "ian at airs dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/57675] New: Complex division of NaN by zero not handled correctly
Date: Sat, 22 Jun 2013 15:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ian at airs dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-57675-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01211.txt.bz2
Content-length: 1209

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW675

            Bug ID: 57675
           Summary: Complex division of NaN by zero not handled correctly
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ian at airs dot com

The rules in C99 Annex G say that if either part of a complex number is
infinity, then the whole number is treated as infinity.  The rules imply but do
not clearly state that an operation involving a NaN should yield a NaN.
However, this program aborts:

__complex double f (__complex double, __complex double)
  __attribute__ ((noinline));
__complex double
f (__complex double a, __complex double b)
{
  return a / b;
}

int
main ()
{
  __complex double c = f (__builtin_nan("") + 1.0i, 0);
  if (__builtin_isinf (__real__ c) || __builtin_isinf (__imag__ c))
    abort ();
  exit (0);
}

Computing NaN+1.0i / 0+0i yields NaN+Inf*I.  The rules of Annex G say that the
latter is infinity.  But the result of dividing a NaN by 0 should be NaN, just
as the result of any operation involving NaN should be NaN.

[Bug fortran/13615] -Wuninitialized produces wrong error message for characters

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
At revision 200321, I still get no warning for tests as in comment #7 and

pr13615_1.f90:3:0: warning: 'c[1]{lb: 1 sz: 1}' is used uninitialized in this
function [-Wuninitialized]

as in comment #8. What dump(s) would be necessary for any progress for this PR?