public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers
[not found] <bug-39029-4@http.gcc.gnu.org/bugzilla/>
@ 2011-02-20 15:19 ` olafvdspek at gmail dot com
2011-02-20 21:59 ` manu at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: olafvdspek at gmail dot com @ 2011-02-20 15:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
Olaf van der Spek <olafvdspek at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |olafvdspek at gmail dot com
--- Comment #1 from Olaf van der Spek <olafvdspek at gmail dot com> 2011-02-20 15:15:08 UTC ---
Could you attach a minimal testcase?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers
[not found] <bug-39029-4@http.gcc.gnu.org/bugzilla/>
2011-02-20 15:19 ` [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers olafvdspek at gmail dot com
@ 2011-02-20 21:59 ` manu at gcc dot gnu.org
2011-02-21 9:44 ` olafvdspek at gmail dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: manu at gcc dot gnu.org @ 2011-02-20 21:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2011.02.20 21:10:59
CC| |manu at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-02-20 21:10:59 UTC ---
We need more information. Please follow the instructions here:
http://gcc.gnu.org/bugs/#report
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers
[not found] <bug-39029-4@http.gcc.gnu.org/bugzilla/>
2011-02-20 15:19 ` [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers olafvdspek at gmail dot com
2011-02-20 21:59 ` manu at gcc dot gnu.org
@ 2011-02-21 9:44 ` olafvdspek at gmail dot com
2011-12-15 2:13 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: olafvdspek at gmail dot com @ 2011-02-21 9:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
--- Comment #3 from Olaf van der Spek <olafvdspek at gmail dot com> 2011-02-21 09:37:03 UTC ---
g++ -o b.h.gch a.h
g++ c.cpp
a.h:
#pragma once // a.h:1:9: warning: #pragma once in main file
c.cpp:
#include "b.h"
#include "b.h" // c.cpp:2:15: error: b.h: No such file or directory
int main()
{
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers
[not found] <bug-39029-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2011-02-21 9:44 ` olafvdspek at gmail dot com
@ 2011-12-15 2:13 ` pinskia at gcc dot gnu.org
2012-04-28 14:15 ` bohan.gnu at retropaganda dot info
2013-08-23 22:15 ` bohan.gnu at retropaganda dot info
5 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2011-12-15 2:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-12-15 02:11:02 UTC ---
*** Bug 47857 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers
[not found] <bug-39029-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2011-12-15 2:13 ` pinskia at gcc dot gnu.org
@ 2012-04-28 14:15 ` bohan.gnu at retropaganda dot info
2013-08-23 22:15 ` bohan.gnu at retropaganda dot info
5 siblings, 0 replies; 6+ messages in thread
From: bohan.gnu at retropaganda dot info @ 2012-04-28 14:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
--- Comment #5 from Johan Boulé <bohan.gnu at retropaganda dot info> 2012-04-28 14:15:17 UTC ---
I believe my original bug report does not stand as a valid bug. Bug #47857 has
been marked as duplicate but is not: it's a spurious warning. Also, Olaf showed
a test case that seems problematic but is probably worth a separate bug report.
Following is a minimal test case for what I originally thought was a bug, but
might actually not be considered a bug:
==============
includes/a.hpp
==============
#pragma once
class a { a(); };
=========
src/a.cpp
=========
#include <a.hpp>
a::a() {}
int main() {}
========
Makefile
========
bin/a.out: src/a.cpp pch/a.hpp.gch
mkdir -p bin
# fails:
g++ -include pch/a.hpp src/a.cpp -o bin/a.out
# fails:
g++ -include pch/a.hpp src/a.cpp -o bin/a.out -I pch
# succeeds:
g++ -include pch/a.hpp src/a.cpp -o bin/a.out -I includes
pch/a.hpp.gch: includes/a.hpp
mkdir -p pch
g++ -I includes -xc++-header includes/a.hpp -o pch/a.hpp.gch
clean:
rm -Rf pch bin
=======
make -i
=======
mkdir -p pch
g++ -I includes -xc++-header includes/a.hpp -o pch/a.hpp.gch
includes/a.hpp:1:9: warning: #pragma once in main file
mkdir -p bin
# fails:
g++ -include pch/a.hpp src/a.cpp -o bin/a.out
src/a.cpp:1:17: error: a.hpp: No such file or directory
make: [bin/a.out] Error 1 (ignored)
# fails:
g++ -include pch/a.hpp src/a.cpp -o bin/a.out -I pch
src/a.cpp:1:17: error: a.hpp: No such file or directory
make: [bin/a.out] Error 1 (ignored)
# succeeds:
g++ -include pch/a.hpp src/a.cpp -o bin/a.out -I includes
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers
[not found] <bug-39029-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2012-04-28 14:15 ` bohan.gnu at retropaganda dot info
@ 2013-08-23 22:15 ` bohan.gnu at retropaganda dot info
5 siblings, 0 replies; 6+ messages in thread
From: bohan.gnu at retropaganda dot info @ 2013-08-23 22:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
Johan Boulé <bohan.gnu at retropaganda dot info> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Johan Boulé <bohan.gnu at retropaganda dot info> ---
I highly suspect it was caused by having two copies of the same header files:
- 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, which
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: <gcc-bugs-return-428309-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 5106 invoked by uid 48); 23 Aug 2013 22:23:47 -0000
From: "baker at usgs dot gov" <gcc-bugzilla@gcc.gnu.org>
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: <bug-58234-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-08/txt/msg01233.txt.bz2
Content-length: 7901
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234
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=uninit 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 using
the __FD_ZERO macro in /usr/include/bits/select.h. A very simple program will
trigger the run-time failure:
#include <sys/select.h>
int main( void ) {
fd_set rfds;
FD_ZERO( &rfds );
return 0;
}
Compiled with:
# icc -check=uninit intel.c
The fix is to disable the in-line asm code for __FD_ZERO; -no-gcc will suffice:
# icc -no-gcc -check=uninit 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-gcc,
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 this
is an improvement, and also cures a subtle flaw in the original that (luckily)
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 \
: "=c" (__d0), "=D" (__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 occurs --
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.
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 always a
movl, even on an x86_64 machine. That is not technically correct. __d1 should
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 the
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 ‘CREG’ while reloading ‘asm’).
Someone more knowledgeable than I will have to say whether there are any loose
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 elsewhere,
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: <gcc-bugs-return-428310-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 10477 invoked by uid 48); 23 Aug 2013 22:31:38 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.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: <bug-58234-4-88iynAIY4l@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58234-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58234-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-08/txt/msg01234.txt.bz2
Content-length: 842
http://gcc.gnu.org/bugzilla/show_bug.cgi?idX234
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> ---
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-08-23 22:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-39029-4@http.gcc.gnu.org/bugzilla/>
2011-02-20 15:19 ` [Bug preprocessor/39029] #pragma once is not "exported" from the precompiled headers olafvdspek at gmail dot com
2011-02-20 21:59 ` manu at gcc dot gnu.org
2011-02-21 9:44 ` olafvdspek at gmail dot com
2011-12-15 2:13 ` pinskia at gcc dot gnu.org
2012-04-28 14:15 ` bohan.gnu at retropaganda dot info
2013-08-23 22:15 ` bohan.gnu at retropaganda dot info
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).