[Bug libstdc++/108221] New: Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221 Bug ID: 108221 Summary: Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jdx at o2 dot pl Target Milestone: --- Host: x86_64-w64-mingw32 Target: h8300-elf Build: x86_64-w64-mingw32 I get following message when I try to build master (339db340): Making all in c++20 make[5]: Entering directory '/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/src/c++20' /bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile /d/Works/xcomp/gcc-build/./gcc/xgcc -shared-libgcc -B/d/Works/xcomp/gcc-build/./gcc -nostdinc++ -L/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/src -L/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/src/.libs -L/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/libsupc++/.libs -B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem /usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -I/d/Works/gcc/libstdc++-v3/../libgcc -I/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/h8300-elf -I/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include -I/d/Works/gcc/libstdc++-v3/libsupc++ -std=gnu++20 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=tzdb.lo -fimplicit-templates -isystem /d/Works/xcomp/sysroot/h8300-elf/include -c -o tzdb.lo ../../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc libtool: compile: /d/Works/xcomp/gcc-build/./gcc/xgcc -shared-libgcc -B/d/Works/xcomp/gcc-build/./gcc -nostdinc++ -L/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/src -L/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/src/.libs -L/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/libsupc++/.libs -B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem /usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -I/d/Works/gcc/libstdc++-v3/../libgcc -I/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/h8300-elf -I/d/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include -I/d/Works/gcc/libstdc++-v3/libsupc++ -std=gnu++20 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=tzdb.lo -fimplicit-templates -isystem /d/Works/xcomp/sysroot/h8300-elf/include -c ../../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc -o tzdb.o In file included from D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/bits/chrono_io.h:39, from D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/chrono:3321, from d:\works\gcc\libstdc++-v3\src\c++20\tzdb.cc:28: D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/format: In instantiation of 'std::__format::_Formatting_scanner, wchar_t>::_M_format_arg(std::size_t):: [with auto:42 = float]': D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/format:3038:44: required from 'decltype(auto) std::basic_format_arg<_Context>::_M_visit(_Visitor&&, std::__format::_Arg_t) [with _Visitor = std::__format::_Formatting_scanner, wchar_t>::_M_format_arg(std::size_t)::; _Context = std::basic_format_context, wchar_t>]' D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/format:3082:28: required from 'decltype(auto) std::visit_format_arg(_Visitor&&, basic_format_arg<_Context>) [with _Visitor = __format::_Formatting_scanner<__format::_Sink_iter, wchar_t>::_M_format_arg(std::size_t)::; _Context = basic_format_context<__format::_Sink_iter, wchar_t>]' D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/format:3533:23: required from 'void std::__format::_Formatting_scanner<_Out, _CharT>::_M_format_arg(std::size_t) [with _Out = std::__format::_Sink_iter; _CharT = wchar_t; std::size_t = long unsigned int]' D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/format:3528:7: required from here D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/format:3547:37: error: static assertion failed 3547 | static_assert(__format::__formattable_with<_Type, _Context>); | ~~^~~ D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/format:3547:37: note: constraints not satisfied In file included from D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/bits/chrono.h:43, from D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/chrono:41: D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/concepts:152:13: required for the satisfaction of 'constructible_from<_Tp, _Tp>' [with _Tp = std::formatter] D:/Works/xcomp/gcc-build/h8300-elf/libstdc++-v3/include/concepts:166:13: required for the satisfacti
[Bug libstdc++/108222] New: windows 9x support for libstdc++ threads and probably other character types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108222 Bug ID: 108222 Summary: windows 9x support for libstdc++ threads and probably other character types Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- windows 9x needs to call A apis CreateFileA not CreateFileW for example CreateSemaphoreA not CreateSemaphoreW for example 9x for A and NT for W. https://github.com/gcc-mirror/gcc/blob/dcf8fe1eeab668a4d24bcc4baa3ad185dbf1b5e0/libgcc/config/i386/gthr-win32.c#L196 Like this should call A apis when -D_WIN32_WINDOWS is defined.
[Bug libstdc++/108222] windows 9x support for libstdc++ threads and probably other features like std::filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108222 --- Comment #1 from cqwrteur --- I think we also need flags like --with-default-win32-windows=0x0400 to tell GCC we are building for windows 95
[Bug c++/108223] New: GCC reject QNaN in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108223
Bug ID: 108223
Summary: GCC reject QNaN in constant expressions
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nikolasklauser at berlin dot de
Target Milestone: ---
GCC rejects the following code with "error: '__builtin_fmax(+QNaN, +QNaN)' is
not a constant expression" even though it's perfectly defined behaviour.
test code (Godbolt: https://godbolt.org/z/1hfxM9PEW):
constexpr bool test() {
auto val = __builtin_fmax(__builtin_nan(""), __builtin_nan(""));
return true;
}
static_assert(test());
[Bug c++/108223] GCC rejects QNaN in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108223 --- Comment #1 from Andrew Pinski --- __builtin_fmax does not have to be a constant expression as it is an extension ...
[Bug c++/108223] GCC rejects QNaN in __builtin_fmax constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108223
--- Comment #2 from Andrew Pinski ---
That being said this works:
#include
constexpr bool test() {
auto val = std::max(__builtin_nan(""), __builtin_nan(""));
return true;
}
static_assert(test());
[Bug libstdc++/108222] windows 9x support for libstdc++ threads and probably other features like std::filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108222 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski --- windows 9x support is not going to happen.
[Bug c++/108223] GCC rejects QNaN in __builtin_fmax constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108223 --- Comment #3 from Nikolas Klauser --- It doesn't have to work, but it works for some inputs, so I would expect that it works for all. https://godbolt.org/z/KsrjEP77c
[Bug libstdc++/108222] windows 9x support for libstdc++ threads and probably other features like std::filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108222 cqwrteur changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|UNCONFIRMED --- Comment #3 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > windows 9x support is not going to happen. But neither you should fail that support either.
[Bug libstdc++/108222] windows 9x support for libstdc++ threads and probably other features like std::filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108222 --- Comment #4 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > windows 9x support is not going to happen. You should not break windows 9x either.
[Bug c/108224] New: Suggest stdlib.h header for rand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224 Bug ID: 108224 Summary: Suggest stdlib.h header for rand Product: gcc Version: 12.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Would be great if the suggestions could suggest for rand() Same in C and C++
[Bug c/108224] Suggest stdlib.h header for rand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c/108224] Suggest stdlib.h header for rand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-12-25
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed.
Simple testcase:
int f(void)
{
return rand();
}
[Bug c/108224] Suggest stdlib.h header for rand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224
--- Comment #2 from Andrew Pinski ---
diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index 9c256173b82..dd4c23e5923 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -171,6 +171,8 @@ get_stdlib_header_for_name (const char *name, enum stdlib
lib)
{"getenv", {"", ""} },
{"malloc", {"", ""} },
{"realloc", {"", ""} },
+{"rand", {"", ""} },
+{"srand", {"", ""} },
/* and . */
{"memchr", {"", ""} },
Should be enough for both C and C++.
[Bug c/108224] Suggest stdlib.h header for rand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224
--- Comment #3 from Jonny Grant ---
Great! I just saw it is the same for random(), srandom(), initstate(),
setstate()
Is there an easy way to add them all based on the C API to save opening
separate tickets?
I added those :
>From 6ff344979af46dbcd739dd9068d6d595547e4c27 Mon Sep 17 00:00:00 2001
From: Jonathan Grant
Date: Sun, 25 Dec 2022 22:38:44 +
Subject: [PATCH] add srandom random initstate setstate
---
gcc/c-family/known-headers.cc | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index 9c256173b82..ade9fa2dcc0 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -171,6 +171,10 @@ get_stdlib_header_for_name (const char *name, enum stdlib
lib)
{"getenv", {"", ""} },
{"malloc", {"", ""} },
{"realloc", {"", ""} },
+{"random", {"", ""} },
+{"srandom", {"", ""} },
+{"initstate", {"", ""} },
+{"setstate", {"", ""} },
/* and . */
{"memchr", {"", ""} },
--
2.37.2
[Bug libstdc++/108225] New: cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 Bug ID: 108225 Summary: cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- /home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:151:7: error: '__gthread_cond_init_function' was not declared in this scope; did you mean '__gthread_mutex_init_functio '? 151 | __GTHREAD_COND_INIT_FUNCTION(&_M_cond); | ^~~~ /home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h In destructor 'std::__condvar::~__condvar()': /home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:157:69: error: '_M_cond' was not declared in this scope 157 | int __e __attribute__((__unused__)) = __gthread_cond_destroy(&_M_cond); | ^~~ /home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:157:45: error: '__gthread_cond_destroy' was not declared in this scope; did you mean '__gthread_mutex_destroy'? 157 | int __e __attribute__((__unused__)) = __gthread_cond_destroy(&_M_cond); | ^~ | __gthread_mutex_destroy
[Bug tree-optimization/108226] New: __restrict on inlined function parameters does not function as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108226
Bug ID: 108226
Summary: __restrict on inlined function parameters does not
function as expected
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jhaberman at gmail dot com
Target Milestone: ---
In bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58526 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60712#c3 it is said that
restrict/__restrict on inlined function parameters was fixed in GCC 5. But I
ran into a case where __restrict does not work as expected:
// Godbolt link for this example: https://godbolt.org/z/e5j93Ex3v
long g;
static void Func1(void* p1, int* p2) {
switch (*p2) {
case 2:
__builtin_memcpy(p1, &g, 1);
return;
case 1:
__builtin_memcpy(p1, &g, 8);
return;
case 0: {
__builtin_memcpy(p1, &g, 16);
return;
}
}
}
static void Func2(char* __restrict p1, int* __restrict p2) {
*p2 = 1;
*p1 = 123;
Func1(p1, p2);
}
void Func3(char* p1, int* p2) {
*p2 = 1;
Func2(p1, p2);
}
The __restrict qualifiers on Func2() should allow the switch() should be
optimized away. Clang optimizes it, GCC does not.
It appears that __restrict on function parameters can even make the code worse.
Consider a slight variation on this example:
// Godbolt link for this example: https://godbolt.org/z/Y61qajETd
long g;
static void Func1(void* p1, int* p2) {
switch (*p2) {
case 2:
__builtin_memcpy(p1, &g, 1);
return;
case 1:
__builtin_memcpy(p1, &g, 8);
return;
case 0: {
__builtin_memcpy(p1, &g, 16);
return;
}
}
}
// If we remove __restrict here, GCC succeeds in optimizing away the switch().
static void Func2(char* __restrict p1, int* __restrict p2) {
*p1 = 123;
*p2 = 1;
Func1(p1, p2);
}
void Func3(char* p1, int* p2) {
*p2 = 1;
Func2(p1, p2);
}
In this case, it should be straightforward to optimize away the switch(), even
without __restrict. But GCC does not optimize this correctly unless we
*remove* __restrict.
[Bug target/36821] Flush denormals to Zero Flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36821 --- Comment #6 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:e54375d85d4aa5889869c2672158083b2106b623 commit r13-4891-ge54375d85d4aa5889869c2672158083b2106b623 Author: liuhongt Date: Mon Dec 12 15:43:58 2022 +0800 x86: Add a new option -mdaz-ftz to enable FTZ and DAZ flags in MXCSR. if (mdaz-ftz) link crtfastmath.o else if ((Ofast || ffast-math || funsafe-math-optimizations) && !shared && !mno-daz-ftz) link crtfastmath.o else Don't link crtfastmath.o gcc/ChangeLog: PR target/55522 PR target/36821 * config/i386/gnu-user-common.h (GNU_USER_TARGET_MATHFILE_SPEC): Link crtfastmath.o whenever -mdaz-ftz is specified. Don't link crtfastmath.o when -share or -mno-daz-ftz is specified. * config/i386/i386.opt (mdaz-ftz): New option. * doc/invoke.texi (x86 options): Document mftz-daz.
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 --- Comment #31 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:e54375d85d4aa5889869c2672158083b2106b623 commit r13-4891-ge54375d85d4aa5889869c2672158083b2106b623 Author: liuhongt Date: Mon Dec 12 15:43:58 2022 +0800 x86: Add a new option -mdaz-ftz to enable FTZ and DAZ flags in MXCSR. if (mdaz-ftz) link crtfastmath.o else if ((Ofast || ffast-math || funsafe-math-optimizations) && !shared && !mno-daz-ftz) link crtfastmath.o else Don't link crtfastmath.o gcc/ChangeLog: PR target/55522 PR target/36821 * config/i386/gnu-user-common.h (GNU_USER_TARGET_MATHFILE_SPEC): Link crtfastmath.o whenever -mdaz-ftz is specified. Don't link crtfastmath.o when -share or -mno-daz-ftz is specified. * config/i386/i386.opt (mdaz-ftz): New option. * doc/invoke.texi (x86 options): Document mftz-daz.
[Bug target/36821] Flush denormals to Zero Flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36821 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to CVS Commits from comment #6) > The master branch has been updated by hongtao Liu : > > https://gcc.gnu.org/g:e54375d85d4aa5889869c2672158083b2106b623 > > commit r13-4891-ge54375d85d4aa5889869c2672158083b2106b623 > Author: liuhongt > Date: Mon Dec 12 15:43:58 2022 +0800 > > x86: Add a new option -mdaz-ftz to enable FTZ and DAZ flags in MXCSR. > > if (mdaz-ftz) > link crtfastmath.o > else if ((Ofast || ffast-math || funsafe-math-optimizations) > && !shared && !mno-daz-ftz) > link crtfastmath.o > else > Don't link crtfastmath.o > > gcc/ChangeLog: > > PR target/55522 > PR target/36821 > * config/i386/gnu-user-common.h (GNU_USER_TARGET_MATHFILE_SPEC): > Link crtfastmath.o whenever -mdaz-ftz is specified. Don't link > crtfastmath.o when -share or -mno-daz-ftz is specified. > * config/i386/i386.opt (mdaz-ftz): New option. > * doc/invoke.texi (x86 options): Document mftz-daz. Does -mdaz-ftz actually activate all of -ffast-math and/or -funsafe-math-optimizations?
[Bug target/36821] Flush denormals to Zero Flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36821 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #8 from Hongtao.liu --- > Does -mdaz-ftz actually activate all of -ffast-math and/or > -funsafe-math-optimizations? No, -mdaz-ftz only set DAZ and FTZ bits.
[Bug c++/108169] class type template parameters are const in GCC (differs from other compilers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108169
mail at jhellings dot nl changed:
What|Removed |Added
CC||mail at jhellings dot nl
--- Comment #3 from mail at jhellings dot nl ---
I looked a bit further into this and into what the standard says. GCC seems to
derive the wrong type for non-type template parameters in a few cases both (1)
when they have a placeholder type such as auto and (2) when they use a normal
type. See https://jhellings.nl/article?articleid=1 for the full analysis.
My findings (summary):
Let V be a non-type template parameter. The C++20 standard defines decltype(V)
as follows (Clause 1 of Section [dcl.type.decltype]):
"For an expression E, the type denoted by decltype(E) is defined as follows:
... otherwise, if E is an unparenthesized id-expression naming a non-type
template-parameter, decltype(E) is the type of the template-parameter after
performing any necessary type deduction;"
In the above, the type of a template-parameter is defined as follows (Clause 6
of Section [temp.param]):
"A non-type template-parameter shall have one of the following (possibly
cv-qualified) types: ... The top-level cv-qualifiers on the template-parameter
are ignored when determining its type."
Hence, decltype(V) with V a non-type template parameter should never yield a
type with a top-level const qualifier.
In GCC 12 (x86-64 gcc 12.2 on Compiler Explorer), GCC does not follow this rule
in the following case: if the type of V is a structural class type T, then GCC
always yields a ``const T''.
See, for example, the following program _that does not use placeholder types_:
/*
* @author{Jelle Hellings}.
*/
#include
#include
#include
/*
* Format the type @{Type} and print it to standard output. The qualifiers
* @{qs...} are used to include further details on @{Type}.
*/
template
void type_printer(const auto&... qs)
{
if constexpr (std::is_lvalue_reference_v) {
return type_printer>(qs..., "&");
}
if constexpr (std::is_rvalue_reference_v) {
return type_printer>(qs..., "&&");
}
if constexpr (std::is_const_v) {
return type_printer>(qs..., "const");
}
if constexpr (std::is_volatile_v) {
return type_printer>(qs..., "volatile");
}
if constexpr (std::is_array_v) {
return type_printer>(qs..., "[]");
}
if constexpr (std::is_pointer_v) {
return type_printer>(qs..., "*");
}
((std::cout << qs << " "), ...);
std::cout << '`' << typeid(Type).name() << '`' << std::endl;
}
/*
* Print the details on the type @{Type}, the type of a non-type template
* parameter with value @{Value}, and on the type of expressions involving
* @{Value}. The printed data will be labeled with @{case_name}.
*/
template
void inspect_template_argument(const auto& case_name)
{
type_printer(case_name);
type_printer(case_name);
}
/*
* A dummy struct type.
*/
struct dummy {};
/*
* Entry-point of the program.
*/
int main()
{
/* We look at most combinations of types and values. */
inspect_template_argument("{int}");
inspect_template_argument("{c-int}");
inspect_template_argument("{dummy}");
inspect_template_argument("{c-dummy}");
}
The above program SHOULD return:
{int} `int`
{int} `int`
{c-int} const `int`
{c-int} `int`
{dummy} `5dummy`
{dummy} `5dummy`
{c-dummy} const `5dummy`
{c-dummy} `5dummy`
But, in x86-64 gcc 12.2 (on Compiler Explorer), it returns
{int} `i`
{int} `i`
{c-int} const `i`
{c-int} `i`
{dummy} `5dummy`
{dummy} const `5dummy` << WRONG to the best of my understanding
{c-dummy} const `5dummy`
{c-dummy} const `5dummy` << WRONG to the best of my understanding
Note that in x86-64 gcc 11.3 (on Compiler Explorer), the output was more-wrong,
as also the const-qualifier for non-class types was preserved in some cases.
Indeed, x86-64 gcc 11.3 (on Compiler Explorer) returns:
{int} `i`
{int} `i`
{c-int} const `i`
{c-int} const `i` << WRONG & FIXED to the best of my understanding
{dummy} `5dummy`
{dummy} const `5dummy`<< WRONG to the best of my understanding
{c-dummy} const `5dummy`
{c-dummy} const `5dummy` << WRONG to the best of my understanding
The issues detected above carry over to the usage of placeholder types, leading
to the bug reported in this bug report.
[Bug c++/108169] class type template parameters are const in GCC (differs from other compilers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108169 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100893 --- Comment #4 from Andrew Pinski --- (In reply to mail from comment #3)> > Note that in x86-64 gcc 11.3 (on Compiler Explorer), the output was > more-wrong, as also the const-qualifier for non-class types was preserved in > some cases. Indeed, x86-64 gcc 11.3 (on Compiler Explorer) returns: So that was PR 100893 .
[Bug c++/108169] class type template parameters are const in GCC (differs from other compilers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108169 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-26 Ever confirmed|0 |1 --- Comment #5 from Andrew Pinski --- So confirmed.
[Bug c++/104577] needs copy constructor for class non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104577
mail at jhellings dot nl changed:
What|Removed |Added
CC||mail at jhellings dot nl
--- Comment #2 from mail at jhellings dot nl ---
I looked a bit further into this and into what the standard says. GCC does
partially the correct thing in this case, whereas several other compilers do
the wrong thing. See https://jhellings.nl/article?articleid=1 for the full
analysis.
The short summary:
In Clause 8 of Section [temp.param], the standard defines the value of a
non-type template argument:
"An id-expression naming a non-type template-parameter of class type T denotes
a static storage duration object of type const T known as a template parameter
object, whose value is that of the corresponding template argument after it has
been converted to the type of the template-parameter. ..."
Hence, whatever is provided as a non-type template parameter argument (of type
S in this bug report) is converted to the type S and the value resulting from
this conversion is available within the template as an lvalue object of type
const S.
To convert an expression to type S, you either need a constexpr copy
constructor (general case) or a constexpr move constructor (in the special case
in which you provide a movable value).
Note that both Clang and Microsoft C++ do not correctly implement the semantics
of non-type template parameters (they pass values without converting them to
the type of the non-type template parameter).
I did find a separate issue, however:
/*
* @author{Jelle Hellings}.
* @copyright{The 2-Clause BSD License; see the end of this article}.
*/
/*
* A type that can only be default-constructed and moved.
*/
struct no_copy
{
/*
* We can default-construct a dummy.
*/
constexpr no_copy() {};
/*
* We cannot copy dummy.
*/
no_copy(const no_copy&) = delete;
/*
* But we certainly can move a dummy.
*/
constexpr no_copy(no_copy&&) {}
};
/*
* A template function that accepts a no_copy non-type template parameter, but
* does not do anything with it.
*/
template
void test_f()
{
/* We cannot pass NC to another template, as we do not have a copy
* constructor. We can use this template by moving in a no_copy, however.
*/
};
/*
* A template struct that accepts a no_copy non-type template parameter, but
* does not do anything with it.
*/
template
struct test_t
{
/* We cannot pass NC to another template, as we do not have a copy
* constructor. We can use this template by moving in a no_copy, however.
*/
};
/*
* Entry-point of the program.
*/
int main ()
{
test_f(); // Works fine, as it should.
test_t value; // <- error: use of deleted function.
}
[Bug c++/108169] class type template parameters are const in GCC (differs from other compilers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108169 --- Comment #6 from mail at jhellings dot nl --- Dear Andrew, My excuses for ruining your Christmas ??! Thanks for confirming the bug so quickly, I hope my analysis helps solving this and other cases. With kind regards, Jelle Hellings -Original Message- From: pinskia at gcc dot gnu.org Sent: Sunday, December 25, 2022 11:02 PM To: m...@jhellings.nl Subject: [Bug c++/108169] class type template parameters are const in GCC (differs from other compilers) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108169 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91907
[Bug c++/108169] class type template parameters are const in GCC (differs from other compilers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108169 --- Comment #7 from Andrew Pinski --- (In reply to mail from comment #6) > Dear Andrew, > > My excuses for ruining your Christmas ??! You didn't ruin anything really. I have fun reading bugzilla reports really.
[Bug tree-optimization/93042] bit-field optimizations get in the way of interchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93042 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-26 --- Comment #1 from Andrew Pinski --- With lowering of bitfield accesses, gcc.dg/tree-ssa/loop-interchange-14.c fails because of this.
[Bug tree-optimization/45833] Unnecessary runtime versioning for aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45833
--- Comment #5 from Andrew Pinski ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> Same thing without a union:
>
> struct v { int v[4]; } __attribute__ ((aligned (4 * sizeof (int;
> void
> f (struct v *x, struct v *y, struct v *z)
> {
> for (int i = 0; i < 4; i++)
> x->v[i] = y->v[i] + z->v[i];
> }
That was fixed in GCC 8.
The union case is still not fixed.
[Bug c/108224] Suggest stdlib.h header for rand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224 Sam James changed: What|Removed |Added CC||sam at gentoo dot org --- Comment #4 from Sam James --- (In reply to Jonny Grant from comment #3) > Great! I just saw it is the same for random(), srandom(), initstate(), > setstate() > > Is there an easy way to add them all based on the C API to save opening > separate tickets? > > I added those : Could you send the patch to gcc-patches (the mailing list)? Thanks.
[Bug c++/101789] Fails to match (re-)declaration of member function of class template when using an alias template for the (dependent) return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101789 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-26 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed (I forgot to confirm it when it was split off). Both MSVC and clang accept the code.
