public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/51155] New: sizeof and sizeof... in template partial specialization
@ 2011-11-16 7:31 pubby.8 at gmail dot com
2011-11-16 9:13 ` [Bug c++/51155] Incorrect sizeof and sizeof... behavior " daniel.kruegler at googlemail dot com
2021-06-01 14:28 ` ppalka at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: pubby.8 at gmail dot com @ 2011-11-16 7:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51155
Bug #: 51155
Summary: sizeof and sizeof... in template partial
specialization
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: pubby.8@gmail.com
-std=c++11
gcc version 4.7.0 20111112 (experimental) (GCC)
---
14.5.5.8 of n324 states:
"A partially specialized non-type argument expression shall not involve a
template parameter of the
partial specialization except when the argument expression is a simple
identifier."
From what I understand, this seems to be broken when using sizeof:
---
template <int a, int b>
struct foo { };
// partial specializations:
template <int a>
struct foo<a, 0> { }; // correct and compiles
template <int a>
struct foo<a + 1, 0> { }; // not correct and doesn't compile
template <int a>
struct foo<sizeof(a), 0> { }; // not correct and doesn't compile
// due to 'a' not being used
template <int a>
struct foo<sizeof(a), a> { }; // not correct and compiles
---
Additional bugs when using sizeof.. with a variadic template
---
template <int n, int... xs>
struct foo { };
// partial specialization:
template <int... xs>
struct foo<sizeof...(xs), xs...> { }; // not correct and doesn't compile
// although it should if sizeof is
allowed
template <int... xs>
struct foo<sizeof(xs), xs...> { }; // not correct and compiles
// sizeof(xs) evaluates to sizeof(int)
// which is incorrect
---
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c++/51155] Incorrect sizeof and sizeof... behavior in template partial specialization
2011-11-16 7:31 [Bug c++/51155] New: sizeof and sizeof... in template partial specialization pubby.8 at gmail dot com
@ 2011-11-16 9:13 ` daniel.kruegler at googlemail dot com
2021-06-01 14:28 ` ppalka at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: daniel.kruegler at googlemail dot com @ 2011-11-16 9:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51155
Daniel Krügler <daniel.kruegler at googlemail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |daniel.kruegler at
| |googlemail dot com
--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-11-16 08:36:52 UTC ---
(In reply to comment #0)
> 14.5.5.8 of n324 states:
>
> "A partially specialized non-type argument expression shall not involve a
> template parameter of the
> partial specialization except when the argument expression is a simple
> identifier."
>
> From what I understand, this seems to be broken when using sizeof:
[..]
> template <int a>
> struct foo<sizeof(a), a> { }; // not correct and compiles
The core language is a bit fuzzy here, but this example should be no problem at
all, because sizeof(a) does not actually depend on the value of a, it just
corresponds to the equivalent of sizeof(int), which is fine. I don't think that
gcc should change the compiler behaviour here unless the core language is
better. IMO the corresponding CWG issue is this one:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1315
I observe that Comeau online accepts this as well.
> Additional bugs when using sizeof.. with a variadic template
>
> template <int n, int... xs>
> struct foo { };
>
> // partial specialization:
> template <int... xs>
> struct foo<sizeof...(xs), xs...> { }; // not correct and doesn't compile
> // although it should if sizeof is
> allowed
>
> template <int... xs>
> struct foo<sizeof(xs), xs...> { }; // not correct and compiles
> // sizeof(xs) evaluates to sizeof(int)
> // which is incorrect
I agree that this should be ill-formed, it looks as if gcc incorrectly performs
an implicit unpacking of the parameter pack xs here. It does so correctly
within the body of a class template.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c++/51155] Incorrect sizeof and sizeof... behavior in template partial specialization
2011-11-16 7:31 [Bug c++/51155] New: sizeof and sizeof... in template partial specialization pubby.8 at gmail dot com
2011-11-16 9:13 ` [Bug c++/51155] Incorrect sizeof and sizeof... behavior " daniel.kruegler at googlemail dot com
@ 2021-06-01 14:28 ` ppalka at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-06-01 14:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51155
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |ppalka at gcc dot gnu.org
Target Milestone|--- |12.0
Resolution|--- |DUPLICATE
--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
GCC 12 now handles all these testcases correctly after r12-1093, which
implements CWG 1315.
*** This bug has been marked as a duplicate of bug 67593 ***
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-06-01 14:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-16 7:31 [Bug c++/51155] New: sizeof and sizeof... in template partial specialization pubby.8 at gmail dot com
2011-11-16 9:13 ` [Bug c++/51155] Incorrect sizeof and sizeof... behavior " daniel.kruegler at googlemail dot com
2021-06-01 14:28 ` ppalka at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).