strange error
When I try to compile this code (witch has one ')' missing) I get a strange error... Is it a bug? I use gcc (GCC) 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) 29: for(i=1; i cbarre.c: In function `argomenti': cbarre.c:29: warning: too many arguments for format cbarre.c:30: parse error before "if" cbarre.c:30: `__s1_len' undeclared (first use in this function) cbarre.c:30: (Each undeclared identifier is reported only once cbarre.c:30: for each function it appears in.) cbarre.c:30: `__s2_len' undeclared (first use in this function) cbarre.c:30: warning: left-hand operand of comma expression has no effect cbarre.c:30: warning: left-hand operand of comma expression has no effect cbarre.c:30: warning: left-hand operand of comma expression has no effect cbarre.c:30: warning: left-hand operand of comma expression has no effect cbarre.c: At top level: cbarre.c:30: parse error before ')' token cbarre.c:32: parse error before '[' token cbarre.c:32: warning: type defaults to `int' in declaration of `__result' cbarre.c:32: ISO C forbids data definition with no type or storage class cbarre.c:32: parse error before '}' token cbarre.c:32: conflicting declarations of `__result' cbarre.c:32: `__result' previously declared here cbarre.c:32: warning: `__result' was declared `extern' and later `static' cbarre.c:32: `vsArg' undeclared here (not in a function) cbarre.c:32: `i' undeclared here (not in a function) cbarre.c:32: `__s2' undeclared here (not in a function) cbarre.c:32: parse error before "if" cbarre.c:32: warning: type defaults to `int' in declaration of `__result' cbarre.c:32: conflicting declarations of `__result' cbarre.c:32: `__result' previously defined here cbarre.c:32: ISO C forbids data definition with no type or storage class cbarre.c:32: parse error before '}' token cbarre.c:32: warning: type defaults to `int' in declaration of `__result' cbarre.c:32: ISO C forbids data definition with no type or storage class cbarre.c:32: parse error before '}' token cbarre.c:32: conflicting declarations of `__result' cbarre.c:32: `__result' previously declared here cbarre.c:32: warning: `__result' was declared `extern' and later `static' cbarre.c:32: `__s1' undeclared here (not in a function) cbarre.c:32: parse error before "if" cbarre.c:32: warning: type defaults to `int' in declaration of `__result' cbarre.c:32: conflicting declarations of `__result' cbarre.c:32: `__result' previously defined here cbarre.c:32: ISO C forbids data definition with no type or storage class cbarre.c:32: parse error before '}' token cbarre.c:34: parse error before '[' token cbarre.c:34: warning: type defaults to `int' in declaration of `__result' cbarre.c:34: ISO C forbids data definition with no type or storage class cbarre.c:34: parse error before '}' token cbarre.c:34: conflicting declarations of `__result' cbarre.c:34: `__result' previously declared here cbarre.c:34: warning: `__result' was declared `extern' and later `static' cbarre.c:34: `vsArg' undeclared here (not in a function) cbarre.c:34: `i' undeclared here (not in a function) cbarre.c:34: `__s2' undeclared here (not in a function) cbarre.c:34: parse error before "if" cbarre.c:34: warning: type defaults to `int' in declaration of `__result' cbarre.c:34: conflicting declarations of `__result' cbarre.c:34: `__result' previously defined here cbarre.c:34: ISO C forbids data definition with no type or storage class cbarre.c:34: parse error before '}' token cbarre.c:34: warning: type defaults to `int' in declaration of `__result' cbarre.c:34: ISO C forbids data definition with no type or storage class cbarre.c:34: parse error before '}' token cbarre.c:34: conflicting declarations of `__result' cbarre.c:34: `__result' previously declared here cbarre.c:34: warning: `__result' was declared `extern' and later `static' cbarre.c:34: `__s1' undeclared here (not in a function) cbarre.c:34: parse error before "if" cbarre.c:34: warning: type defaults to `int' in declaration of `__result' cbarre.c:34: conflicting declarations of `__result' cbarre.c:34: `__result' previously defined here cbarre.c:34: ISO C forbids data definition with no type or storage class cbarre.c:34: parse error before '}' token cbarre.c:36: parse error before '[' token cbarre.c:36: warning: type defaults to `int' in declaration of `__result' cbarre.c:36: ISO C forbids data definition with no type or storage class cbarre.c:36: parse error before '}' token cbarre.c:36: conflicting declarations of `__result' cbarre.c:36: `__result' previously declared here cbarre.c:36: warning: `__result' was declared `extern' and later `static' cbarre.c:36: `vsArg' undeclared here (not in a function) cbarre.c:36: `i' undeclared here (not in a function) cbarre.c:36: `__s2' undeclared here (not in a function) cbarre.c:36: parse error before "if" cbarre.c:36: warning: type defaults to `int' in declaration of `__result' cbarre.c:36: conflicting declarations of `__result' cbarre.c:36: `__result' previously defined here cbarre.c:36: ISO C forbids data defin
Project Mail.
[Bug c++/39425] New: gcc loops after reporting template instantiation errors
On the following example, gcc seems to loop and starts filling the ram after
reporting the errors. Same issue on x86_64-linux-gnu or with older 4.x
versions.
~/tmp$ cat test2.cpp
class a {
template
struct _rec {
static const char size = _rec< (s >> 1) >::size;
};
template<>
struct _rec <0> {
static const char size = 0;
};
static const unsigned int value = _rec < 1 >::size;
}
~/tmp$ g++-4.3 -v -ftemplate-depth-4 test2.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-5'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Debian 4.3.3-5)
COLLECT_GCC_OPTIONS='-v' '-ftemplate-depth-4' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/i486-linux-gnu/4.3.3/cc1plus -quiet -v -D_GNU_SOURCE test2.cpp
-quiet -dumpbase test2.cpp -mtune=generic -auxbase test2 -version
-ftemplate-depth-4 -o /tmp/ccZ7Hrtb.s
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.3
/usr/include/c++/4.3/i486-linux-gnu
/usr/include/c++/4.3/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.3.3/include
/usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed
/usr/include
End of search list.
GNU C++ (Debian 4.3.3-5) version 4.3.3 (i486-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version
2.4.0-p2.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64543
Compiler executable checksum: 6dda33bccb1e3fda2076fc047c4bfa75
test2.cpp:8: error: explicit specialization in non-namespace scope ‘class
a’
test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13: instantiated from here
test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13: instantiated from here
test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13: instantiated from here
test2.cpp:5: error: ‘a::_rec<0u>::size’ cannot be initialized by a
non-constant expression when being declared
test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13: instantiated from here
test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5: instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13: instantiated from here
^C
(exit 130)
--
Summary: gcc loops after repo
[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
Andrew Ayer changed:
What|Removed |Added
CC||bugs at mm dot beanwood.com
--- Comment #4 from Andrew Ayer 2013-02-24
22:05:26 UTC ---
(In reply to comment #2)
> I want to understand how critical this additional underflow is,
> performance-wise
There are also correctness implications: what if you're trying to ignore
all the bytes you know are available to be read without blocking? Then
the extra underflow blocks, possibly forever if the program is prevented
from taking action that would result in the underflow completing.
I got bitten by this because I was trying to ignore data from a socket.
Note that the standard has similar language for read(char_type*,
streamsize) ("either of the following conditions") but the library in
effect checks for n characters being reached before checking for eof:
if you read() exactly the number of characters left in the stream,
eofbit is not set. So the library isn't currently consistent across
all the various istream functions.
I would argue that the current behavior of ignore() is actually contrary
to the standard. If the standard says "until any" then ignore()
needs to terminate when n characters have been extracted. But if it
first checks for eof and blocks forever, then it doesn't terminate.
Perhaps this is why getline explicitly mentions the order: in that case
the standard really does want eof to be checked first.
[Bug c++/56692] New: [4.8 Regression] [C++11] Segmentation fault when calling static/non-static overloaded function from lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56692
Bug #: 56692
Summary: [4.8 Regression] [C++11] Segmentation fault when
calling static/non-static overloaded function from
lambda
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@mm.beanwood.com
The following causes an "Internal compiler error: Segmentation fault" in GCC
4.8.0 when compiled with 'g++ -std=c++11':
struct Class {
void f () { }
static void f (int) { }
};
int main ()
{
[] () { Class::f(0); };
}
This does not segfault in 4.7.2. Removing the non-static f declaration
prevents the segfault.
gcc was compiled with no configure arguments. The system is i686-pc-linux-gnu.
Here's the complete error message, including stack trace:
t.c: In lambda function:
t.c:8:17: internal compiler error: Segmentation fault
[] () { Class::f(0); };
^
0x84edeb1 crash_signal
../.././gcc/toplev.c:332
0x81c64c9 lookup_base(tree_node*, tree_node*, int, base_kind*, int)
../.././gcc/cp/search.c:199
0x81d276c finish_qualified_id_expr(tree_node*, tree_node*, bool, bool, bool,
bool)
../.././gcc/cp/semantics.c:1786
0x81d32a3 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool,
bool, bool, char const**, unsigned int)
../.././gcc/cp/semantics.c:3348
0x8187f06 cp_parser_primary_expression
../.././gcc/cp/parser.c:4394
0x81892d9 cp_parser_postfix_expression
../.././gcc/cp/parser.c:5629
0x818b223 cp_parser_unary_expression
../.././gcc/cp/parser.c:6685
0x818bcf5 cp_parser_binary_expression
../.././gcc/cp/parser.c:7365
0x818c1d0 cp_parser_assignment_expression
../.././gcc/cp/parser.c:7590
0x818dd8c cp_parser_expression
../.././gcc/cp/parser.c:7741
0x818e3fd cp_parser_expression_statement
../.././gcc/cp/parser.c:9021
0x8185717 cp_parser_statement
../.././gcc/cp/parser.c:8873
0x81869d5 cp_parser_statement_seq_opt
../.././gcc/cp/parser.c:9139
0x8187ceb cp_parser_lambda_body
../.././gcc/cp/parser.c:8653
0x8187ceb cp_parser_lambda_expression
../.././gcc/cp/parser.c:8194
0x8187ceb cp_parser_primary_expression
../.././gcc/cp/parser.c:4085
0x81892d9 cp_parser_postfix_expression
../.././gcc/cp/parser.c:5629
0x818b223 cp_parser_unary_expression
../.././gcc/cp/parser.c:6685
0x818bcf5 cp_parser_binary_expression
../.././gcc/cp/parser.c:7365
0x818c1d0 cp_parser_assignment_expression
../.././gcc/cp/parser.c:7590
Thanks!
[Bug c++/50512] New: surprising change in overloading resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50512 Bug #: 50512 Summary: surprising change in overloading resolution Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@mezzarobba.net The attached programm returns: 1 when compiled with g++ from the Debian package g++-4.6.1-9 (which says it is based on SVN r178501); 2 with g++-4.6.1-10 (r178746) or g++-4.6.1-11; 1 again with g++-4.6.12 (r179140) 2 with gcc-snapshot-20110924-1 (trunk r179143). I'm not 100% sure what the correct behaviour is, but the change does not look deliberate. (Could it be related to PR c++/50442?) ~$ g++ -v test.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-12' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Debian 4.6.1-12) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1plus -quiet -v -imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -version -o /tmp/ccHeTpTX.s GNU C++ (Debian 4.6.1-12) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.2, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.6 /usr/include/c++/4.6/x86_64-linux-gnu/. /usr/include/c++/4.6/backward /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++ (Debian 4.6.1-12) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.2, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: a48902e2296a3dd0e51e6adfff572b1c COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as --64 -o /tmp/ccnazg5w.o /tmp/ccHeTpTX.s COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/collect2 --build-id --no-add-needed --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../.. /tmp/ccnazg5w.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crtn.o ~$ ./a.out || echo $? 1 ~$ g++ -v test.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.7.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20110924-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,fortran,objc,obj-c++,go --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --wi
[Bug c++/50512] surprising change in overloading resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50512 --- Comment #1 from mm at mezzarobba dot net 2011-09-25 16:51:17 UTC --- Created attachment 25361 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25361 testcase
[Bug c++/51121] New: Duplicate destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51121
Bug #: 51121
Summary: Duplicate destructors
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@mm.st
g++ generates bad assembly for this code:
---
#include
#include
#include
using std::decimal::decimal32;
int
main( int, char ** )
{
std::multimap< decimal32, std::pair< std::string, decimal32 > > m;
decimal32 d1;
std::string str;
decimal32 d2;
m.insert( std::make_pair( d1, std::make_pair( str, d2 )));
return 0;
}
---
Specifically, it says
$ g++ -c multimap_decimal.cpp
/tmp/cc2sQism.s: Assembler messages:
/tmp/cc2sQism.s:1690: Error: symbol `_ZNSt4pairIDfS_ISsDfEED2Ev' is already
defined
That symbol is the destructor for std::pair< decimal32, std::pair< std::string,
decimal32 > >. It seems that g++ is instatiating a destructor for that type
and with the first decimal32 replaced with const decimal32 and giving both the
same mangled name. So it works if I change the m.insert() line to
std::pair< const decimal32, std::pair< std::string, decimal32 > >
p( d1, std::make_pair( str, d2 ));
m.insert( p );
.ii file attached.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
[Bug c++/51121] Duplicate destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51121 --- Comment #1 from David Bustos 2011-11-14 14:34:54 UTC --- Created attachment 25817 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25817 .ii file of problematic code
[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 Romain changed: What|Removed |Added CC||romain.services at mm dot st --- Comment #6 from Romain --- Hi, > It might be an interesting exercise to encrypt the APFS volume and see if that throws just enough additional filesystem overhead in to make the problem go latent. I'm also trying to compile gcc-7.2.0 on macOS 10.13, and I'm using encrypted APFS, but it does not make this bug disappear. Regards, Romain
[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #8 from Romain --- Hi Jack, Thanks. My system is a Core i7 (HT enabled), so I have 8 cores, good catch! Regards, Romain
[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #14 from Romain Bossart --- Thank you Jack, gcc-7.2.0 now compiles correctly on my i7 system (8 cores HT) with encrypted APFS Best regards
[Bug libstdc++/80654] New: is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654
Bug ID: 80654
Summary: is_trivially_copy_constructible fails with compiler
error with vector of uncopyable objects
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at mm dot beanwood.com
Target Milestone: ---
Created attachment 41332
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41332&action=edit
Pre-processed file that triggers bug
std::is_trivially_copy_constructible>::value, where nocopy
is a non-copyable type (e.g. std::unique_ptr), causes a compiler error instead
of producing a value of false as expected.
A practical consequence of this bug is that it is not possible to
move-construct a std::optional>, because std::optional uses
std::is_trivially_copy_constructible internally.
Preprocessed file is attached.
Compiler output:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-7/current.x86_64/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-7/7.1.0.x86_64/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /usr/local/gcc-7/tmp-build/gcc-7.1.0/configure
--prefix=/usr/local/gcc-7/7.1.0.x86_64 --enable-languages=c,c++,go
--with-arch-32=i586
Thread model: posix
gcc version 7.1.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/local/gcc-7/7.1.0.x86_64/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1plus -E
-quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE bug.cpp -mtune=generic
-march=x86-64 -fpch-preprocess -o bug.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../include/c++/7.1.0
/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../include/c++/7.1.0/x86_64-pc-linux-gnu
/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../include/c++/7.1.0/backward
/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include
/usr/local/include
/usr/local/gcc-7/7.1.0.x86_64/include
/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/local/gcc-7/7.1.0.x86_64/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1plus
-fpreprocessed bug.ii -quiet -dumpbase bug.cpp -mtune=generic -march=x86-64
-auxbase bug -version -o bug.s
GNU C++14 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.0.0, MPFR version
3.1.2-p3, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.0.0, MPFR version
3.1.2-p3, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b73243a43f922df6e56feb5c73c5449a
In file included from
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/vector:62:0,
from bug.cpp:3:
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_construct.h: In
instantiation of 'void std::_Construct(_T1*, _Args&& ...) [with _T1 = nocopy;
_Args = {const nocopy&}]':
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_uninitialized.h:83:18:
required from 'static _ForwardIterator
std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*; bool _TrivialValueTypes = false]'
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_uninitialized.h:134:15:
required from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*]'
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_uninitialized.h:289:37:
required from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator,
_InputIterator, _ForwardIterator, std::allocator<_Tp>&) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*; _Tp = nocopy]'
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_vector.h:331:31:
required from 'std::vector<_Tp, _Alloc&
[Bug c/65833] New: Attempting to convert 128 bit integers to 128 bit decimal floating-point results in an unresolved symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65833
Bug ID: 65833
Summary: Attempting to convert 128 bit integers to 128 bit
decimal floating-point results in an unresolved symbol
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mm at mezzarobba dot net
CC: christoph.lauter at lip6 dot fr
The following code
$ cat stitd.c
int main(void) {
__uint128_t foo = 42;
_Decimal128 bar = foo;
(void) bar;
return 0;
}
fails to link with
$ gcc -Wall -Wextra -std=gnu11 stitd.c
/tmp/ccY4noUz.o: In function `main':
stitd.c:(.text+0x27): undefined reference to `__bid_floatunstitd'
collect2: error: ld returned 1 exit status
(exit 1)
Changing __uint128_t to __int128_t results in a similar error. Replacing
_Decimal128 by __float128 works.
~/docs/vrac/c$ gcc -v --version
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.9/cc1 -quiet -v -imultiarch x86_64-linux-gnu
help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase
help-dummy -version --version -o /tmp/cc2dxKl2.s
GNU C (Debian 4.9.2-10) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p3, MPC version 1.0.2
warning: MPFR header version 3.1.2-p3 differs from library version 3.1.2-p11.
warning: MPC header version 1.0.2 differs from library version 1.0.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64'
as -v --64 --version -o /tmp/ccNgVCKN.o /tmp/cc2dxKl2.s
GNU assembler version 2.25 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.25
GNU assembler (GNU Binutils for Debian) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-linux-gnu'.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.9/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc8TwP9y.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/
--build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker
/lib64/ld-linux-x86-64.so.
[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857 --- Comment #6 from Andrew Ayer --- Any word on if this will be fixed in GCC? To summarize, GCC's current behavior is wrong because: * Underflowing after ignoring the requested number of bytes could block forever, breaking applications. * The standard says "characters are extracted until ANY of the following occurs: ... n characters are extracted" (emphasis mine). If ignore() blocks forever after extracting n characters, it's a violation of the standard because it doesn't terminate as is required. * GCC's std::basic_istream::read() implementation does NOT underflow after reading the requested number of bytes (even though the standard uses similar language for read and ignore). This inconsistent behavior is confusing as one would expect read and ignore to behave equivalently. * Other major C++ implementations don't underflow after ignoring the requested number of bytes. (Thanks, Sergey, for checking this.) I wrote about this in greater depth at [1] and also wrote my own non-member ignore() which I'm using in place of basic_istream::ignore() [2] which others may find useful until this bug is fixed. [1] https://www.agwa.name/blog/post/gccs_implementation_of_basicistreamignore_is_broken [2] https://www.agwa.name/blog/post/gccs_implementation_of_basicistreamignore_is_broken/media/ignore.h
[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
mm-nospam at outlook dot co.nz changed:
What|Removed |Added
CC||mm-nospam at outlook dot co.nz
--- Comment #14 from mm-nospam at outlook dot co.nz ---
The bug still occurs for the same test case with the f() function modified as
such:
X f()
{
try {
X x(true);
return X(false);
} catch(...) { }
return X(false);
}
The first X(false) is constructed and never destructed.
This example also occurs in [except.ctor]/2 of the C++17 standard, note that
since C++17 X's destructor should be marked as noexcept(false) in the test
case.
