From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14052 invoked by alias); 22 Jul 2013 20:24:48 -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 9077 invoked by uid 48); 22 Jul 2013 20:22:44 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements Date: Mon, 22 Jul 2013 20:24:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: inline-asm X-Bugzilla-Version: 4.7.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-07/txt/msg01042.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57950 --- Comment #10 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Andreas Schwab from comment #9) > The assembler only sees literal newlines, it does not know how they were > written in the source. Is there other way to generate literal newlines apart from printing a liter= al newline? And why it matters how they were written in the source code? The p= oint is that GCC should see that it is a literal newline and hint GAS that it was actually in the same line (or not) in the original source code. GAS does not need to know anything. > The compiler cannot put line directives in the middle of an assembler str= ing > by itself because it cannot know how the assembler will interpret the text > around the newline. This will surely break things. If there are restrictions on the lines where the location directives can ap= pear in an assembler file, then it is a problem, yes. I wasn't aware of such restrictions, I was assuming that they were basically like preprocessor directives. Oh, well, another reason why an integrated assembler is such a good idea... >>From gcc-bugs-return-426536-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 22 20:46:38 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 922 invoked by alias); 22 Jul 2013 20:46: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 29596 invoked by uid 48); 22 Jul 2013 20:44:36 -0000 From: "wschmidt at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions Date: Mon, 22 Jul 2013 20:46: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: ABI, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: wschmidt at gcc dot gnu.org 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-07/txt/msg01043.txt.bz2 Content-length: 1166 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949 --- Comment #3 from Bill Schmidt --- The problem is target-specific, in config/rs6000/rs6000.c: rs6000_function_arg_boundary(). static unsigned int rs6000_function_arg_boundary (enum machine_mode mode, const_tree type) { if (DEFAULT_ABI == ABI_V4 && (GET_MODE_SIZE (mode) == 8 || (TARGET_HARD_FLOAT && TARGET_FPRS && (mode == TFmode || mode == TDmode)))) return 64; else if (SPE_VECTOR_MODE (mode) || (type && TREE_CODE (type) == VECTOR_TYPE && int_size_in_bytes (type) >= 8 && int_size_in_bytes (type) < 16)) return 64; else if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || (type && TREE_CODE (type) == VECTOR_TYPE && int_size_in_bytes (type) >= 16)) return 128; else if (TARGET_MACHO && rs6000_darwin64_abi && mode == BLKmode && type && TYPE_ALIGN (type) > 64) return 128; else return PARM_BOUNDARY; } Note that the TARGET_MACHO + Darwin ABI case does what the 64-bit PowerPC ELF ABI implies should be done. It's not clear to me why that ABI is excluded.