From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3572 invoked by alias); 22 Jun 2013 14:43:42 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 3489 invoked by uid 48); 22 Jun 2013 14:43:39 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/13615] -Wuninitialized produces wrong error message for characters Date: Sat, 22 Jun 2013 14:43:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.2.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: minor X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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/msg01209.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D13615 --- Comment #12 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Dominique d'Humieres from comment #11) > At revision 200321, I still get no warning for tests as in comment #7 and >=20 > pr13615_1.f90:3:0: warning: 'c[1]{lb: 1 sz: 1}' is used uninitialized in > this function [-Wuninitialized] >=20 > as in comment #8. What dump(s) would be necessary for any progress for th= is > PR? The SSA built is: warn_character (character(kind=3D1)D.24[1:1] & restrict dD.1877, integer(kind=3D4)D.8 _dD.1876) { character(kind=3D1)D.24 cD.1878[1:1]; character(kind=3D1)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 =3D [z.f : 3] cD.1878[1]{lb: 1 sz: 1}; [z.f : 3:0] # .MEM_4 =3D VDEF <.MEM_1(D)> [z.f : 3] [z.f : 3] *d_3(D)[1]{lb: 1 sz: 1} =3D _2; # .MEM_5 =3D VDEF <.MEM_4> cD.1878 =3D{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 goi= ng on. >>From gcc-bugs-return-424831-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 22 15:10:39 2013 Return-Path: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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=3D57631 Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manu at gcc dot gnu.org --- Comment #11 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (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=3DAttachFil= e&do=3Dview&target=3Dgccfarming >>From gcc-bugs-return-424832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 22 15:11:43 2013 Return-Path: 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: List-Archive: List-Post: List-Help: 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" 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: 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?id=57675 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.