[Bug preprocessor/57714] New: Newline rendered incorrectly in output

[Bug preprocessor/57714] New: Newline rendered incorrectly in output

[potswa at mac dot com]

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

            Bug ID: 57714
           Summary: Newline rendered incorrectly in output
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: potswa at mac dot com

main(){\
return 0;
}

preprocesses to

main(){return
       0;
}

The problem only appears in output from the -E option; observing the newline
within the program as with

#define main(){\
return 0;
}
main()

produces the correct result

}
{return 0;

This is a regression since 4.2.1; the GCC version included with Mac OS X does
not exhibit the problem.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is correct behavior for the continuing of the line.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[potswa at mac dot com]

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

--- Comment #2 from David Krauss <potswa at mac dot com> ---
Andrew, are you sure? The zero should remain on the same line as the "return"
token.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[potswa at mac dot com]

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

--- Comment #3 from David Krauss <potswa at mac dot com> ---
See section 9 of the manual:
http://gcc.gnu.org/onlinedocs/gcc-4.8.1/cpp/Preprocessor-Output.html#Preprocessor-Output

The output from the C preprocessor looks much like the input, except that all
preprocessing directive lines have been replaced with blank lines and all
comments with spaces. Long runs of blank lines are discarded.

...

CPP does not insert any whitespace where there was none in the original source,
except where necessary to prevent an accidental token paste.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[manu at gcc dot gnu.org]

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

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

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to David Krauss from comment #0)
> main(){\
> return 0;
> }
> 
> preprocesses to
> 
> main(){return
>        0;
> }

Actually, according to: http://gcc.gnu.org/wiki/FAQ#cpp_continuation_discarded

I am surprised the backslash is not simply discarded. It is discarded if you
add a space before the "return". It is a bug that it is NOT discarded,
>From gcc-bugs-return-425142-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 25 22:26:16 2013
Return-Path: <gcc-bugs-return-425142-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14963 invoked by alias); 25 Jun 2013 22:26:16 -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 14928 invoked by uid 48); 25 Jun 2013 22:26:10 -0000
From: "duncan_roe at acslink dot net.au" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57707] gcc misinterprets hex escapes in constant strings
Date: Tue, 25 Jun 2013 22:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.7.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: duncan_roe at acslink dot net.au
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_status resolution
Message-ID: <bug-57707-4-C9kkvXTesY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57707-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57707-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/msg01521.txt.bz2
Content-length: 678

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

duncan_roe at acslink dot net.au <duncan_roe at acslink dot net.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #5 from duncan_roe at acslink dot net.au <duncan_roe at acslink dot net.au> ---
There's no need for that. C is defined in Kernighan & Ritchie's "The C
Programming Language". They mandate \xhh as a character escape. No mention of
"except when the next character happens to be a hex digit".

[Bug preprocessor/57714] Newline rendered incorrectly in output

[potswa at mac dot com]

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

--- Comment #5 from David Krauss <potswa at mac dot com> ---
What? That makes even less sense. Are you guys familiar with the concept of
line splicing? See "phases of translation" in the Standard, namely phase 2.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[potswa at mac dot com]

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

--- Comment #6 from David Krauss <potswa at mac dot com> ---
Just to clarify the last comments, the input

main(){\
 return 0;
}

translates via cpp to

main(){
 return 0;
}

i.e. no splicing is apparent in the output.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[potswa at mac dot com]

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

--- Comment #7 from David Krauss <potswa at mac dot com> ---
Oh, OK, now I followed that link. Splicing is supposed to be transparent unless
you specify -P. This still qualifies as a bug.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[potswa at mac dot com]

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

--- Comment #8 from David Krauss <potswa at mac dot com> ---
Probably what happened:

1. In preserving visual appearance, tokens not separated by spaces are kept
together.
2. Line splicing happens before spaces are identified for the above.
3. The { and return tokens are grouped into the same visual block.
4. 0 follows a space and its location on the next line is duly noted.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
I think what happens is that the preprocessor is trying to avoid breaking up a
valid token like in:

void foo(void) {re\
turn;
}

It would be an improvement if it ignored the \ between valid tokens boundaries
even if there is no whitespace, but I think there is not going to be anyone
sufficiently bothered to fix this ever. So unless you want to give it a try,
let's leave this bug report closed.

I added a note to the FAQ.
>From gcc-bugs-return-425163-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 26 08:45:37 2013
Return-Path: <gcc-bugs-return-425163-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12194 invoked by alias); 26 Jun 2013 08:45:37 -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 12138 invoked by uid 48); 26 Jun 2013 08:45:27 -0000
From: "potswa at mac dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/57714] Newline rendered incorrectly in output
Date: Wed, 26 Jun 2013 08:45: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: potswa at mac dot com
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: <bug-57714-4-ttviTuJ1mB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57714-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57714-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/msg01542.txt.bz2
Content-length: 551

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

--- Comment #10 from David Krauss <potswa at mac dot com> ---
I don't plan on fixing this in GCC, but I did implement the feature today in my
own preprocessor, http://code.google.com/p/c-plus/source/list . It does require
a handshake between phases 2 and 3, because a token divided over two lines
needs to go into the earlier line, and then the extra newlines are flushed once
the token is complete. But a newline inside a whitespace "token" is not
postponed.

OK, on to bigger and better things :)

[Bug preprocessor/57714] Newline rendered incorrectly in output

[harald at gigawatt dot nl]

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

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #11 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Manuel López-Ibáñez from comment #9)
> It would be an improvement if it ignored the \ between valid tokens boundaries even if there is no whitespace,

Since the GCC documentation explicitly documents that no whitespace is inserted
except when necessary, as noted by David in comment #3, removing the backslash
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 also
include the documented extensions of GCC.

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?
>From gcc-bugs-return-425407-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 29 10:04:26 2013
Return-Path: <gcc-bugs-return-425407-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 30517 invoked by uid 48); 29 Jun 2013 10:04:23 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.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: <bug-57714-4-0Z6r907djn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57714-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57714-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/msg01786.txt.bz2
Content-length: 575

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

--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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 better
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: <gcc-bugs-return-425408-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 4095 invoked by uid 55); 29 Jun 2013 10:19:43 -0000
From: "zeccav at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
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: <bug-57749-4-ZhVKor107j@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57749-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57749-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/msg01787.txt.bz2
Content-length: 2100

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

--- Comment #4 from Vittorio Zecca <zeccav at gmail dot com> ---
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 <gcc-bugzilla@gcc.gnu.org>

> http://gcc.gnu.org/bugzilla/show_bug.cgi?idW749
>
> --- Comment #3 from Harald Anlauf <anlauf at gmx dot de> ---
> (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.
>

[Bug preprocessor/57714] Newline rendered incorrectly in output

[harald at gigawatt dot nl]

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

--- Comment #13 from Harald van Dijk <harald at gigawatt dot nl> ---
Sure. I have no strong preference on the matter, and have changed the wiki.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[potswa at mac dot com]

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

--- Comment #14 from David Krauss <potswa at mac dot com> ---
Harald's comment #10 is almost accurate, but for two things:

1. Actually the C standard does care whether whitespace is added. Whitespace is
visible in the result of stringizing, and when comparing duplicate macro
definitions.

2. Whitespace does not need to be added to cause the visual formatting of the
output to match the input. The trick is to output a backslash character in the
output. Of course this would disturb clients who don't expect backslashes in
their pretty-printed output. But pretty-printed output shouldn't be used for
automatic translation in the first place — that is what the -P option is for.

And to reconcile #2 with #1, the stringize operator and macro definition
comparison need to track splices in preserved whitespace, and treat whitespace
composed entirely of splices as nonexistent. That is exactly what I implemented
in my own preprocessor. See edits subsequent to the one linked above.

Such changes must be done internally even if you choose not to print
backslashes to the final output stream. If someone wants to fix this in GCC,
let this be a guide…
>From gcc-bugs-return-425417-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 29 12:56:35 2013
Return-Path: <gcc-bugs-return-425417-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11859 invoked by alias); 29 Jun 2013 12:56:35 -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 11820 invoked by uid 48); 29 Jun 2013 12:56:32 -0000
From: "anlauf at gmx dot de" <gcc-bugzilla@gcc.gnu.org>
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 12:56: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: anlauf at gmx dot de
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: <bug-57749-4-Nm1DgDfoOd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57749-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57749-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/msg01796.txt.bz2
Content-length: 1453

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

--- Comment #6 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Harald Anlauf from comment #5)
> (In reply to Vittorio Zecca from comment #4)
> > Also I do not understand the different behaviour with different levels of
> > optimization,
>
> I think that compile-time optimization realizes that the exponent y
> is actually exactly a positive integer and does some simplification.
> At -O0, you get an evaluation by the run-time library.

Looking at the dump tree, one find that the following is generated:

      D.1825 = __builtin_cpowf (D.1824, __complex__ (1.0e+0, 0.0));

Without optimization, this is converted into a call to cpowf.

A straigtforward C example shows that the exception is generated
within libm:

#define _GNU_SOURCE
#include <complex.h>
#include <fenv.h>
#include <stdio.h>

main()
{
  complex x, y, z;
  x = 0.;
  y = 1.;
  feenableexcept (FE_DIVBYZERO | FE_OVERFLOW | FE_INVALID);
  z = cpowf (x, y);
  printf("z = %f + %f * i\n", creal(z), cimag(z));
}

(gdb) run
Starting program: /home/anlauf/a.out

Program received signal SIGFPE, Arithmetic exception.
0xb7f98ea3 in clogf () from /lib/libm.so.6
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.14.1-14.27.1.i686
(gdb) where
#0  0xb7f98ea3 in clogf () from /lib/libm.so.6
#1  0xb7f9a4d4 in cpowf () from /lib/libm.so.6
#2  0x080485a2 in main () at check-cpow.c:12

That's with glibc-2.14.1.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[potswa at mac dot com]

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

--- Comment #15 from David Krauss <potswa at mac dot com> ---
Corrections to previous: Harald's comment is #11, and I meant to refer to the
commits in my repo from
http://code.google.com/p/c-plus/source/detail?r=d462b650c355b606545158f4da7365180b699752
up through
http://code.google.com/p/c-plus/source/detail?r=2849f0f6d0677ed2679e39aad2c85e87f9b7ebd4
.

[Bug preprocessor/57714] Newline rendered incorrectly in output

[potswa at mac dot com]

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

--- Comment #17 from David Krauss <potswa at mac dot com> ---
Yes, my preprocessor classifies the backslash-after-preprocessing as a
whitespace token. I simply don't intend to make textual preprocessing output.
With raw strings, UCNs, and user-defined literals, there's just no way a user
would handle it all properly. GCC avoids inserting whitespace except where
"necessary," where a token boundary would be invisible, but tokenizing has
gotten harder than it was. My preprocessor doesn't bother with any artificial
whitespace.

Pretty mode is for user display only, and robust processing needs out-of-band
non-text data.