[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 Peter VARGA changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME |--- --- Comment #13 from Peter VARGA --- (In reply to Andrew Pinski from comment #12) > This build works for me so closing. Any chance you could be more specific? For me it doesn't work and I think the goal should be to provide as much information as possible so other none-gcc-glibc-experts have a chance to use these tools - or? I have in the 1st comment an MCVE which I doesn't compile with the default settings. OK, I got the hint to compile gcc with the glibc version - but this I am not capable and I asked for additional information. What came I don't understand Any effort to solve this?
[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 --- Comment #15 from Peter VARGA --- (In reply to Jonathan Wakely from comment #14) > Installing your own glibc in a new location and trying to point GCC to it > with -I /FaF/glibc/include is not "the default settings". > > As has been explained, you need to rebuild GCC to use the new glibc. To do > that you also need the Linux kernel headers in the same sysroot tree, i.e. > /FaF/glibc > > Did you try that yet? It would be very much appreciated if you could provide me the missing settings for my configure command line arguments which look for the moment like this: --prefix=/FaF --infodir=/FaF/share/info --mandir=/FaF/share/man --libdir=/FaF/lib64 --libexecdir=/FaF/lib64 --enable-languages=c,c++ --enable-checking=release --with-gmp=/FaF/ --with-mpfr=/FaF --with-gmc=/FaF --with-gxx-include-dir=/FaF/include/c++/7.3 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-7.3 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux --disable-multilib
[Bug c++/87017] New: vector must have the same value as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87017
Bug ID: 87017
Summary: vector must have the same value as its allocator
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
This MCVE compiles/runs with gcc 7.3, clang 6.0 and icc 18.0 [this is, what I
tested so far]:
#include
#include
#include
namespace FaF
{
template
class Allocator
{
public:
typedef T value_type;
Allocator() throw() {}
template Allocator (const Allocator&) throw() {}
~Allocator() throw() {}
T* allocate (std::size_t num, const void* hint = 0)
{
(void) hint; (void) num;
return new ( T );
}
void deallocate (T* p, std::size_t num) { (void) num; (void) p; }
};
using string = std::basic_string,
Allocator>;
using smatch = std::match_results>;
}
int main()
{
FaF::smatch results {};
std::cout << "OK\n";
}
gcc 8.2 complains here:
FaF::smatch results {};
^--- vector must have the same value as its allocator
Changing it to std::smatch then it compiles.
Compiler options:
-O3 -std=c++17 -Werror -Wextra -Wold-style-cast -Wall
Live version: https://godbolt.org/z/8wI6YS
[Bug c++/87017] vector must have the same value as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87017 Peter VARGA changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #3 from Peter VARGA --- Jonathan, I thank you very much for your clear and simple explanation. I have fixed it now as you suggested according to the standard!
[Bug c++/84744] New: cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
Bug ID: 84744
Summary: cannot use glibc 2.27 with gcc 7.3
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
Created attachment 43581
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43581&action=edit
error messages
I have installed gcc 7.3 in the /FaF directory and glibc 2.27 in the /FaF/glibc
directory.
Compiling this code
---
#include
#include
int main( int argc, char * argv [] )
{
if ( argc != 2 )
{
return 1;
}
return std::abs(std::atoi(argv[1]));
}
with g++ -c foo.cpp works fine.
Adding the glibc 2.27 include path fails horrible: g++ -c foo.cpp -I
/FaF/glibc/include
Here the full error list: https://gofile.io/?c=J2Zwlv or see the attached file.
Compiling it with the system gcc 4.8.5 works fine even the glibc 2.27 include
path is added.
Output for g++ -xc++ -E -v - -I /FaF/glibc/include/
---
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-suse-linux
Configured with: ../gcc-7.3.0/configure --prefix=/FaF --infodir=/FaF/share/info
--mandir=/FaF/share/man --libdir=/FaF/lib64 --libexecdir=/FaF/lib64
--enable-languages=c,c++ --enable-checking=release --with-gmp=/FaF/
--with-mpfr=/FaF --with-gmc=/FaF --with-gxx-include-dir=/FaF/include/c++/7.3
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/--with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-7.3 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux --disable-multilib
Thread model: posix
gcc version 7.3.0 (SUSE Linux)
COLLECT_GCC_OPTIONS='-E' '-v' '-I' '/FaF/glibc/include/' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/FaF/lib64/gcc/x86_64-suse-linux/7.3.0/cc1plus -E -quiet -v -I
/FaF/glibc/include/ -D_GNU_SOURCE - -mtune=generic -march=x86-64
ignoring nonexistent directory
"/FaF/lib64/gcc/x86_64-suse-linux/7.3.0/../../../../x86_64-suse-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/FaF/glibc/include/
/FaF/include/c++/7.3
/FaF/include/c++/7.3/x86_64-suse-linux
/FaF/include/c++/7.3/backward
/FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include
/usr/local/include
/FaF/include
/FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include-fixed
/usr/include
End of search list.
First error lines - for some reasons g++ starts to use the g++ starts to use
the g++ 4.8.5 - which is installed on the system - include path.
In file included from /usr/include/math.h:48:0,
from /FaF/include/c++/7.3/cmath:45,
from foo.cpp:11:
/FaF/glibc/include/bits/mathdef.h:19:3: error: #error "Never use
directly; include instead"
# error "Never use directly; include instead"
^
In file included from /FaF/include/c++/7.3/cstdlib:75:0,
from foo.cpp:10:
/usr/include/stdlib.h:95:1: error: ‘__BEGIN_NAMESPACE_STD’ does not name a
type; did you mean ‘__BEGIN_DECLS’?
__BEGIN_NAMESPACE_STD
^
__BEGIN_DECLS
/usr/include/stdlib.h:101:5: error: ‘div_t’ does not name a type; did you mean
‘size_t’?
} div_t;
^
[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 --- Comment #2 from Peter VARGA --- Sorry, but this does not help.
[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 --- Comment #3 from Peter VARGA --- (In reply to Andrew Pinski from comment #1) > >-I /FaF/glibc/include > > Use -isystem instead or a true sysroot instead. Sorry, but this does not help.
[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 --- Comment #4 from Peter VARGA --- (In reply to Andrew Pinski from comment #1) > >-I /FaF/glibc/include > > Use -isystem instead or a true sysroot instead. Can you post the full g++ command line options how you mean it?
[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 --- Comment #6 from Peter VARGA --- (In reply to Marc Glisse from comment #5) > That's not how you use a different glibc. If you look at the include order > printed by -v, it has to remain in that order (libstdc++ before glibc, in > particular), whereas you are adding your glibc in front. Best would be to > recompile gcc, which has the added advantage that it will be able to take > advantage of the new features in the new glibc this way. May be for you all is clear but I am not in the gnu gcc developer team and I am using only gcc. Therefore I don't really understand what I should do. You all give just half of some hints and they don't even work. What should I do different when I recompile gcc? This works - but why should I do it? Why is g++ using the path /usr/include BEFORE the others and this is the problem! gcc does NOT keep the include order. g++ foo.cpp -o foo -nostdinc -I /FaF/include/c++/7.3 -I /FaF/include/c++/7.3/x86_64-suse-linux/ -I /FaF/glibc/include/ -I /FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include In /FaF is my gcc 7.3 and in /FaF/glibc is glibc 2.27
[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 --- Comment #7 from Peter VARGA --- This is the original version: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include Before I found now finally a solution I had to sort out the order - it was not really that trivial and very annoying. This is now how it works and - as it should be - the order of the include files in the project does NOT matter anymore. BUT, it is very important that /usr/include is last in the list, otherwise it won't compile: -nostdinc -I /FaF/curl/include -I /usr/include/mysql -I /FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include-fixed -I /FaF/include/c++/7.3 -I /FaF/include/c++/7.3/x86_64-suse-linux/ -I /FaF/lib64/gcc/x86_64-suse-linux/7.3.0/include -I /FaF/glibc/include/ -I /usr/include
[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744 --- Comment #10 from Peter VARGA --- (In reply to Jonathan Wakely from comment #8) > You need to recompile gcc telling it to use the new glibc. > > When GCC is built it creates fixed dependencies on the C library. You can't > just point it to a new libc and expect it to work. A new C library needs a > new compiler as well. > > So build GCC (see https://gcc.gnu.org/wiki/InstallingGCC for a starting > point) and add --with-native-system-header-dir=/FaF/glibc/include/ to the > configure options. The option --with-native-system-header-dir=/FaF/glibc/include/ didn't work. Now, the include errors appear while compiling gcc. Below some extract. I am working on SLES 12 SP3 - the system glibc version is 2.22. OK it is 3 years old. I am using the newest glibc version 2.27 only for my project. The question is if I really need the newest version. It makes the whole process only too complicated. In file included from /FaF/glibc/include/errno.h:28:0, from ../../../gcc-7.3.0/libgcc/../gcc/tsystem.h:93, from ../../../gcc-7.3.0/libgcc/libgcc2.c:27: /FaF/glibc/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file or directory # include ^~~ In file included from /FaF/glibc/include/errno.h:28:0, from ../../../gcc-7.3.0/libgcc/../gcc/tsystem.h:93, from ../../../gcc-7.3.0/libgcc/libgcov.h:42, from ../../../gcc-7.3.0/libgcc/libgcov-interface.c:26: /FaF/glibc/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file or directory # include ^~~ In file included from /FaF/glibc/include/errno.h:28:0, from ../../../gcc-7.3.0/libgcc/../gcc/tsystem.h:93, from ../../../gcc-7.3.0/libgcc/libgcov.h:42, from ../../../gcc-7.3.0/libgcc/libgcov-merge.c:26:
[Bug c++/69723] New: Inconsistent report of unused and uninitialized variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
Bug ID: 69723
Summary: Inconsistent report of unused and uninitialized
variables
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
It is here described:
http://stackoverflow.com/questions/35269414/gcc-does-not-warn-variable-set-but-not-used
auto foo() -> void
{
int unused = 0;
unused++;
}
and
auto foo() -> void
{
int x;
int unused;
for ( ; x < 100; x++ ) unused++;
}
do not generate and warnings. Only the -O1 generates an error. I expect
error: variable ‘unused’ set but not used [-Werror=unused-but-set-variable].
error: ‘unused’ and ‘x’ are used uninitialized [-Werror=uninitialized]
[Bug c++/69723] Inconsistent report of unused and uninitialized variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723 --- Comment #1 from Peter VARGA --- Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.3/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.3_source/configure --disable-multilib Thread model: posix gcc version 4.9.3 (GCC)
[Bug c++/69723] Inconsistent report of unused and uninitialized variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723 --- Comment #3 from Peter VARGA --- Dear Jakob, thank you for the explanation. But honestly, the "definition" when to warn is in my eyes wrong. Even var++ is reading and then setting the variable in this case it does NOT make sense! Just imagine I had a function with 200 lines and I "forgot" this variable in a refactoring process. gcc could have warn me because it is not logical and the variable is set but NOT used. May be the gcc community can reconsider the definition.
[Bug c++/69723] Inconsistent report of unused and uninitialized variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723 --- Comment #5 from Peter VARGA --- I do not understand what you mean with "Replace unused++ with unused = unused + 1". How ever. I checked my example code in Compiler Explorer with clang and clang generates a warning as it should be. OK. You was honest that this means a lot of work but it is a bug and of course everybody can live with it. https://goo.gl/5eaLw5
[Bug c++/69925] New: No warning for uninitialized char * passing to function as const char *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69925
Bug ID: 69925
Summary: No warning for uninitialized char * passing to
function as const char *
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
auto foo( const char * ) -> void;
int main()
{
char bar [100];
foo( bar );
}
In my opinion gcc should warn that bar is uninitialized used due to the fact it
is used as const in foo().
g++ -Wall -Wextra -Werror -c foo.cpp
I have to admit that I could not find any compiler which warns about this:
https://goo.gl/0d6KU4
[Bug c++/69925] No warning for uninitialized char * passing to function as const char *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69925 --- Comment #2 from Peter VARGA --- I expected honestly this answer but then almost every compiler warning can be "overruled" by a bad programmer. By the way I found out this behavior because I used it in STL and there is almost every parameter const when it makes sense.
[Bug libstdc++/71562] New: Changing the fix size of _S_local_capacity in sso_string_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71562
Bug ID: 71562
Summary: Changing the fix size of _S_local_capacity in
sso_string_base.h
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
Would it be possible to change the hard coded size <_S_local_capacity> in
in line #55 from 15 to a PREPROCESSOR_DEFINE which can be
provided to the compiler in the command line?
To catch the situation the PREPROCESSOR_DEFINE is not set, there have to be a
check in the beginning of the include file like this [the name is an example]:
#ifndef LOCAL_CAPACITY_STRING_BASE
#define LOCAL_CAPACITY_STRING_BASE 15
#endif
and then line #55 would be this:
enum { _S_local_capacity = LOCAL_CAPACITY_STRING_BASE };
This would increase the flexibility for the programmer without a hack in the
c++ include file...
[Bug libstdc++/71562] Changing the hard coded size of _S_local_capacity in sso_string_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71562 --- Comment #2 from Peter VARGA --- I disagree 100% with your comment! I am definitely NOT a genius and I needed 5 minutes to find out where the hard coded size is set. Look at the GNU Glibc - you can crash an existing system when running ./configure with the wrong paths/settings. In the documentation is a warning. You NEVER can be responsible if a programmer does NOT know what he is doing. You can only warn them and then let it go. I do NOT need this define - I set it already to my own value but because vstring.h has the special status I thought it may be also for other programner useful. Why 15 and not 30? Do you understand what I mean?
[Bug c++/65512] New: Inconsistent report of uninitialized members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
Bug ID: 65512
Summary: Inconsistent report of uninitialized members
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
#include
typedef struct
{
charsDateTime [20];
std::atomicbReadyToFlush;
} LogEntries;
typedef struct
{
LogEntriesleLogEntries [1] {};
} LogThreads;
Compiling with g++ -std=c++11 gcc-warning-bug.cpp -Wall -Wextra -Werror
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -c
Compiler error:
gcc-warning-bug.cpp:11:34: error: missing initializer for member
‘LogEntries::sDateTime’ [-Werror=missing-field-initializers]
LogEntriesleLogEntries [1] {};
^
gcc-warning-bug.cpp:11:34: error: missing initializer for member
‘LogEntries::bReadyToFlush’ [-Werror=missing-field-initializers]
cc1plus: all warnings being treated as error
I consider it as a bug because one of these following steps does not produce
the error message:
1) comment the line std::atomicbReadyToFlush;
2) Add {} to char sDateTime [20];
[Bug c++/65512] Inconsistent report of uninitialized members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512 --- Comment #1 from Peter VARGA --- Output for the -v option: Using built-in specs. COLLECT_GCC=g++ Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.2_source/configure --disable-multilib Thread model: posix gcc version 4.9.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra' '-c' '-Werror' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -E -quiet -v -D_GNU_SOURCE gcc-warning-bug.cpp -mtune=generic -march=x86-64 -std=c++11 -Wall -Wextra -Werror -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fpch-preprocess -o gcc-warning-bug.ii ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/backward /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra' '-c' '-Werror' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -fpreprocessed gcc-warning-bug.ii -quiet -dumpbase gcc-warning-bug.cpp -mtune=generic -march=x86-64 -auxbase gcc-warning-bug -Wall -Wextra -Werror -std=c++11 -version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o gcc-warning-bug.s GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.2, GMP version 4.2.3, MPFR version 3.1.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.2, GMP version 4.2.3, MPFR version 3.1.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 660c5687a086ea3686f43ea5e642dd2c
[Bug c++/65513] New: gcc stops with "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513
Bug ID: 65513
Summary: gcc stops with "internal compiler error"
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
#include
class LogEntries
{
public:
charsDateTime [20];
std::atomic bReadyToFlush;
};
class LogThreads
{
public:
static LogEntries leLogEntries [10];
};
LogEntries LogThreads::leLogEntries [10] {};
Compiler options:
g++ -v -save-temps -std=c++11 gcc-warning-bug-2.cpp -Wall -Wextra -c -Werror
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
Output:
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2_source/configure --disable-multilib
Thread model: posix
gcc version 4.9.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra' '-c'
'-Werror' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -E -quiet -v
-D_GNU_SOURCE gcc-warning-bug-2.cpp -mtune=generic -march=x86-64 -std=c++11
-Wall -Wextra -Werror -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -fpch-preprocess -o gcc-warning-bug-2.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/backward
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
/usr/local/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra' '-c'
'-Werror' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -fpreprocessed
gcc-warning-bug-2.ii -quiet -dumpbase gcc-warning-bug-2.cpp -mtune=generic
-march=x86-64 -auxbase gcc-warning-bug-2 -Wall -Wextra -Werror -std=c++11
-version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o
gcc-warning-bug-2.s
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.2.3, MPFR version 3.1.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.2.3, MPFR version 3.1.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 660c5687a086ea3686f43ea5e642dd2c
gcc-warning-bug-2.cpp:16:43: error: missing initializer for member
‘LogEntries::sDateTime’ [-Werror=missing-field-initializers]
LogEntries LogThreads::leLogEntries [10] {};
^
gcc-warning-bug-2.cpp:16:43: error: missing initializer for member
‘LogEntries::bReadyToFlush’ [-Werror=missing-field-initializers]
gcc-warning-bug-2.cpp: In function ‘void
__static_initialization_and_destruction_0(int, int)’:
gcc-warning-bug-2.cpp:16:43: internal compiler error: in
gimplify_init_constructor, at gimplify.c:4007
0x7f7bc3 gimplify_init_constructor
../../gcc-4.9.2_source/gcc/gimplify.c:4007
0x7f879e gimplify_modify_expr_rhs
../../gcc-4.9.2_source/gcc/gimplify.c:4167
0x7f8874 gimplify_modify_expr
../../gcc-4.9.2_source/gcc/gimplify.c:4486
0x7fab57 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.2_source/gcc/gimplify.c:7627
0x7fc576 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-4.9.2_source/gcc/gimplify.c:5373
0x7fa40d gimplify_cleanup_point_expr
../../gcc-4.9.2_source/gcc/gimplify.c:5149
0x7fa40d gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.2_source/gcc/gimplify.c:7990
0x7fc576 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-4.9.2_source/gcc/gimplify.c:5373
0x7fb023 gimplify_statement_list
../../gcc-4.9.2_source/gcc/gimplify.c:1432
0x7fb023 gim
[Bug c++/65513] gcc stops with "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513
--- Comment #1 from Peter VARGA ---
One of these following steps do not produce any error message and the compiler
can finish successfully:
1) Add {} to the sDateTime member
2) Remove the std::atomic member
[Bug c++/65512] Inconsistent report of uninitialized members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512 --- Comment #3 from Peter VARGA --- 1) I had no idea how the importance is qualified. Is my 1st bug report. For me it was a blocker because I could not finish compiling 2) Not using -Werror is really a bit hard - don't you think?! My workaround is using the -Wno-missing-field-initializers switch 3) What about 4.9.3 - I cannot use 5.0 once released.
[Bug c++/65512] Inconsistent report of uninitialized members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512 --- Comment #5 from Peter VARGA --- 1) There are bugs which are not important. It is always a point of view. As a starter here I had 2 possibilities and I took the wrong. More or less you may be right but it was a simple misunderstanding. AND I did NOT think the bug is important because I have already a solution. It was blocker for me because compiler could not finish. 2) :-) - I am used my sources do compile on a very high restrict level. 3) What about 4.9.3 - is it fixed or not?
[Bug c++/65512] Inconsistent report of uninitialized members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512 --- Comment #7 from Peter VARGA --- Due the fact some frameworks do NOT support gcc 5.0 yet I would like to know if this bug is going to be fixed in a 4.9.X version or not.
[Bug c++/65692] New: Repeating error for each array entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65692
Bug ID: 65692
Summary: Repeating error for each array entry
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
#include
typedef struct
{
boolbValid;
charsDateTime [20];
std::atomic bReadyToFlush;
} LogEntries;
typedef struct
{
LogEntries leLogEntries [1] {};
} LogThreads;
Compiled with: gcc t.cpp -c -std=c++11 -Wall -Werror -Wextra
gcc displayes 3! error messages - 3 for each array entry. Even -Werror is
set the -fmax-errors option does not work in this case [may be this is on
purpose because the error is basing on a warning].
The above example is reported here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512 as fixed in 5.0 and is NOT
the subject of this post --> The repeating error message can be reviewed.
[Bug middle-end/59812] Missing aggressive loop optimization warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812
Peter VARGA changed:
What|Removed |Added
CC||developm...@faf-ltd.com
--- Comment #4 from Peter VARGA ---
Good, but why does not produce this test case any warning:
#include
#include
using namespace std;
int main() {
complex delta;
complex mc[4] = {0};
for(int di = 0; di < 4; di++, delta = mc[di]) {
cout << "di:" << di << " delta:" << delta << endl;
}
return 0;
}
it is an endless loop. According this threads
http://stackoverflow.com/questions/32506643/c-compilation-bug ,
http://blog.regehr.org/archives/918 I understand it was fixed.
[Bug bootstrap/43714] missing check for zlib.h, fails to build lto-compress.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43714 Peter VARGA changed: What|Removed |Added CC||developm...@faf-ltd.com --- Comment #3 from Peter VARGA --- But is this really that big deal to check it in configure? There are checked so many conditions and a missing zlib.h causes the compilation to fail.
