New GCC mirror
Hi, I set up a new GCC mirror. URL: https://bigsearcher.com/mirrors/gcc/ Update frequency: daily Organization/Contact: BigSearcher (https://bigsearcher.com) / i...@bigsearcher.com Location: San Francisco CA, USA Please, add it to your official mirror list page. Thank you, Andrea
Re: Implementing p0515 - spaceship operator
On 10/01/18 14:00, Jonathan Wakely wrote: > On 9 Jan 2018 10:56 p.m., "Tim van Deurzen" wrote: > > > Just to confirm with you, it does make sense to conditionally parse the > token for operator<=> in libcpp (i.e. only when the cxx standard being used > is >=2a)? I'm just wondering if this does not accidentally affect other > front-ends using libcpp? > Maybe it is easier to say "gcc supports <=> in C++2a, and as an extension also supports it in C and C++ of any standard" ? I don't believe there is any way for it to conflict with existing valid code, so it would do no harm as a gcc extension like that - and C users can then use it too. > > Other front ends won't setthe language to C++2a. > > I think the relevant check is: > > if (CPP_OPTION (pfile, lang) == CLK_CXX2A > || CPP_OPTION (pfile, lang) == CLK_GNUCXX2A) > > This can only be true for a C++ source file when the standard is C++2a. >
Re: Implementing p0515 - spaceship operator
t all cleaOn 11 January 2018 at 10:05, David Brown wrote: > Maybe it is easier to say "gcc supports <=> in C++2a, and as an > extension also supports it in C and C++ of any standard" ? I don't > believe there is any way for it to conflict with existing valid code, so > it would do no harm as a gcc extension like that - and C users can then > use it too. It's not very useful in C because you need the comparison category types, which are classes defined in (see http://en.cppreference.com/w/cpp/header/compare) C doesn't have those types, and can't define anything close. And it's non-conforming to declare those types in pre-C++2a, because the names could be used by user programs. Potentially the types could be defined with reserved names like __strong_ordering, and then make std::strong_ordering a typedef for that, but there are also changes to the language spec that go with the new operator, and enabling those pre-C++2a could change the meaning of valid code. So it's not ar it does no harm.
Re: Implementing p0515 - spaceship operator
On 11 January 2018 at 10:13, Jonathan Wakely wrote: > t all cleaOn 11 January 2018 at 10:05, David Brown wrote: >> Maybe it is easier to say "gcc supports <=> in C++2a, and as an >> extension also supports it in C and C++ of any standard" ? I don't >> believe there is any way for it to conflict with existing valid code, so >> it would do no harm as a gcc extension like that - and C users can then >> use it too. > > It's not very useful in C because you need the comparison category > types, which are classes defined in (see > http://en.cppreference.com/w/cpp/header/compare) > > C doesn't have those types, and can't define anything close. > > And it's non-conforming to declare those types in pre-C++2a, because > the names could be used by user programs. > > Potentially the types could be defined with reserved names like > __strong_ordering, and then make std::strong_ordering a typedef for > that, but there are also changes to the language spec that go with the > new operator, and enabling those pre-C++2a could change the meaning of > valid code. > > So it's not ar it does no harm. Sorry, Firefox keeps jumping the cursor around and garbled this text as I entered it. That should read: So it's not at all clear it does no harm.
Re: Implementing p0515 - spaceship operator
On 11/01/18 11:13, Jonathan Wakely wrote: > t all cleaOn 11 January 2018 at 10:05, David Brown wrote: >> Maybe it is easier to say "gcc supports <=> in C++2a, and as an >> extension also supports it in C and C++ of any standard" ? I don't >> believe there is any way for it to conflict with existing valid code, so >> it would do no harm as a gcc extension like that - and C users can then >> use it too. > > It's not very useful in C because you need the comparison category > types, which are classes defined in (see > http://en.cppreference.com/w/cpp/header/compare) > > C doesn't have those types, and can't define anything close. > Surely you can get very close by simply returning an int, value -1, 0 or 1? That is what other languages (like PHP) do for their <=> operator. There are complications - such as for floating point when you have NaNs. But I think you could have a very successful operator if you defined "a <=> b" to be the same as "(a > b) - (a < b)". Whether it would be particularly /useful/ or not is another matter. I was thinking mainly in terms of saving effort when making C++2a support - rather than having to making the new operator conditional on a particular version of the standards, it could be accepted in any version. > And it's non-conforming to declare those types in pre-C++2a, because > the names could be used by user programs. > > Potentially the types could be defined with reserved names like > __strong_ordering, and then make std::strong_ordering a typedef for > that, but there are also changes to the language spec that go with the > new operator, and enabling those pre-C++2a could change the meaning of > valid code. > > So it's not ar it does no harm. >
Re: Implementing p0515 - spaceship operator
On 11 January 2018 at 11:28, David Brown wrote: > On 11/01/18 11:13, Jonathan Wakely wrote: >> t all cleaOn 11 January 2018 at 10:05, David Brown wrote: >>> Maybe it is easier to say "gcc supports <=> in C++2a, and as an >>> extension also supports it in C and C++ of any standard" ? I don't >>> believe there is any way for it to conflict with existing valid code, so >>> it would do no harm as a gcc extension like that - and C users can then >>> use it too. >> >> It's not very useful in C because you need the comparison category >> types, which are classes defined in (see >> http://en.cppreference.com/w/cpp/header/compare) >> >> C doesn't have those types, and can't define anything close. >> > > Surely you can get very close by simply returning an int, value -1, 0 or > 1? That is what other languages (like PHP) do for their <=> operator. > There are complications - such as for floating point when you have NaNs. > But I think you could have a very successful operator if you defined "a > <=> b" to be the same as "(a > b) - (a < b)". > > Whether it would be particularly /useful/ or not is another matter. I > was thinking mainly in terms of saving effort when making C++2a support > - rather than having to making the new operator conditional on a > particular version of the standards, it could be accepted in any version. It seems like the wrong trade-off. We have dozens of features that depend on the standards mode, we know how to do that. Simply slamming a new language feature in all modes (*and* in a different language with a different front-end!) to save a small amount of effort doesn't seem like a good idea to me. Especially if it then doesn't even work the same pre-C++2a, as know we need to test it in additional ways.
Re: Implementing p0515 - spaceship operator
On 11 January 2018 at 11:32, Jonathan Wakely wrote: > On 11 January 2018 at 11:28, David Brown wrote: >> On 11/01/18 11:13, Jonathan Wakely wrote: >>> t all cleaOn 11 January 2018 at 10:05, David Brown wrote: Maybe it is easier to say "gcc supports <=> in C++2a, and as an extension also supports it in C and C++ of any standard" ? I don't believe there is any way for it to conflict with existing valid code, so it would do no harm as a gcc extension like that - and C users can then use it too. >>> >>> It's not very useful in C because you need the comparison category >>> types, which are classes defined in (see >>> http://en.cppreference.com/w/cpp/header/compare) >>> >>> C doesn't have those types, and can't define anything close. >>> >> >> Surely you can get very close by simply returning an int, value -1, 0 or >> 1? That is what other languages (like PHP) do for their <=> operator. >> There are complications - such as for floating point when you have NaNs. >> But I think you could have a very successful operator if you defined "a >> <=> b" to be the same as "(a > b) - (a < b)". >> >> Whether it would be particularly /useful/ or not is another matter. I >> was thinking mainly in terms of saving effort when making C++2a support >> - rather than having to making the new operator conditional on a >> particular version of the standards, it could be accepted in any version. > > It seems like the wrong trade-off. We have dozens of features that > depend on the standards mode, we know how to do that. > > Simply slamming a new language feature in all modes (*and* in a > different language with a different front-end!) to save a small amount > of effort doesn't seem like a good idea to me. Especially if it then > doesn't even work the same pre-C++2a, as know we need to test it in s/know/now/ > additional ways.
Re: Implementing p0515 - spaceship operator
On 11/01/18 12:32, Jonathan Wakely wrote: > On 11 January 2018 at 11:28, David Brown wrote: >> On 11/01/18 11:13, Jonathan Wakely wrote: >>> t all cleaOn 11 January 2018 at 10:05, David Brown wrote: Maybe it is easier to say "gcc supports <=> in C++2a, and as an extension also supports it in C and C++ of any standard" ? I don't believe there is any way for it to conflict with existing valid code, so it would do no harm as a gcc extension like that - and C users can then use it too. >>> >>> It's not very useful in C because you need the comparison category >>> types, which are classes defined in (see >>> http://en.cppreference.com/w/cpp/header/compare) >>> >>> C doesn't have those types, and can't define anything close. >>> >> >> Surely you can get very close by simply returning an int, value -1, 0 or >> 1? That is what other languages (like PHP) do for their <=> operator. >> There are complications - such as for floating point when you have NaNs. >> But I think you could have a very successful operator if you defined "a >> <=> b" to be the same as "(a > b) - (a < b)". >> >> Whether it would be particularly /useful/ or not is another matter. I >> was thinking mainly in terms of saving effort when making C++2a support >> - rather than having to making the new operator conditional on a >> particular version of the standards, it could be accepted in any version. > > It seems like the wrong trade-off. We have dozens of features that > depend on the standards mode, we know how to do that. > > Simply slamming a new language feature in all modes (*and* in a > different language with a different front-end!) to save a small amount > of effort doesn't seem like a good idea to me. Especially if it then > doesn't even work the same pre-C++2a, as know we need to test it in > additional ways. > Fair enough. I was merely thinking it might make the development a little easier by avoiding more feature testing in the front ends. And gcc has a history of making some features of one language or standard available in others as gcc extensions. (Sometimes I find these useful in my coding - though I can't think off-hand for a use of <=> in my own programs.) But I see pre-C++2a would be a problem here. You can't make it match the C++2a version, because you don't have the types available - and you wouldn't want to make it have different types that are incompatible with the C++2a version. It would be fine with a -1, 0, 1 int result in C - but not in pre-C++2a.
Re: Implementing p0515 - spaceship operator
On Thu, 11 Jan 2018, David Brown wrote: > Maybe it is easier to say "gcc supports <=> in C++2a, and as an > extension also supports it in C and C++ of any standard" ? I don't > believe there is any way for it to conflict with existing valid code, so > it would do no harm as a gcc extension like that - and C users can then > use it too. As per previous IRC discussion, changing the lexing to support this pp-token can break valid code in previous standards, e.g. code concatenating <=> and >, then stringizing the result (the C++ proposal for adding this feature also notes some obscure cases where the character sequence <=> can actually occur as tokens, not just pp-tokens - "X<&Y::operator<=>" and "x+&operator<=>y" - so of course patches adding this feature should add testcases using such cases with older -std= options). Changes to cpp_avoid_paste (so that preprocessed output does not put a pp-token starting with > immediately after <=) do not need to be conditional on the standard version, however. -- Joseph S. Myers jos...@codesourcery.com
gcc-7-20180111 is now available
Snapshot gcc-7-20180111 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180111/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 256556 You'll find: gcc-7-20180111.tar.xzComplete GCC SHA256=8ce66a1e834d55424db7f2115d4c0df75cd2ca40a2b2ca29cff7ac5991a1599a SHA1=66b11cba84b112ba2769a85591c5147d5685a34d Diffs from 7-20180104 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Status of m32c target?
Hello, what is the status of the m32c target? There are some open bugs that prevent the C/C++ compiler build: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&list_id=197687&product=gcc&query_format=advanced&short_desc=m32c&short_desc_type=allwordssubstr -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
