Possible bug regarding C++ SFINAE
Hello,
I've noticed some strange behavior regarding C++ SFINAE that I believe
may not be ISO-14882 compliant. I've tried to get a minimal example to
reproduce the compilation errors I'm getting, but some explanation is
needed.
I'm working on a boolean metafunction to detect nested member
templates. I'm basically following the example of detecting nested
types from comp.lang.c++.moderated USENET postings from Rani Sharoni
(2002-03-17, http://tinyurl.com/2u2a9f) and Aleksey Gurtovoy
(2002-03-19, http://tinyurl.com/376y7c). Also, the 3rd code example in
section 14.8.2 of the standard especially illustrates what I'm trying
to do. There's been some discussion on the Boost mailing list on the
thread archived at http://tinyurl.com/39cvhc.
I'll first show a working example. Then I'll show two examples that
perhaps should work but instead generate compilation errors. The
following example works.
$ g++ -dumpversion
4.1.2
$ cat sfinae_success.cc
typedef char (&yes)[1];
typedef char (&no) [2];
template struct type_substitute {};
template class>
struct biary_template_substitute {};
template
struct has_xxx {
template
static no test(
type_substitute*,
...
);
template
static yes test(
type_substitute*,
biary_template_substitute<
W::template xxx
>*
);
static const bool value
= sizeof(test(0, 0)) == sizeof(yes);
};
struct foo {
template struct xxx;
};
struct bar {
template struct yyy;
};
struct baz {
template struct xxx;
};
int main()
{
int assert_has_xxx[has_xxx::value];
int assert_not_xxx[!has_xxx::value];
int assert_not_unary[!has_xxx::value];
}
$ g++ -std=c++98 -pedantic sfinae_success.cc
$
However, the following changes introduce a compilation error.
$ diff -c sfinae_success.cc sfinae_error1.cc
*** sfinae_success.cc 2007-04-04 11:21:10.0 -0400
--- sfinae_error1.cc2007-04-04 11:21:10.0 -0400
***
*** 10,25
struct has_xxx {
template
static no test(
! type_substitute*,
...
);
template
static yes test(
! type_substitute*,
! biary_template_substitute<
! W::template xxx
! >*
);
static const bool value
--- 10,23
struct has_xxx {
template
static no test(
! W*,
...
);
template
static yes test(
! W*,
! typename W::template xxx*
);
static const bool value
$ g++ -std=c++98 -pedantic sfinae_error1.cc
sfinae_error1.cc: In instantiation of 'const bool has_xxx::value':
sfinae_error1.cc:43: instantiated from here
sfinae_error1.cc:24: error: wrong number of template arguments (2, should be 1)
sfinae_error1.cc:36: error: provided for 'template struct baz::xxx'
$
If you cast the first argument to test() instead of explicitly calling
test(0, 0), then gcc no longer issues the error above. However,
overload resolution no longer chooses the intended function overload.
$ diff -c sfinae_error1.cc sfinae_error2.cc
*** sfinae_error1.cc2007-04-04 11:21:10.0 -0400
--- sfinae_error2.cc2007-04-04 11:21:10.0 -0400
***
*** 21,27
);
static const bool value
! = sizeof(test(0, 0)) == sizeof(yes);
};
struct foo {
--- 21,27
);
static const bool value
! = sizeof(test((T*)0, 0)) == sizeof(yes);
};
struct foo {
$ g++ -std=c++98 -pedantic sfinae_error2.cc
sfinae_error2.cc: In function 'int main()':
sfinae_error2.cc:41: error: ISO C++ forbids zero-size array 'assert_has_xxx'
$
Are either or both of these errors the result of non standard
compliant bugs in gcc? If not, what's the explanation? If so, let me
know if you'd like me to fill out a bug report.
Thanks!
Daniel Walker
powerpc -mcpu=common equivalent ?
Hi, It looks like -mcpu=common (on the powerpc architecture) was removed. My group is struggling to find a way to compile generic binaries for PowerPC. We have been getting an LWSYNC instruction included in the binaries, and some of our processors are getting a trap when this instructions is executed. The platforms we are using are all Freescale, they are p2020, t1042, and 8540. Freescale support informed us that we should use -mcpu=common , which is gone, we tried a number of other -mcpu setting including -mcpu=powerpc, but none of them allow us to have generic binaries for all the platforms. I suppose this is either a bug report that we're getting lwsync when we shouldn't be getting it, or just a question of what the typical tune is to make generic binaries ? Thanks for any help, Daniel
Re: powerpc -mcpu=common equivalent ?
On 02/09/2017 10:08 AM, David Edelsohn wrote: On Thu, Feb 9, 2017 at 1:00 PM, Daniel Walker wrote: Hi, It looks like -mcpu=common (on the powerpc architecture) was removed. My group is struggling to find a way to compile generic binaries for PowerPC. We have been getting an LWSYNC instruction included in the binaries, and some of our processors are getting a trap when this instructions is executed. The platforms we are using are all Freescale, they are p2020, t1042, and 8540. Freescale support informed us that we should use -mcpu=common , which is gone, we tried a number of other -mcpu setting including -mcpu=powerpc, but none of them allow us to have generic binaries for all the platforms. I suppose this is either a bug report that we're getting lwsync when we shouldn't be getting it, or just a question of what the typical tune is to make generic binaries ? I think that you misunderstand what "common" meant. Common was a subset of the original IBM POWER Architecture (not POWER processor) and the PowerPC architecture. An option that targets all Freescale processors is up to Freescale. Thanks, David No, I understood that. I'm not actually sure if we don't have a POWER architecture included. However, lwsync didn't exist in POWER, and some of our processors don't tolerate lwsync. Do you know of a way to compile for all powerpc and POWER platforms in one ? Or to compile for powerpc platforms which don't tolerate lwsync for some reason? Daniel
Re: powerpc -mcpu=common equivalent ?
On 02/09/2017 11:06 AM, Jakub Jelinek wrote: On Thu, Feb 09, 2017 at 01:47:33PM -0500, David Edelsohn wrote: Freescale did not implement the POWER architecture. Again, POWER is a comment about the original IBM POWER architecture (RIOS processors) and used in RISC System/6000 computers, not the recent POWER processors called POWER4, POWER5, POWER6, POWER7, POWER8, POWER9. lwsync is part of the ISA and Freescale did not fully implement the architecture. Freescale or someone needs to implement a patch to target the Freescale non-compliant processors. It seems with -mcpu=8540 and -mcpu=8548 you get sync instead of lwsync: /* E500 cores only support plain "sync", not lwsync. */ #define TARGET_NO_LWSYNC (rs6000_cpu == PROCESSOR_PPC8540 \ || rs6000_cpu == PROCESSOR_PPC8548) The question is if all the CPUs you're using are these 2, or if you use some others that might not be superset of those. Jakub We tried using e500, but on Freescale t1042 there was another instruction, evstdd instruction which caused a fault. Andrii did the testing, he can address it better than I can. Daniel
