[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression

["ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644

Uroš Bizjak <ubizjak at gmail dot com> changed:

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

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
Not a GCC bug then.
>From gcc-bugs-return-482507-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 01 14:21:31 2015
Return-Path: <gcc-bugs-return-482507-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 125294 invoked by alias); 1 Apr 2015 14:21:30 -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 124271 invoked by uid 48); 1 Apr 2015 14:21:19 -0000
From: "drivshin at allworx dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/61977] [4.8/4.9/5 Regression] powerpc preprocessor breaks on lines that end with "vector"
Date: Wed, 01 Apr 2015 14:21: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.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: drivshin at allworx dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61977-4-WgVqZdGufJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61977-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61977-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: 2015-04/txt/msg00059.txt.bz2
Content-length: 1132

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida977

--- Comment #9 from David Rivshin <drivshin at allworx dot com> ---
I think the extra newline is the result of maybe_print_line() being invoked
when trying to peek past a newline in the input.

#0  maybe_print_line_1 (src_loc\x134, stream=0x361e3b8800 <_IO_2_1_stdout_>) at
c-ppoutput.c:352
#1  maybe_print_line (src_loc\x134) at c-ppoutput.c:385
#2  do_line_change (pfile=0x1ef2910, token=0x1f1dd68, src_loc\x134,
parsing_args=0) at c-ppoutput.c:463
#3  cb_line_change (pfile=0x1ef2910, token=0x1f1dd68, parsing_args=0) at
c-ppoutput.c:490
#4  _cpp_lex_token (pfile=0x1ef2910) at lex.c:2192
#5  cpp_peek_token (pfile=0x1ef2910, index=0) at lex.c:2085
#6  cpp_get_token_1 (pfile=0x1ef2910, location=0x7fffffffd8fc) at macro.c:2501

If I'm understanding the logic correctly, when _cpp_lex_direct() sees the
newline, the processing of the line is considered complete, and therefore that
line of output complete. But because of the conditional macro that's not
entirely true, and the output only has the line up to (but not including) the
conditional macro token itself at that point.