[Bug c/40228] New: Provide option to show preprocessed line with errors
Hi, I think it would be useful to display the preprocessed line with errors (in C/C++ in my case) for those occasions when the problem is related to a macro going wrong.I suggest this would be an option since most of the time you wouldn't want it. Crawling through the output of gcc -E and trying to find the line that actually corresponds the error is quite hard work, and if the compiler already has the line that it should help us by showing it (possibly with the line before as well?) Dave -- Summary: Provide option to show preprocessed line with errors Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at treblig dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40228
[Bug c++/24985] caret diagnostics
--- Comment #8 from dave at treblig dot org 2009-07-03 11:03 --- Note there are two slightly different things being asked for here: 1) Showing the horizontal position in the line 2) show the preprocessed line rather than the raw line (which was my 40228 that just got marked as a dupe) - obviously this would be an option rather than the default. I'm not entirely sure they are actually dupes. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
[Bug c++/71507] New: Unending compilation/google's protobuf (protstream_objectsource_test.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71507 Bug ID: 71507 Summary: Unending compilation/google's protobuf (protstream_objectsource_test.cc) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dave at treblig dot org Target Milestone: --- This compile has been cooking for 50+mins on an i7 so far, nothing in the .s, and it's RAM usage is unchanging (and not using much RAM). [dg@major src]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 6.1.1 20160510 (Red Hat 6.1.1-2) (GCC) (Fedora 24 gcc-c++-6.1.1-2.fc24.x86_64 - I can see a similar report from an Arch user that they're hitting the same problem, so I don't think it's just me) The attached file is preprocessed from Google's protobuf; protostream_objectsource_test.cc and it hit this during the make check. The full running command line is: ++ -DHAVE_CONFIG_H -I. -I.. -I./../gmock/gtest/include -I./../gmock/include -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -DNDEBUG -MT google/protobuf/util/internal/protobuf_test-protostream_objectsource_test.o -MD -MP -MF google/protobuf/util/internal/.deps/protobuf_test-protostream_objectsource_test.Tpo -c -o google/protobuf/util/internal/protobuf_test-protostream_objectsource_test.o google/protobuf/util/internal/protostream_objectsource_test.cc and to produce the attached file I did: g++ -DHAVE_CONFIG_H -I. -I.. -I./../gmock/gtest/include -I./../gmock/include -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -DNDEBUG -MT google/protobuf/util/internal/protobuf_test-protostream_objectsource_test.o -MD -MP -MF google/protobuf/util/internal/.deps/protobuf_test-protostream_objectsource_test.Tpo -c -E google/protobuf/util/internal/protostream_objectsource_test.cc -o preprocessed-protostream_objectsource_test.cc
[Bug c++/71507] Unending compilation/google's protobuf (protstream_objectsource_test.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71507 --- Comment #1 from Dr. David Alan Gilbert --- Created attachment 38692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38692&action=edit compressed, preprocessed c++
[Bug c++/71507] Unending compilation/google's protobuf (protstream_objectsource_test.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71507 --- Comment #4 from Dr. David Alan Gilbert --- Ah thanks.
[Bug c/115027] New: Missing warning: unused struct's with self-referential initialisers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027
Bug ID: 115027
Summary: Missing warning: unused struct's with self-referential
initialisers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dave at treblig dot org
Target Milestone: ---
It would be nice to generate a warning in the following case, which I tripped
over in the Linux kernel:
#include
struct foo {
struct foo *a;
};
static struct foo f = { &f };
int main()
{
printf("Hello\n");
}
Here 'f' is unused outside of it's initialiser, pointing to itself.
So technically used, but practically not.
In the Linux kernel, this corresponds to it's LIST_HEAD :
(from include/linux/list.h)
#define LIST_HEAD_INIT(name) { &(name), &(name) }
#define LIST_HEAD(name) \
struct list_head name = LIST_HEAD_INIT(name)
and I've just gone through and posted patches to remove a handful of
LIST_HEADs, some of which had been unused for many years.
It would be nice if the compiler told people instead.
[Bug c/115027] Missing warning: unused struct's with self-referential initialisers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027 --- Comment #3 from Dr. David Alan Gilbert --- (For my own keeping track, Jakub replied to that patch with a suggestion: https://inbox.sourceware.org/gcc-patches/Zwlg8VYJXQmEC65C@tucnak/ )
