From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16545 invoked by alias); 29 Jun 2013 09:18:56 -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 16509 invoked by uid 48); 29 Jun 2013 09:18:53 -0000 From: "harald at gigawatt dot nl" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/57714] Newline rendered incorrectly in output Date: Sat, 29 Jun 2013 09:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: harald at gigawatt dot nl X-Bugzilla-Status: RESOLVED 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: 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/msg01785.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57714 Harald van Dijk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |harald at gigawatt dot nl --- Comment #11 from Harald van Dijk --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #9) > It would be an improvement if it ignored the \ between valid tokens bound= aries even if there is no whitespace, Since the GCC documentation explicitly documents that no whitespace is inse= rted except when necessary, as noted by David in comment #3, removing the backsl= ash in your example, int foo(){\ return 0;} would be invalid, as there was no whitespace between { and return in the original code, and there would be after removing the backslash. It would be valid as far as the C and C++ standards are concerned, but invalid if you a= lso include the documented extensions of GCC. Could you either not suggest that the current behaviour is a bug (even if i= t is a minor one) in the FAQ, or change the documentation so that it is unspecif= ied what that code preprocesses to? >>From gcc-bugs-return-425407-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 29 10:04:26 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 30542 invoked by alias); 29 Jun 2013 10:04:26 -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 30517 invoked by uid 48); 29 Jun 2013 10:04:23 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/57714] Newline rendered incorrectly in output Date: Sat, 29 Jun 2013 10:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: RESOLVED 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: 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/msg01786.txt.bz2 Content-length: 575 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57714 --- Comment #12 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Harald van Dijk from comment #11) > Could you either not suggest that the current behaviour is a bug (even if= it > is a minor one) in the FAQ, or change the documentation so that it is > unspecified what that code preprocesses to? Good observation. Feel free to edit the wiki to match the documentation. Changing the documentation is less trivial, but if you think that is a bett= er option, you could submit a patch. >>From gcc-bugs-return-425408-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 29 10:19:46 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 4125 invoked by alias); 29 Jun 2013 10:19:46 -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 4095 invoked by uid 55); 29 Jun 2013 10:19:43 -0000 From: "zeccav at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0 Date: Sat, 29 Jun 2013 10:19: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.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: zeccav at gmail 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: Message-ID: In-Reply-To: References: 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/msg01787.txt.bz2 Content-length: 2100 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #4 from Vittorio Zecca --- I am happy to refresh my complex analysis study of long ago. The singularity of log(x) in zero is not essential. Essential singularity means the Laurent seriesis infinite in both directions? z**-k and z**+k roughly, but log(z) Laurent series is infinite only for z**+k. I hope to remember correctly. But exp(y*log(x)) may well be essential, however. Anyway I am not sure this is an essential (forgive the pun) reason to raise an exception Also I do not understand the different behaviour with different levels of optimization, and I confirm the a.out executable runs fine under valgrind. And the code runs fine with Intel ifort. And I really do not see how complex zero raised to a positive power should raise an exception. 2013/6/29 anlauf at gmx dot de > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 > > --- Comment #3 from Harald Anlauf --- > (In reply to Vittorio Zecca from comment #2) > > I believe -O0 is the default optimization level, so it is important. > > > > Of course the code I sent you is a fragment from a much larger program, > > kind of c**x with c complex and x real. It is not possible to make x > > into an integer. > > > > When x is zero and y is real, x**y is singular for y<=0, right? > > I think you are missing the intricacies of complex arithmetics. > > x**y = exp (y * log(x)) has an *essential singularity* at x=0, > which is the starting point of a branch cut (usually the negative > real axis). See also cpow(3). > > The man page for pow(3) covers only real arithmetics and does not apply. > > > Also, I do not understand why I get SIGFPE on either zero or invalid > > -ffpe-trap suboption, > > but this is a lesser issue. > > A quick search did not turn up any result whether IEEE specifies > a defined behavior for your case. Maybe you are more successful. > I also could not find anything in the Fortran standard. > > -- > You are receiving this mail because: > You reported the bug. >