[Bug bootstrap/58289] New: gcc/gengtype.c includes gcc/double-int.h, which uses C++ constructs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58289
Bug ID: 58289
Summary: gcc/gengtype.c includes gcc/double-int.h, which uses
C++ constructs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jklowden at schemamania dot org
I pulled from svn://gcc.gnu.org/svn/gcc/trunk today to build gcc on OS X using
Clang. Some header files use C++ syntax, but are included in C files. The
error I'm seeing is:
/Developer/usr/bin/clang [...options omitted...]
-o build/gengtype.o ../../gcc/gengtype.c
[...warnings ommitted...]
In file included from ../../gcc/gengtype.c:28:
../../gcc/double-int.h:58:10: error: must use 'struct' tag to refer to type
'double_int'
static double_int from_uhwi (unsigned HOST_WIDE_INT cst);
The error stems from this construct in double-int.h:
==snip==
struct double_int
{
/* Normally, we would define constructors to create instances.
Two things prevent us from doing so.
First, defining a constructor makes the class non-POD in C++03,
and we certainly want double_int to be a POD.
Second, the GCC conding conventions prefer explicit conversion,
and explicit conversion operators are not available until C++11. */
static double_int from_uhwi (unsigned HOST_WIDE_INT cst);
==pins==
Comment not withstanding, the file could easily be converted to C; there are no
classes declared, for instance. All that's needed is say,
static struct double-int from_uhwi = cst;
perhaps with a cast.
I found similar problems in two other files that were small enough to repair or
work around. This file seems to be a pupa determined to become C++, and I'm
not quite sure what should be done.
[Bug bootstrap/58289] gcc/gengtype.c includes gcc/double-int.h, which uses C++ constructs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58289 --- Comment #2 from James K. Lowden --- (In reply to Andrew Pinski from comment #1) > GCC is now a C++ program even though it uses the .c file extension. Use > clang in C++ mode instead. Thank you, but the the problem is not completely solved. 1. This is not mentioned anywhere in http://gcc.gnu.org/install/configure.html. 2. Not all .c files needed to build gcc are C++. Setting Clang to compile all files as C++ means libiberty cannot be compiled: ../../../libiberty/sha1.c:235:11: error: '' can not be defined in a type specifier The compiler has precious little information to tell it what language to use. How to distinguish between C and C++ if not by the extension? Particularly in a project with both C and C++ source files among its build-time dependencies?
[Bug c++/45536] New: gcc updates output timestamp even when compilation fails
e=131072
Compiler executable checksum: 2d02d8750f9b337bb19a7dd5b4e2167e
While one might argue GIGO, including extra filenames on the command line is an
easy mistake to make. I submit gcc should make every effort not to produce
invalid binaries.
--
Summary: gcc updates output timestamp even when compilation fails
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jklowden at schemamania dot org
GCC build triplet: elf_x86_64
GCC host triplet: elf_x86_64
GCC target triplet: elf_x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45536
[Bug libstdc++/45725] New: streambuf_iterator compares equal when it should not
bool std::operator==( std::istreambuf_iterator, std::istreambuf_iterator )
returns TRUE if both iterators are EOF or both are not. That means two
iterators at different places in the streambuf -- which, when dereferenced
produce different characters -- nevertheless compare as equal. This is
inconsistent with how other iterators work, and inconsistent with the pointer
model of iterators.
streambuf iterators are constructed from a stream, and could use the stream's
tellg/tellp to determine equality. (Two streams both at EOF should of course
continue to be equal to permit canonical use in e.g. std::copy.)
In the program below, two istreambuf_iterator objects repeatedly compare as
true even though one is incremented. I would expect no output, but the program
produces:
45 4c 46 01 01 01 00 00 00 00
IOW, two such iterators are always equal! Or, acutally, looking at the
operator==() code:
return (__thiseof && __beof || (!__thiseof && !__beof));
their equality is a function of their EOF status only.
== snip ==
#include
#include
#include
#include
using namespace std;
int
main( int argc, char *argv[] )
{
string name(argv[0]);
ifstream input( name.c_str() );
istreambuf_iterator begin(input);
istreambuf_iterator end(input);
for( int i=0; i < 10; i++ ) {
if( begin == ++end ) {
int data = *end;
cout << setw(2) << setfill('0')
<< hex << data << ' ';
}
}
return 0;
}
== pins ==
Unless two streambuf_iterators can be compared for equality within the stream,
it's impossible to use standard algorithms with them to process part of a file:
to work, one iterator must always be EOF.
--
Summary: streambuf_iterator compares equal when it should not
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jklowden at schemamania dot org
GCC build triplet: i386--netbsdelf
GCC host triplet: i386--netbsdelf
GCC target triplet: i386--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45725
[Bug libstdc++/78276] regex_search is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78276 James K. Lowden changed: What|Removed |Added CC||jklowden at schemamania dot org --- Comment #2 from James K. Lowden --- Created attachment 56124 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56124&action=edit test programs and input
[Bug libstdc++/78276] regex_search is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78276
--- Comment #3 from James K. Lowden ---
Here is a nonpathological example taken from a real-world problem were
std::regex_search fails.
This pattern is part of the COBOL COPY text-manipulation directive:
([[:space:]]+(LEADING|TRAILING))?[[:space:]]+("((["]{2}|[^"])*)"|'(([']{2}|[^'])*)[']|([[:alnum:]]+([_-]+[[:alnum:]]+)*)|==((=?[^=]+)+)==)[[:space:]]+BY[[:space:]]+(("(["]{2}|[^"])*")|('([']{2}|[^'])*')|([[:alnum:]]+([_-]+[[:alnum:]]+)*)|==((=?[^=]+)*)==)([[:space:]]*[.])?
That pattern has 21 captures. Ignoring the optional LEADING/TRAILING clause,
it accepts 1 of 3 operands on either side of the BY keyword:
1. a quoted string using the " double-quote
2. a quoted string using the ' single-quote
3. an identifier consisting of alphanumerics with hyphens or underscores
Quoted strings in this syntax may include embedded quotes by doubling them.
By "fails", I mean "does not terminate" in a reasonable time. Using gdb I have
seen over 1900 stack frames inside std::regex_search. This is with gcc 11 on
Linux.
I have recast the program using awk and regex(3) from the C standard library,
both of which succeed instantly. I attach a tarball that includes all three
files, the input, and a Makefile to demonstrate them.
