[Bug c/57653] filename information discarded when using -imacros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #22 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Jul 24 09:00:13 2014 New Revision: 212972 URL: https://gcc.gnu.org/viewcvs?rev=212972root=gccview=rev Log: PR c/57653 * c-opts.c (c_finish_options): If -imacros is in effect, return. * c-c++-common/pr57653.c: New test. * c-c++-common/pr57653.h: New file. * c-c++-common/pr57653-2.c: New test. * c-c++-common/pr57653-2.h: New file. Added: trunk/gcc/testsuite/c-c++-common/pr57653-2.c trunk/gcc/testsuite/c-c++-common/pr57653-2.h trunk/gcc/testsuite/c-c++-common/pr57653.c trunk/gcc/testsuite/c-c++-common/pr57653.h Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/testsuite/ChangeLog
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Allan McRae from comment #19) That patch works. With -imacros foo.h: LC_ENTER foo.c LC_RENAME command-line LC_ENTER foo.h LC_LEAVE 0x0 LC_ENTER /usr/include/stdc-predef.h LC_LEAVE 0x0 LC_RENAME foo.c - correct output LC_LEAVE 0x0 All other combinations of -include/-imacros/-ffreestanding/no foo.h all are unchanged as expected. Great! I am certainly too busy at the moment to go through all the steps of the contribution process for this. The patch needs to be fully bootstrapped with the latest trunk, an appropriate testcase needs to be created, plus run the full regression testsuite and compare the results with the regression results of the unpatched trunk and check that no new failures appear. Then, it has to be submitted to gcc-patches with a GNU Changelog. If you are really interested in fixing this, you should just take the lead. Feel free to modify the patch as you need. The patch is anyway too small to require any kind of legal assignment, but if they ask for it, you can always say I wrote it. I have an assignment in place with the FSF. When submitting to gcc-patches, CC js...@gcc.gnu.org. You can also see in the svn log or svn blame who wrote the -imacro code and CC him/her as well. (You can also CC me).
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Once you are in trunk, you can ask the release managers to backport it to the GCC 4.8 branch.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Allan McRae from comment #15)
I tried with -include foo.h and a breakpoint in push_command_line_include...
I just stepped through from that breakpoint and saw cpp_push_default_include
being called for both stdc-predef.h and foo.h. That also gives the correct
output.
# gcc-4.9 -include foo.h foo.c
foo.c: In function ‘main’:
foo.c:1:21: error: expected expression before ‘}’ token
int main() { return }
What is the trace of LC_ messages produced here? It seems the -imacros code is
missing something. Actually, if you could attach the corresponding gdb session
like you did earlier, it would be helpful to compare both.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #17 from Allan McRae allan at archlinux dot org --- Created attachment 30359 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30359action=edit gdb log when using -include When using -include instead of -imacros, the trail is: LC_ENTER foo.c LC_RENAME command-line LC_ENTER /usr/include/stdc-predef.h LC_LEAVE 0x0 LC_ENTER foo.h LC_LEAVE 0x0 LC_RENAME foo.c LC_LEAVE 0x0 gdb log with -include attached.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #18 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
Thanks!
I think I know the reason why it is failing, but I am not sure about the proper
fix.
For some reason unknown to me, push_commandline_include should not be called
while processing -imacros. -imacros tries to achieve this but playing tricks
with include_cursor, but that doesn't stop the pre-included files. Calling
cpp_push_include (or cpp_push_default_include) seems to mess up everything
(again, no idea why!). This code is really a mess but the simple patch below
seems to work. Could you test it?
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c (revision 200330)
+++ gcc/c-family/c-opts.c (working copy)
@@ -1338,10 +1338,14 @@ c_finish_options (void)
/* Give CPP the next file given by -include, if any. */
static void
push_command_line_include (void)
{
+ // This can happen if disabled by -imacros for example.
+ if (include_cursor deferred_count)
+return;
+
if (!done_preinclude)
{
done_preinclude = true;
if (flag_hosted std_inc !cpp_opts-preprocessed)
{
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #19 from Allan McRae allan at archlinux dot org --- That patch works. With -imacros foo.h: LC_ENTER foo.c LC_RENAME command-line LC_ENTER foo.h LC_LEAVE 0x0 LC_ENTER /usr/include/stdc-predef.h LC_LEAVE 0x0 LC_RENAME foo.c - correct output LC_LEAVE 0x0 All other combinations of -include/-imacros/-ffreestanding/no foo.h all are unchanged as expected.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Allan McRae from comment #13) The file /usr/include/stdc-predef.h is from glibc (v2.17 on Arch) and is specifically mentioned as being preincluded in http://gcc.gnu.org/gcc-4.8/porting_to.html. In fact, using -ffreestanding solves the issue. So when you use -ffreestanding, is stdc-predef.h still included? You could put a break in push_command_line_include and check if -include foo.h still includes stdc-predef.h and whether it shows also the problem. If the file is included but there is no bug, then my guess is that the code executed before or after the pre-include stdc-predef.h is missing something for the -imacros case. If it shows the bug, then the code for pre-including stuff must be wrong somehow, perhaps cpp_push_default_include is doing something wrong when compared to cpp_push_include.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #15 from Allan McRae allan at archlinux dot org ---
with -ffreestanding
LC_ENTER foo.c
LC_RENAME command-line
LC_ENTER foo.h
LC_LEAVE 0x0
LC_RENAME foo.c
- correct output printed here
LC_LEAVE 0x0
so std-predef.h is not included.
I tried with -include foo.h and a breakpoint in push_command_line_include... I
just stepped through from that breakpoint and saw cpp_push_default_include
being called for both stdc-predef.h and foo.h. That also gives the correct
output.
# gcc-4.9 -include foo.h foo.c
foo.c: In function ‘main’:
foo.c:1:21: error: expected expression before ‘}’ token
int main() { return }
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #8 from Allan McRae allan at archlinux dot org --- I really have no idea what I am looking for... but adding a breakpoint at linemap_add I see (reason, file): LC_ENTER foo.c LC_RENAME command-line LC_ENTER /usr/include/stdc-predef.h LC_LEAVE 0x0 LC_RENAME foo.c - correct output printed here LC_LEAVE 0x0 LC_ENTER foo.c LC_RENAME command-line LC_ENTER foo.h LC_LEAVE 0x0 LC_ENTER /usr/include/stdc-predef.h LC_RENAME foo.c LC_LEAVE 0x0 - incorrect output printed here LC_LEAVE 0x0 So it looks like it is not leaving /usr/include/stdc-predef.h at the right time so the wrong thing is being renamed?
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-23
Ever confirmed|0 |1
--- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Allan McRae from comment #8)
I really have no idea what I am looking for... but adding a breakpoint at
linemap_add I see (reason, file):
LC_ENTER foo.c
LC_RENAME command-line
LC_ENTER /usr/include/stdc-predef.h
LC_LEAVE 0x0
LC_RENAME foo.c
- correct output printed here
LC_LEAVE 0x0
LC_ENTER foo.c
LC_RENAME command-line
LC_ENTER foo.h
LC_LEAVE 0x0
LC_ENTER /usr/include/stdc-predef.h
LC_RENAME foo.c
LC_LEAVE 0x0
- incorrect output printed here
LC_LEAVE 0x0
So it looks like it is not leaving /usr/include/stdc-predef.h at the right
time so the wrong thing is being renamed?
It seems a probable cause for this bug. Can you track where the return paths
differ?
Does
LC_ENTER /usr/include/stdc-predef.h
happen through the same functions in both cases?
and the LC_LEAVE 0x0 just afterwards?
Perhaps there is a missing LC_LEAVE or perhaps the order between
LC_RENAME foo.c
LC_LEAVE 0x0
should be reversed.
Strangely, I still cannot reproduce this:
manuel@gcc10:~$ ~/test1/200330/install/bin/gcc -imacros foo.h foo.c
foo.c: In function ‘main’:
foo.c:1:21: error: expected expression before ‘}’ token
int main() { return }
^
manuel@gcc10:~$ ~/test1/200330/install/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/manuel/test1/200330/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/manuel/test1/200330/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/manuel/test1/src/configure
--prefix=/home/manuel/test1/./200330/install
--enable-languages=c,c++,objc,fortran,ada,obj-c++
Thread model: posix
gcc version 4.9.0 20130622 (experimental) [trunk revision 195333] (GCC)
Are you sure you don't have some local arch-linux patches? Have you tried
directly downloading the svn version?
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Sorry, I didn't intend to confirm it until someone else can reproduce it.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #11 from Allan McRae allan at archlinux dot org --- Created attachment 30345 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30345action=edit log of gdb session Here is the log from my gdb session. Arch builds with no patches, just a could of small sed lines that should not affect this. See our build script (plain bash): https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gcc Since it is also in Fedora rawhide, hopefully someone there can confirm.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Allan McRae from comment #11) Created attachment 30345 [details] log of gdb session Here is the log from my gdb session. Arch builds with no patches, just a could of small sed lines that should not affect this. See our build script (plain bash): https://projects.archlinux.org/svntogit/packages.git/tree/trunk/ PKGBUILD?h=packages/gcc Does it do a full bootstrap? My gdb session looks more optimized than yours. Perhaps it is a bug in the host compiler? My version also does not ever execute this: Breakpoint 1, linemap_add (set=0x77ff9000, reason=LC_ENTER, sysp=2, to_file=0x140e270 /usr/include/stdc-predef.h, to_line=1) at /build/gcc-git/src/gcc/libcpp/line-map.c:291 In fact, I don't have this file. manuel@gcc10:~$ cat /etc/debian_version 6.0.6 so the presence of the file may make a difference (unfortunately, I don't have root access to gcc10 to fake the file and test).
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #13 from Allan McRae allan at archlinux dot org --- The Arch gcc does the full bootstrap. The debug build I am using was compiled with DEBUG_CFLAGS=-g -fvar-tracking-assignments. The file /usr/include/stdc-predef.h is from glibc (v2.17 on Arch) and is specifically mentioned as being preincluded in http://gcc.gnu.org/gcc-4.8/porting_to.html. In fact, using -ffreestanding solves the issue.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Allan McRae from comment #6) I have also confirmed this issue on Fedora rawhide. gcc 4.8.1 20130603 (Red Hat 4.8.1-1) What I would do to investigate this issue is to put a breakpoint in linemap_add and try to figure out what is the difference with and without the -imacro. There must be some difference there.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org Component|middle-end |c --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Can you provide a complete testcase? Thanks.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #2 from Allan McRae allan at archlinux dot org ---
# echo int main() { return } foo.c
# touch foo.h
# gcc -imacros foo.h foo.c
command-line: In function ‘main’:
command-line:1:21: error: expected expression before ‘}’ token
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Allan McRae from comment #2)
# echo int main() { return } foo.c
# touch foo.h
# gcc -imacros foo.h foo.c
command-line: In function ‘main’:
command-line:1:21: error: expected expression before ‘}’ token
I cannot reproduce this with r198545, so it seems fixed in mainline. Could you
test with that?
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I mean in GCC 4.9.0 (trunk), (that revision is the latest I have built).
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #5 from Allan McRae allan at archlinux dot org --- I still get this with r200224 # gcc-4.9 -v Using built-in specs. COLLECT_GCC=gcc-4.9 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-git/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share/gcc-4.9 --with-bugurl='http://aur.archlinux.org/packages.php?ID=16045' --enable-languages=c,c++,lto --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --disable-multilib --disable-libssp --disable-werror --enable-checking=release --program-suffix=-4.9 --enable-version-specific-runtime-libs Thread model: posix gcc version 4.9.0 20130619 (experimental) (GCC) Built with CFLAGS=-march=x86-64 -mtune=generic -O2 -fstack-protector --param=ssp-buffer-size=4 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #6 from Allan McRae allan at archlinux dot org --- I have also confirmed this issue on Fedora rawhide. gcc 4.8.1 20130603 (Red Hat 4.8.1-1)
