[Bug libstdc++/90770] Building with --enable-libstdcxx-debug and make profiledbootstrap fails with mv: cannot stat 'Makefile': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90770 --- Comment #5 from Tadeus Prastowo --- Created attachment 46466 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46466=edit Complete terminal output during the non-parallel build after applying the patchset I confirm that your patchset solves the build problem. Specifically, applying your patchset to the release tarball of GCC 9.1.0 (see https://gcc.gnu.org/ml/gcc/2019-05/msg00024.html) fails for the `ChangeLog' and `configure'. Nevertheless, the build is successful since I think the changes to those two files are not essential. Attached is the complete terminal output during the successful non-parallel build after successfully applying your patchset for the files `Makefile.am' and `Makefile.in'.
[Bug libstdc++/90770] New: Building with --enable-libstdcxx-debug and make profiledbootstrap fails with mv: cannot stat 'Makefile': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90770 Bug ID: 90770 Summary: Building with --enable-libstdcxx-debug and make profiledbootstrap fails with mv: cannot stat 'Makefile': No such file or directory Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tadeus.prastowo at unitn dot it Target Milestone: --- Created attachment 46456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46456=edit Complete terminal output during the non-parallel build This issue is initially reported in gcc-help (see https://gcc.gnu.org/ml/gcc-help/2019-05/msg00137.html) and has been confirmed by one other person (see https://gcc.gnu.org/ml/gcc-help/2019-06/msg00014.html). The issue is reproducible by unpacking the release tarball of GCC 9.1.0 (see https://gcc.gnu.org/ml/gcc/2019-05/msg00024.html) and then building it by configuring using configure switch `--enable-libstdcxx-debug' (e.g., ../gcc-9/configure --prefix=$HOME/gcc-9 --enable-languages=c,c++ --enable-libstdcxx-debug --disable-multilib) and making using `make profiledbootstrap'. The build will fail with the following message (the complete terminal output during the non-parallel build is attached; feel free to request additional log files) whose solution is described at the end: libtool: link: x86_64-linux-gnu-ranlib .libs/libstdc++convenience.a libtool: link: rm -fr .libs/libstdc++convenience.lax .libs/libstdc++convenience.lax libtool: link: ( cd ".libs" && rm -f "libstdc++convenience.la" && ln -s "../libstdc++convenience.la" "libstdc++convenience.la" ) if test ! -d /home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug; then \ mkdir -p /home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug; \ for d in c++98 c++11 c++17 filesystem; do mkdir -p /home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug/$d; done; \ (cd /home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug; \ sed -e 's/top_builddir = \.\./top_builddir = ..\/../' \ -e 's/top_build_prefix = \.\./top_build_prefix = ..\/../' \ -e 's/srcdir = \.\./srcdir = ..\/../' \ -e 's/VPATH = \.\./VPATH = ..\/../' \ -e 's/glibcxx_basedir = \.\./glibcxx_basedir = ..\/../' \ -e 's/MKDIR_P = \.\./MKDIR_P = ..\/../' \ < ../Makefile > Makefile ; \ for d in . c++98 c++11 c++17 filesystem; do \ sed -e 's/top_builddir = \.\./top_builddir = ..\/../' \ -e 's/top_build_prefix = \.\./top_build_prefix = ..\/../' \ -e 's/srcdir = \.\./srcdir = ..\/../' \ -e 's/VPATH = \.\./VPATH = ..\/../' \ -e 's/glibcxx_basedir = \.\./glibcxx_basedir = ..\/../' \ -e 's/MKDIR_P = \.\./MKDIR_P = ..\/../' \ < ../$d/Makefile > $d/Makefile ; \ done) ; \ fi; \ echo `date` > stamp-debug; (cd /home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug; \ mv Makefile Makefile.tmp; \ sed -e 's,all-local: all-once,all-local:,' \ -e 's,install-data-local: install-data-once,install-data-local:,' \ -e '/vpath/!s,src/c,src/debug/c,' \ < Makefile.tmp > Makefile ; \ rm -f Makefile.tmp ; \ make CXXFLAGS='-gdwarf-4 -g3 -O0 -D_GLIBCXX_ASSERTIONS' \ toolexeclibdir=/home/eus/gcc-9/lib/../lib64/debug all) ; mv: cannot stat 'Makefile': No such file or directory /bin/bash: line 2: Makefile.tmp: No such file or directory make[7]: Entering directory '/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug' make[7]: *** No rule to make target 'all'. Stop. make[7]: Leaving directory '/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug' Makefile:1074: recipe for target 'build-debug' failed make[6]: *** [build-debug] Error 2 make[6]: Leaving directory '/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src' Makefile:730: recipe for target 'all-recursive' failed make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory '/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src' Makefile:562: recipe for target 'all-recursive' failed make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory '/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3' Makefile:487: recipe for target 'all' failed make[3]: *** [all] Error 2 make[3]: Leaving directory '/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3' Makefile:15380: recipe for target 'all-stagefeedback-target-libstdc++-v3' failed make[2]: *** [all-stagefeedback-target-libstdc++-v3] Error 2 make[2]: Leaving directory '/home/eus/buildzone/gcc-9-build' Makefile:22998: recipe for target 'stagefeedback-bubble' failed make[1]: *** [stagefeedback-bubble] Error 2 make[1]: Leaving directory '/home/eus/buildzone/gcc-9-build' Makefile:23017: recipe for ta
[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741 --- Comment #10 from Tadeus Prastowo --- Okay, I see it now. Thank you very much, Jakub, for your clear explanation.
[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741
Tadeus Prastowo changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #7 from Tadeus Prastowo ---
The code in question, which is simplified below to match the real use-case,
does not involve template specialization, and so, the quoted passage does not
apply:
-- 8< ---
template
struct X {
static_assert(sizeof(decltype(x)) == 200, "1");
};
-- 8< ---
The said code compiles fine with other GCC and Clang versions mentioned in the
initial report.
The code above has the merit of not requiring the specification of a
redundant/dummy template argument just to fire the static assertion.
[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741 --- Comment #4 from Tadeus Prastowo --- My use-case is to use the instantiation of `struct X' to fire the static assert.
[Bug c++/89741] New: [Regression] static_assert fires when template not instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741
Bug ID: 89741
Summary: [Regression] static_assert fires when template not
instantiated
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tadeus.prastowo at unitn dot it
Target Milestone: ---
Consider the following MWE:
-- 8<
template
struct Y {
static constexpr bool value = false;
};
template<>
struct Y {
static constexpr bool value = true;
};
template
struct X {
static_assert(Y::value, "1");
};
int main() {
}
-- 8<
Compiling it with GCC 8.3, GCC 7.4, GCC 6.3, GCC 5.5, GCC 4.9.4, Clang 6.0, and
Clang 7.0 gives no error (see https://www.godbolt.org/z/t8Dkw7).
Compiling it with GCC 9.0 (trunk) gives an error.
[Bug c++/89553] New: "static const double x = 2" is treated equivalent to "static constexpr double x = 2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89553
Bug ID: 89553
Summary: "static const double x = 2" is treated equivalent to
"static constexpr double x = 2"
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tadeus.prastowo at unitn dot it
Target Milestone: ---
For the following example, requesting a strict compliance to C++17 using
"-std=c++17 -pedantic-errors", Clang rejects but GCC accepts
(https://www.godbolt.org/z/RDRdE5):
template
struct X {
static constexpr double value = *x * 2;
};
static const double x = 2;
static_assert(X<>::value > 2);
According to the discussion at the C++ standard discussion forum (see
https://groups.google.com/a/isocpp.org/d/topic/std-discussion/i9eAYNDCr8U), GCC
behavior is wrong because C++17 standard (the draft available at
http://www.open-std.org/JTC1/SC22/WG21/docs/standards.html) says that "static
const double x = 2" cannot be treated as being equivalent to "static constexpr
double x = 2" due to the use of lvalue-to-rvalue conversion that hits the
following stipulation in [expr.const]p2,2.7,2.7.1 (page 139 of the draft):
-- 8< -
An expression e is a core constant expression unless the evaluation of e,
following the rules of the abstract machine (4.6), would evaluate one of the
following expressions:
— an lvalue-to-rvalue conversion (7.1) unless it is applied to
— a non-volatile glvalue of integral or enumeration type that refers to a
complete non-volatile const object with a preceding initialization, initialized
with a constant expression
-- 8< -
Specifically, "static const double x = 2" is not "a non-volatile glvalue of
integral or enumeration type that refers to a complete non-volatile const
object with a preceding initialization, initialized with a constant expression"
due to the type "double".
[Bug c++/89074] New: valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074
Bug ID: 89074
Summary: valid pointer equality constexpr comparison rejected
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tadeus.prastowo at unitn dot it
Target Milestone: ---
struct A {
static constexpr int v {1};
};
struct B {
static constexpr int v {1};
};
static_assert(::v == ::v, "1");
static_assert(::v != ::v, "2");
According to http://eel.is/c++draft/expr.eq#3.3, the second static_assert
should be successful. But, while clang, icc, and msvc accept, gcc version
9.0.0 20190113 fails to even raise the assertion with the following message
(https://www.godbolt.org/z/UtjS8v):
/tmp/x.cpp:10:21: error: non-constant condition for static assertion
10 | static_assert(::v != ::v, "2");
| ~~^~~~
/tmp/x.cpp:10:21: error: ‘((& A::v) != (& B::v))’ is not a constant expression
[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57891
--- Comment #9 from Tadeus Prastowo ---
This problem still exists in the trunk (cf. https://godbolt.org/g/bRf18i).
Clang correctly keeps rejecting it (cf. https://godbolt.org/g/egcNtV). Both
use the following MWE:
template
struct X {
static constexpr unsigned data {a};
};
int main() {
return X<-1>::data;
}
[Bug c++/86823] New: [6/7/8/9 Regression] private member template struct/class is publicly accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86823
Bug ID: 86823
Summary: [6/7/8/9 Regression] private member template
struct/class is publicly accessible
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tadeus.prastowo at unitn dot it
Target Milestone: ---
The following MWE is correctly rejected by GCC version <= 5.5 (cf.
https://godbolt.org/g/Me9i13 (5.5) and https://godbolt.org/g/E7TMAj (4.5.3))
and clang (cf. https://godbolt.org/g/osAZMo (6.0.0)), but incorrectly accepted
by GCC version >= 6.1 (cf. https://godbolt.org/g/nWUuEY (6.1),
https://godbolt.org/g/VmmhY2 (8.2), and https://godbolt.org/g/gwwuG6 (trunk))
struct X {
private:
template // comment this out, and GCC >= 6.1 correctly rejects.
struct Y {
int data;
};
public:
int value;
};
int main() {
typename X::Y
// comment this out, and GCC >= 6.1 correctly rejects.
a;
}
[Bug c++/86608] New: volatile variable is taken as a constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86608
Bug ID: 86608
Summary: volatile variable is taken as a constexpr
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tadeus.prastowo at unitn dot it
Target Milestone: ---
The following program is ill-formed based on
http://eel.is/c++draft/temp.arg.nontype (#1 and #2) and
http://eel.is/c++draft/expr.const#2.7. However,
GCC 8.1 compiles fine (https://godbolt.org/g/o8UPiJ)
as well as any GCC >= 6.1 available in godbolt, but
clang-6.0 (https://godbolt.org/g/HUQXUM) and
GCC 5.5 (https://godbolt.org/g/MQRCdE) as well as
any GCC older than 5.5 but >= 4.9.0 correctly reject
the program.
template struct X {};
int main() {
static constexpr volatile int a = 3;
constexpr volatile int b = 2;
return (sizeof(X) + sizeof(X));
}
So, GCC >= 6.1 should be fixed to reject the program.
[Bug c++/86607] New: constexpr function does not treat function pointers with external linkage as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86607
Bug ID: 86607
Summary: constexpr function does not treat function pointers
with external linkage as constexpr
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tadeus.prastowo at unitn dot it
Target Milestone: ---
Using http://godbolt.org, I see that the following program compiles in
any clang version that supports `-std=c++14' switch (>= 3.5) but fails
in any GCC version >= 5.1 while compiles in any GCC version <= 4.9.4
that supports `-std=c++14' switch (>= 4.8.5):
template
struct carrier {
static constexpr T value = v;
};
template
inline constexpr bool nontype_nontemplate_args_eq(T arg1, T arg2) {
return arg1 == arg2;
}
template
inline constexpr bool nontype_nontemplate_args_eq(T1, T2) {
return false;
}
int fn1() {
return 2;
}
int fn2() {
return 17;
}
int main() {
return carrier::value;
}
Any GCC version >= 5.1 should compile the program because `' and `' as
the arguments of constexpr function `nontype_nontemplate_args_eq' are constexpr
according to the C++ standard http://eel.is/c++draft/expr.const#6.2.
[Bug c++/84464] Pack expansion in mem-initializer-list with expression-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84464 Tadeus Prastowo changed: What|Removed |Added Version|7.3.0 |8.1.0 --- Comment #1 from Tadeus Prastowo --- The bug still exists in GCC 8.1.0 (cf. https://godbolt.org/g/GPci7c).
[Bug c++/84464] New: Pack expansion in mem-initializer-list with expression-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84464
Bug ID: 84464
Summary: Pack expansion in mem-initializer-list with
expression-list
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tadeus.prastowo at unitn dot it
Target Milestone: ---
I am referring to C++14 standard
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf) for the
following problem. Section 12.6.2 "Initializing bases and members" paragraph 1
says that mem-initializer can either be mem-initializer-id(expression-list_opt)
or mem-initializer-id braced-init-list, and mem-initializer... is a valid
construct. But, GCC rejects the first alternative of the valid construct but
accepts the second alternative of the valid construct as demonstrated by the
following program. Since both alternatives are valid constructs, GCC shall
accept the first alternative as well.
GCC cannot compile the following program (cf. https://godbolt.org/g/QWj5Q3),
but Clang can (cf. https://godbolt.org/g/jA7Z8H). I use flag `-std=c++14'.
#include
struct C1 {
bool a;
float b;
C1(bool x, float y) : a(x), b(y) {}
};
struct C2 {
bool c;
float d;
C2(bool x, float y) : c(x), d(y) {}
};
struct C3 {
bool e;
float f;
C3(bool x, float y) : e(x), f(y) {}
};
template
struct A : public baseclasses...
{
template A(Ts... args) : baseclasses(args...)... {
// This uses mem-initializer-id(expression-list_opt).
// Section 5.2 par 1 says that expression-list is initializer-list.
// Section 8.5 par 1 says that initializer-list can be
// initializer-clause... with initializer-clause being
// assignment-expression.
// Section 5.17 par 1 says that assignment-expression can boil down
// to an identifier, for example, args.
// So, the construct is valid as far as I can see. But,
// g++ 5.4.1 fails with: invalid use of pack expansion expression.
// g++ 7.3.0 fails with: no matching function for call to
// ‘C1::C1(bool)’.
// The fix is to use mem-initializer-id braced-init-list as in:
// : baseclasses{args...}...
}
};
int main() {
A<C1, C2, C3> a(true, 1.0F);
std::printf("%d %f %d %f %d %f\n", a.a, a.b, a.c, a.d, a.e, a.f);
}
