[Bug c++/90617] New: GCC 9 miscompiles Qt4 "foreach" macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90617
Bug ID: 90617
Summary: GCC 9 miscompiles Qt4 "foreach" macro
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bastian.beisc...@rwth-aachen.de
Target Milestone: ---
Created attachment 46410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46410=edit
preprocessed qt4.C source.
The following piece of code, which uses Qt 4.8.7:
#include
#include
int main(int argc, char** argv) {
QList list;
list.append(1);
list.append(2);
list.append(3);
foreach(int x, list) {
std::cout << x << std::endl;
}
return 0;
}
Compiled with gcc 9.1.0 like this:
$ g++ -I/usr/include/qt4 -I/usr/include/qt4/QtCore -lQtCore -o qt4 qt4.C
does not execute the "foreach" loop correctly.
$ ./qt4
1
Only the first list element is printed. This is a regression with respect to
GCC 8.3.0:
$ g++-8 -I/usr/include/qt4 -I/usr/include/qt4/QtCore -lQtCore -o qt4 qt4.C
$ ./qt4
1
2
3
The preprocessed sources of qt4.C are attached as 'qt4.i'.
I managed to construct a reproducer (based on the Qt foreach macro) which is
short and does not use Qt:
#include
#include
template
class ForeachContainer {
public:
inline ForeachContainer(const T& t)
: c(t)
, brk(0)
, i(c.begin())
, e(c.end()) {
}
const T c;
int brk;
typename T::const_iterator i, e;
};
int main() {
std::vector v;
v.push_back(0);
v.push_back(1);
v.push_back(2);
for (ForeachContainer> _container_(v);
!_container_.brk && _container_.i != _container_.e;
__extension__ ({ ++_container_.brk; ++_container_.i; })) {
for (int x = *_container_.i;
;
__extension__ ({--_container_.brk; break;})) {
std::cout << "x = " << x << std::endl;
}
}
return 0;
}
$ g++ -g -o mini9 mini.C
$ ./mini9
x = 0
$ g++-8 -g -o mini8 mini.C
$ ./mini8
x = 0
x = 1
x = 2
Admittedly, the code is ugly, but that's what is in Qt 4.8.7.
[Bug c/80919] New: [7 Regression] ICE: Segmentation fault with -Wall when printing address of size 0 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80919
Bug ID: 80919
Summary: [7 Regression] ICE: Segmentation fault with -Wall when
printing address of size 0 array
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bastian.beisc...@rwth-aachen.de
Target Milestone: ---
Hey,
the following code causes a GCC segmentation fault when compiled with -Wall:
#include
void conftest(void)
{
int gid[0];
printf("%x\n", );
}
Compiler output:
$ gcc -Wall -c -o conftest.o conftest.c
conftest.c: In function ‘conftest’:
conftest.c:6:3: internal compiler error: Segmentation fault
printf("%x\n", );
^~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
Cheers
Bastian
[Bug libstdc++/69699] libstdc++ ABI documentation is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699 --- Comment #3 from bastian.beisc...@rwth-aachen.de --- Jonathan, maybe so but it should be mentioned on the page nevertheless, right? My issue is that we are using (as an example): #if (defined(__GLIBCXX__) && __GLIBCXX__ > 20150626) || (defined(_LIBCPP_VERSION) && _LIBCPP_VERSION >= 1101) static_assert(std::is_trivially_constructible::value, "MyClass should be trivially constructible."); #endif since "std_is_trivially_constructible" exists only in libstdc++ shipped with GCC 5.1.0+, but not in libstdc++ shipped with GCC 4.9.3, for example. If i understand your comment correctly you are saying that, if GCC 4.9.4 were released, it would include a version of libstdc++ with __GLIBCXX__ > today, so it would pass the above check, but still there would't be any "std_is_trivially_constructible". But how else can I do the check then?! Using __GNUC__ / __GNUC_MINOR__ is not going to work because we have people using other compilers (clang, Intel compiler) which use libstdc++ shipped with GCC but do not define __GNUC__ / __GNUC_MINOR__.
[Bug libstdc++/69699] libstdc++ ABI documentation is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699 --- Comment #5 from bastian.beisc...@rwth-aachen.de --- Thanks for your comments. Does this mean that such a macro does not exist at the present time?
[Bug libstdc++/69699] New: libstdc++ ABI documentation is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699 Bug ID: 69699 Summary: libstdc++ ABI documentation is out of date Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bastian.beisc...@rwth-aachen.de Target Milestone: --- The page https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html is out of date, specifically section 7 of the history. This section is often very useful when checks on the '__GLIBCXX__' macro need to be implemented. All the releases since GCC 4.8 are missing. For example, GCC 5.3.0 has __GLIBCXX__ 20151204 but it's not mentioned on the page. It is possible that other changes are also missing, but I'm not sure.
[Bug libstdc++/69699] libstdc++ ABI documentation is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699
--- Comment #1 from bastian.beisc...@rwth-aachen.de ---
This is a list of all the missing values of the __GLIBCXX__ macro
4.7.3 20130411
4.7.4 20140612
4.8.0 20130322
4.8.1 20130531
4.8.2 20131016
4.8.3 20140522
4.8.4 20141219
4.8.5 20150623
4.9.0 20140422
4.9.1 20140716
4.9.2 20141030
4.9.3 20150626
5.1.0 20150422
5.2.0 20150716
5.3.0 20151204
obtained with the following zsh script:
#!/usr/bin/env zsh
VERSIONS=( 4.7.3
4.7.4
4.8.0
4.8.1
4.8.2
4.8.3
4.8.4
4.8.5
4.9.0
4.9.1
4.9.2
4.9.3
5.1.0
5.2.0
5.3.0 )
rm -f allversions.txt
for v in ${VERSIONS}; do
wget
ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-${v}/gcc-${v}.tar.bz2
tar xjvf gcc-${v}.tar.bz2 --wildcards "gcc-${v}/gcc/DATESTAMP"
version=$(cat gcc-${v}/gcc/DATESTAMP)
echo ${v} ${version} >> allversions.txt
rm -fr gcc-${v}*
done
[Bug libstdc++/65899] New: std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65899
Bug ID: 65899
Summary: std::basic_stringbuf member __xfer_bufptrs should be
explicitly declared private
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bastian.beisc...@rwth-aachen.de
Target Milestone: ---
I'm trying to compile code with GCC 5.1.0 which makes use of the good ole:
#define private public
hack (for some reason). I know, I know, but it's not my code and I'd like it to
compile out of the box...
Now the issue is this: In GCC 5.1.0's version of the sstream header one finds
the following:
templatetypename _CharT, typename _Traits, typename _Alloc
class basic_stringbuf : public basic_streambuf_CharT, _Traits
{
struct __xfer_bufptrs;
public:
// Types:
typedef _CharTchar_type;
typedef _Traits traits_type;
[...]
private:
[...]
struct __xfer_bufptrs
{
[...]
The problem is that the member __xfer_bufptrs is implicitly private when it's
declared but then later it's expliclity marked private.
Then, due to the #define private public, the second one turns public but the
first one does not and there's a conflict leading to this error:
/usr/include/c++/5.1.0/sstream:335:7: error: ‘struct
std::basic_stringbuf_CharT, _Traits, _Alloc::__xfer_bufptrs’ redeclared with
different access
struct __xfer_bufptrs
^
Any chance to mark the first instance private explicitly?
