From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30516 invoked by alias); 23 Aug 2013 22:15:34 -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 30481 invoked by uid 48); 23 Aug 2013 22:15:32 -0000 From: "bohan.gnu at retropaganda dot info" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers Date: Fri, 23 Aug 2013 22:15: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.2.4 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bohan.gnu at retropaganda dot info 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: bug_status resolution 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-08/txt/msg01232.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D39029 Johan Boul=C3=A9 changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Johan Boul=C3=A9 -= -- I highly suspect it was caused by having two copies of the same header file= s: - one in the source tree, - the other in a staged-install include dir. The PCH would have been built with the one in the source tree. And later, when trying to use the PCH, some -I flag was pointing to the staged-install include dir, not the original source tree. GCC would then see these are different headers than the one in the PCH, whi= ch is technically correct. No bug in GCC here. It's a build-system bug. >>From gcc-bugs-return-428309-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 23 22:23:48 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 5127 invoked by alias); 23 Aug 2013 22:23: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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 5106 invoked by uid 48); 23 Aug 2013 22:23:47 -0000 From: "baker at usgs dot gov" To: gcc-bugs@gcc.gnu.org Subject: [Bug inline-asm/58234] New: In-line asm version of __FD_ZERO in /usr/include/bits/select.h Date: Fri, 23 Aug 2013 22:23:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: inline-asm X-Bugzilla-Version: 4.4.7 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: baker at usgs dot gov 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-08/txt/msg01233.txt.bz2 Content-length: 7901 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D58234 Bug ID: 58234 Summary: In-line asm version of __FD_ZERO in /usr/include/bits/select.h Product: gcc Version: 4.4.7 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: baker at usgs dot gov I encountered a run-time error using the -check=3Duninit Intel icc compiler option on Linux: Run-Time Check Failure: The variable '__d1' is being used without being initialized I tracked the problem to the FD_ZERO macro, which is ultimately expanded us= ing the __FD_ZERO macro in /usr/include/bits/select.h. A very simple program w= ill trigger the run-time failure: #include int main( void ) { fd_set rfds; FD_ZERO( &rfds ); return 0; } Compiled with: # icc -check=3Duninit intel.c The fix is to disable the in-line asm code for __FD_ZERO; -no-gcc will suff= ice: # icc -no-gcc -check=3Duninit intel.c That is fine for this case. But the code I am working with needs other GNUC header options that also get disabled when -no-gcc is used. If I add -no-g= cc, I get lots of compilation errors. I realize this is not technically a GCC library/headers error. I think the Intel icc compiler does not properly account for in-line asm side-effects in its uninitialized variable tracking. However, I decided to see if I could make the __FD_ZERO macro asm work. I = was able to rearrange the in-line asm for a workaround in this case. I think t= his is an improvement, and also cures a subtle flaw in the original that (lucki= ly) makes absolutely no difference. The original __FD_ZERO macro definition (in /usr/include/bits/select.h) is: # define __FD_ZERO(fdsp) \ do { \ int __d0, __d1; \ __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS \ : "=3Dc" (__d0), "=3DD" (__d1) \ : "a" (0), "0" (sizeof (fd_set) \ / sizeof (__fd_mask)), \ "1" (&__FDS_BITS (fdsp)[0]) \ : "memory"); \ } while (0) I cannot tell exactly where in the expansion the Intel run-time error occur= s -- gdb shows ?? for the backtrace beyond the Intel __intel_rtc_uninit_use() service routine (compiled with -g): (gdb) bt #0 0x00130430 in __kernel_vsyscall () #1 0x001a3b11 in raise () from /lib/libc.so.6 #2 0x001a53ea in abort () from /lib/libc.so.6 #3 0x080489e1 in __intel_rtc_uninit_use () #4 0x00000001 in ?? () #5 0x00000000 in ?? () The assembly language generated by gcc -O0 (-m32 or -m64) always includes a store into __d0 and __d1 after the execution of the stosl/stosq instruction= .=20 Maybe it is that store which is tripping up the Intel code. I rewrote the asm to remove __d0 and __d1, since they go out-of-scope anyway after the asm executes: # define __FD_ZERO(fdsp) \ do { = \ __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS = \ : = \ : "a" (0), = \ "c" (sizeof (fd_set) / sizeof (__fd_mask)), = \ "D" (&__FDS_BITS (fdsp)[0]) = \ : "memory"); = \ } while (0) This generated slightly different code, which I believe is correct. Here is the original assembly output for gcc -m32 and gcc -m64: Original __FD_ZERO, gcc -m32 .file "junk.c" .text .globl main .type main, @function main: pushl %ebp movl %esp, %ebp pushl %edi subl $144, %esp movl $0, %eax movl $32, %ecx leal -140(%ebp), %edx movl %edx, %edi #APP # 45 "junk.c" 1 cld; rep; stosl # 0 "" 2 #NO_APP movl %edi, %edx movl %ecx, -12(%ebp) movl %edx, -8(%ebp) movl $0, %eax addl $144, %esp popl %edi popl %ebp ret .size main, .-main .ident "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-3)" .section .note.GNU-stack,"",@progbits Original __FD_ZERO, gcc -m64 .file "junk.c" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 pushq %rbx subq $32, %rsp movl $0, %eax movl $16, %edx leaq -160(%rbp), %rbx .cfi_offset 3, -24 movq %rdx, %rcx movq %rbx, %rdi #APP # 45 "junk.c" 1 cld; rep; stosq # 0 "" 2 #NO_APP movl %edi, %eax movl %ecx, %edx movl %edx, -24(%rbp) movl %eax, -20(%rbp) movl $0, %eax addq $32, %rsp popq %rbx leave .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-3)" .section .note.GNU-stack,"",@progbits (The subtle flaw I see is due to the use of int __d1 for an address on an x86_64 machine. The completely useless and benign store into __d1 is alway= s a movl, even on an x86_64 machine. That is not technically correct. __d1 sh= ould really be declared void * __d1.) Here is the assembly output for gcc -m32 and gcc -m64 using the replacement __FD_ZERO asm: Replacement __FD_ZERO, gcc -m32 .file "junk.c" .text .globl main .type main, @function main: pushl %ebp movl %esp, %ebp pushl %edi pushl %ebx addl $-128, %esp movl $0, %eax movl $32, %edx leal -136(%ebp), %ebx movl %edx, %ecx movl %ebx, %edi #APP # 45 "junk.c" 1 cld; rep; stosl # 0 "" 2 #NO_APP movl $0, %eax subl $-128, %esp popl %ebx popl %edi popl %ebp ret .size main, .-main .ident "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-3)" .section .note.GNU-stack,"",@progbits Replacement __FD_ZERO, gcc -m64 .file "junk.c" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 pushq %rbx subq $16, %rsp movl $0, %eax movl $16, %edx leaq -144(%rbp), %rbx .cfi_offset 3, -24 movq %rdx, %rcx movq %rbx, %rdi #APP # 45 "junk.c" 1 cld; rep; stosq # 0 "" 2 #NO_APP movl $0, %eax addq $16, %rsp popq %rbx leave .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-3)" .section .note.GNU-stack,"",@progbits The code is a little tighter: there is no allocation for __d0 and __d1 on t= he stack, and the stores to __d0 and __d1 are of course also gone, since they = no longer exist. What I do not know is how to tell the compiler that the instruction clobbers %ecx and %edi as side-effects. I do not even know if that is necessary. I tried adding them to the clobber list, but then the asm would not compile (can't find a register in class =E2=80=98CREG=E2=80=99 while reloading =E2= =80=98asm=E2=80=99). Someone more knowledgeable than I will have to say whether there are any lo= ose ends that need to be cleaned up. I apologize if this is the wrong list to post this, and for being so long-winded. I tried to be accurate and complete. Please steer me elsewhe= re, if this post is inappropriate. Thank you, Larry Baker US Geological Survey >>From gcc-bugs-return-428310-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 23 22:31:39 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 10497 invoked by alias); 23 Aug 2013 22:31:39 -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 10477 invoked by uid 48); 23 Aug 2013 22:31:38 -0000 From: "pinskia at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h Date: Fri, 23 Aug 2013 22:31: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.4.7 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia 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: bug_status resolution 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-08/txt/msg01234.txt.bz2 Content-length: 842 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 Andrew Pinski changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- First FD_ZERO comes from glibc so this is not a GCC bug. Second this question should go to ICC rather than GCC since it is their compiler which is causing the complaint in the end rather than GCC. And third the inline-asm is correct to begin with as both rcx and rdi are changed by "rep;stosl/stosq" so having an output constraints is correct; otherwise the compiler could decide to reuse those values that were in them.