Reminder: 3.6 branch is coming

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Reminder: 3.6 branch is coming

Hans Wennborg-2
Reminder: The plan is to create the 3.6 branch next week, on 14 January.

Please help get the release notes and other documents updated. For
example, both the LLVM [1] and Clang [2] release notes look pretty
empty.

Also, if you'd like to volunteer to be a release tester, please let me know.

Cheers,
Hans

 1. http://llvm.org/docs/ReleaseNotes.html
 2. http://clang.llvm.org/docs/ReleaseNotes.html
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Reminder: 3.6 branch is coming

Ben Pope
On Friday, January 09, 2015 08:32 AM, Hans Wennborg wrote:

> Reminder: The plan is to create the 3.6 branch next week, on 14 January.
>
> Please help get the release notes and other documents updated. For
> example, both the LLVM [1] and Clang [2] release notes look pretty
> empty.
>
> Also, if you'd like to volunteer to be a release tester, please let me know.
>
> Cheers,
> Hans
>
>   1. http://llvm.org/docs/ReleaseNotes.html
>   2. http://clang.llvm.org/docs/ReleaseNotes.html
>

Happy to test on Ubuntu 14.04 x86_64.

Ben

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Reminder: 3.6 branch is coming

Renato Golin-2
On 9 January 2015 at 00:51, Ben Pope <[hidden email]> wrote:
> Happy to test on Ubuntu 14.04 x86_64.

ARM and AArch64 here.

--renato
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reminder: 3.6 branch is coming

Sylvestre Ledru-6
In reply to this post by Hans Wennborg-2
On 09/01/2015 01:32, Hans Wennborg wrote:
> Reminder: The plan is to create the 3.6 branch next week, on 14 January.
>
> Please help get the release notes and other documents updated. For
> example, both the LLVM [1] and Clang [2] release notes look pretty
> empty.
>
> Also, if you'd like to volunteer to be a release tester, please let me know.
>
>
Happy to test, all Debian archs.

Sylvestre

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reminder: 3.6 branch is coming

Dimitry Andric
In reply to this post by Hans Wennborg-2
I'll test on FreeBSD, as usual.  Note that trunk has been failing "check-all" on FreeBSD for some time now, due to this:

FAIL: Clang :: CXX/drs/dr6xx.cpp (627 of 20130)
******************** TEST 'Clang :: CXX/drs/dr6xx.cpp' FAILED ********************
Script:
--
/home/dim/obj/llvm-r225586-aconf/Release+Asserts/bin/clang -cc1 -internal-isystem /home/dim/obj/llvm-r225586-aconf/Release+Asserts/bin/../lib/clang/3.6.0/include -nostdsysteminc -std=c++98 /share/dim/src/llvm/trunk/tools/clang/test/CXX/drs/dr6xx.cpp -verify -fexceptions -fcxx-exceptions -pedantic-errors
/home/dim/obj/llvm-r225586-aconf/Release+Asserts/bin/clang -cc1 -internal-isystem /home/dim/obj/llvm-r225586-aconf/Release+Asserts/bin/../lib/clang/3.6.0/include -nostdsysteminc -std=c++11 /share/dim/src/llvm/trunk/tools/clang/test/CXX/drs/dr6xx.cpp -verify -fexceptions -fcxx-exceptions -pedantic-errors
/home/dim/obj/llvm-r225586-aconf/Release+Asserts/bin/clang -cc1 -internal-isystem /home/dim/obj/llvm-r225586-aconf/Release+Asserts/bin/../lib/clang/3.6.0/include -nostdsysteminc -std=c++14 /share/dim/src/llvm/trunk/tools/clang/test/CXX/drs/dr6xx.cpp -verify -fexceptions -fcxx-exceptions -pedantic-errors
/home/dim/obj/llvm-r225586-aconf/Release+Asserts/bin/clang -cc1 -internal-isystem /home/dim/obj/llvm-r225586-aconf/Release+Asserts/bin/../lib/clang/3.6.0/include -nostdsysteminc -std=c++1z /share/dim/src/llvm/trunk/tools/clang/test/CXX/drs/dr6xx.cpp -verify -fexceptions -fcxx-exceptions -pedantic-errors
--
Exit Code: 1

Command Output (stderr):
--
error: 'error' diagnostics seen but not expected:
  File /share/dim/src/llvm/trunk/tools/clang/test/CXX/drs/dr6xx.cpp Line 259: static_assert failed "__STDC_MB_MIGHT_NEQ_WC__ but all basic source characters have same representation"
1 error generated.

--

It looks like the interpretation of what "__STDC_MB_MIGHT_NEQ_WC__" means differs between the llvm developers and the FreeBSD developers.  I'm not sure what a good solution is.

-Dimitry

> On 09 Jan 2015, at 01:32, Hans Wennborg <[hidden email]> wrote:
>
> Reminder: The plan is to create the 3.6 branch next week, on 14 January.
>
> Please help get the release notes and other documents updated. For
> example, both the LLVM [1] and Clang [2] release notes look pretty
> empty.
>
> Also, if you'd like to volunteer to be a release tester, please let me know.
>
> Cheers,
> Hans
>
> 1. http://llvm.org/docs/ReleaseNotes.html
> 2. http://clang.llvm.org/docs/ReleaseNotes.html
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reminder: 3.6 branch is coming

David Chisnall-5
On 10 Jan 2015, at 17:35, Dimitry Andric <[hidden email]> wrote:
>
> It looks like the interpretation of what "__STDC_MB_MIGHT_NEQ_WC__" means differs between the llvm developers and the FreeBSD developers.  I'm not sure what a good solution is.

I've just read the relevant parts of the C11 spec, and it's not really clear to me what the 'basic character set' is.  There are two possible interpretations:

- The set of characters that can be represented by a char in locale "C"
- The set of characters that can be represented by a char in *any* locale

On FreeBSD, it is correct to define __STDC_MB_MIGHT_NEQ_WC__ for the second definition, but not for the first.  Can anyone point to something in the spec that clarifies this?

David


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Reminder: 3.6 branch is coming

sebastian.dressler
In reply to this post by Hans Wennborg-2
2015-01-09 1:32 GMT+01:00 Hans Wennborg <[hidden email]>:
> [...]
> Also, if you'd like to volunteer to be a release tester, please let me know.

I'm again in for testing OS X.

Cheers,
Sebastian
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Reminder: 3.6 branch is coming

Daniel Sanders
I'll be doing Mips.
________________________________________
From: [hidden email] [[hidden email]] on behalf of Sebastian Dreßler [[hidden email]]
Sent: 10 January 2015 21:21
To: Hans Wennborg
Cc: cfe-dev; llvmdev
Subject: Re: [LLVMdev] Reminder: 3.6 branch is coming

2015-01-09 1:32 GMT+01:00 Hans Wennborg <[hidden email]>:
> [...]
> Also, if you'd like to volunteer to be a release tester, please let me know.

I'm again in for testing OS X.

Cheers,
Sebastian
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reminder: 3.6 branch is coming

Dimitry Andric
In reply to this post by David Chisnall-5
On 10 Jan 2015, at 18:58, David Chisnall <[hidden email]> wrote:

>
> On 10 Jan 2015, at 17:35, Dimitry Andric <[hidden email]> wrote:
>>
>> It looks like the interpretation of what "__STDC_MB_MIGHT_NEQ_WC__" means differs between the llvm developers and the FreeBSD developers.  I'm not sure what a good solution is.
>
> I've just read the relevant parts of the C11 spec, and it's not really clear to me what the 'basic character set' is.  There are two possible interpretations:
>
> - The set of characters that can be represented by a char in locale "C"
> - The set of characters that can be represented by a char in *any* locale
>
> On FreeBSD, it is correct to define __STDC_MB_MIGHT_NEQ_WC__ for the second definition, but not for the first.  Can anyone point to something in the spec that clarifies this?
I don't have any clarification, but I do want to quote some discussion from a previous email conversation with Ed Schouten and Richard Smith.  This started with me mailing Ed about this particular test failure, to which he replied:

> On 15 Oct 2014, at 14:12, Ed Schouten <[hidden email]> wrote:
>> On Mon, Oct 13, 2014 at 10:57 PM, Dimitry Andric <[hidden email]> wrote:
>> We talked about this a little on IRC, and the opinion seems to be that defining __STDC_MB_MIGHT_NEQ_WC__ for FreeBSD is not the right thing to do.  The standard says:
>>
>> __STDC_MB_MIGHT_NEQ_WC__  The integer constant 1, intended to indicate that, in the encoding for wchar_t, a member of the basic character set need not have a code value equal to its value when used as the lone character in an ordinary character literal.
>>
>> But the "basic character set" is just the whitespace characters, plus a-zA-Z0-9_{}[]#()<>%:;.?*+-/^&|∼!=,\"’, and I don't think this set is dependent on the locale at all, even with wchar_t...?
>
> As far as I know, they are. On FreeBSD, the encoding of wchar_t
> depends on the locale entirely. This is annoying. I would have loved
> to see us use UCS-4 instead.
>
> Even though FreeBSD does not ship with this, it should be perfectly
> feasible to come up with an EBCDIC locale that would directly map to
> the low 8 bits of wchar_t.
>
> The test case in the LLVM tree is invalid and should be discarded. It
> erroneously assumes that the encoding of wchar_t is independent of the
> locale.
Richard then argued this makes no sense:

> On 15 Oct 2014, at 19:42, Richard Smith <[hidden email]> wrote:
>> On 15 Oct 2014 05:12, "Ed Schouten" <[hidden email]> wrote:
> ...
>> The test case in the LLVM tree is invalid and should be discarded. It
>> erroneously assumes that the encoding of wchar_t is independent of the
>> locale.
>>
> That makes no sense. These value are compile-time constants and cannot possibly depend on the locale.

Next, Ed remarked that wide characters are indeed locale-dependent:

> On 15 Oct 2014, at 19:50, Ed Schouten <[hidden email]> wrote:
>> On Wed, Oct 15, 2014 at 7:42 PM, Richard Smith <[hidden email]> wrote:
>> ...
>> That makes no sense. These value are compile-time constants and cannot
>> possibly depend on the locale.
>
> Exactly, but as far as I know, that's exactly the problem why wide
> characters are broken as implemented on FreeBSD. They are locale
> dependent, meaning that there is no way a compiler could reliably emit
> literal character/string literals.
And Richard then seemed to conclude that this was something to be solved on the FreeBSD side:

> On 15 Oct 2014, at 19:58, Richard Smith <[hidden email]> wrote:
>> On 15 Oct 2014 10:50, "Ed Schouten" <[hidden email]> wrote:
> ...

> That is a much more fundamental problem than the value of this macro, and is a problem the FreeBSD folks will need to sort out for themselves.
>
> Nonetheless, we need to have a fixed encoding for wide character literals, and the macro is specified as corresponding to *that* encoding. And in that encoding, narrow and wide basic source characters have the same value.

This was the end of the thread.  Now, to go back to the beginning again, when I read the C++11 standard, it mentions a "basic source character set" in 2.3 [lex.charset]:

> The basic source character set consists of 96 characters: the space character, the control characters repre- senting horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:14
>
> abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 _{}[]#()<>%:;.?*+-/^&|∼!=,\"’

It looks like this is equivalent to "basic character set", since references in the document mentioning that name refer back to section 2.3.  That section also has a footnote which seems relevant:

> The glyphs for the members of the basic source character set are intended to identify characters from the subset of ISO/IEC 10646 which corresponds to the ASCII character set. However, because the mapping from source file characters to the source character set (described in translation phase 1) is specified as implementation-defined, an implementation is required to document how the basic source characters are represented in source files.

All in all, I'm not sure whether the test case should fail when __STDC_MB_MIGHT_NEQ_WC__ is 1 and all basic source characters just 'happen' to be equal to their representation.

Either that, or maybe just XFAIL the test case on FreeBSD, to fix it.

-Dimitry


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reminder: 3.6 branch is coming

David Chisnall-5
On 12 Jan 2015, at 08:07, Dimitry Andric <[hidden email]> wrote:

>
>
> On 15 Oct 2014, at 19:42, Richard Smith <[hidden email]> wrote:
>> On 15 Oct 2014 05:12, "Ed Schouten" <[hidden email]> wrote:
> ...
>> The test case in the LLVM tree is invalid and should be discarded. It
>> erroneously assumes that the encoding of wchar_t is independent of the
>> locale.
>>
> That makes no sense. These value are compile-time constants and cannot possibly depend on the locale.

I believe Richard is wrong here.  There are a number of similar compile-time constant macros in the C spec.  I believe the clue as to the correct reading of the spec is in the name of the macro: __STDC_MB_MIGHT_NEQ_WC__

Note the word *might*.  It means that it is not safe for code to assume that a cast will give the corresponding char value if one exists.  i.e. that assumption is not true for all locales.

As dim says, the test is wrong.  It would be a valid test for it to fail if __STDC_MB_MIGHT_NEQ_WC__ is *not* defined and not all characters in the basic set have the same encoding as wide chars, but it is not correct to fail if it is set unless that have the same encoding in *all* locales, *and* the vendor is willing to guarantee that they will have the same encoding for all locales in all future binary-compatible versions of the system (which an automated test can't check).

In summary: the test is nonsense and should be removed.

David


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reminder: 3.6 branch is coming

Hans Wennborg-2
On Mon, Jan 12, 2015 at 1:26 AM, David Chisnall
<[hidden email]> wrote:

> On 12 Jan 2015, at 08:07, Dimitry Andric <[hidden email]> wrote:
>>
>>
>> On 15 Oct 2014, at 19:42, Richard Smith <[hidden email]> wrote:
>>> On 15 Oct 2014 05:12, "Ed Schouten" <[hidden email]> wrote:
>> ...
>>> The test case in the LLVM tree is invalid and should be discarded. It
>>> erroneously assumes that the encoding of wchar_t is independent of the
>>> locale.
>>>
>> That makes no sense. These value are compile-time constants and cannot possibly depend on the locale.
>
> I believe Richard is wrong here.  There are a number of similar compile-time constant macros in the C spec.  I believe the clue as to the correct reading of the spec is in the name of the macro: __STDC_MB_MIGHT_NEQ_WC__
>
> Note the word *might*.  It means that it is not safe for code to assume that a cast will give the corresponding char value if one exists.  i.e. that assumption is not true for all locales.
>
> As dim says, the test is wrong.  It would be a valid test for it to fail if __STDC_MB_MIGHT_NEQ_WC__ is *not* defined and not all characters in the basic set have the same encoding as wide chars, but it is not correct to fail if it is set unless that have the same encoding in *all* locales, *and* the vendor is willing to guarantee that they will have the same encoding for all locales in all future binary-compatible versions of the system (which an automated test can't check).
>
> In summary: the test is nonsense and should be removed.

I couldn't find an existing PR for this, so I filed
http://llvm.org/PR22208 with folks on this thread cc'd. It would be
great if we could get it resolved soon.

Thanks,
Hans

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reminder: 3.6 branch is coming

Richard Smith-33
In reply to this post by David Chisnall-5
On Mon, Jan 12, 2015 at 1:26 AM, David Chisnall <[hidden email]> wrote:
On 12 Jan 2015, at 08:07, Dimitry Andric <[hidden email]> wrote:
>
>
> On 15 Oct 2014, at 19:42, Richard Smith <[hidden email]> wrote:
>> On 15 Oct 2014 05:12, "Ed Schouten" <[hidden email]> wrote:
> ...
>> The test case in the LLVM tree is invalid and should be discarded. It
>> erroneously assumes that the encoding of wchar_t is independent of the
>> locale.
>>
> That makes no sense. These value are compile-time constants and cannot possibly depend on the locale.

I believe Richard is wrong here.  There are a number of similar compile-time constant macros in the C spec.  I believe the clue as to the correct reading of the spec is in the name of the macro: __STDC_MB_MIGHT_NEQ_WC__

Note the word *might*.  It means that it is not safe for code to assume that a cast will give the corresponding char value if one exists.  i.e. that assumption is not true for all locales.

You should read the definitions in the relevant standards rather than trying to guess what the macro means from its name. Here is the definition:

"The integer constant 1, intended to indicate that, in the encoding for wchar_t, a member of the basic character set need not have a code value equal to its value when used as the lone character in an integer character constant."

So the value 1 indicates that 'x' might not equal L'x' for some character x in the basic character set. (Note that the 'might' means that there might exist some *character* where this happens, not that there might exist some *locale* where this happens.) Since the value of 'x' and L'x' are determined at translation time, this property obviously cannot depend in any way on the current locale in the execution environment.

Note that the above property is *exactly* what the test is testing for.

However... the FreeBSD folks don't seem interested in fixing their bug, and it's technically conforming for an implementation to define this macro to 1 in any situation -- a member of the basic source character set "need not" have the same value as a narrow or wide character, even though they all actually do -- making this a quality-of-implementation issue, and I'm tired of discussing this, so I've relaxed the test for FreeBSD in r225751.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reminder: 3.6 branch is coming

Nikola Smiljanic
Count me in for testing Fedora and OpenSUSE.

On Tue, Jan 13, 2015 at 1:01 PM, Richard Smith <[hidden email]> wrote:
On Mon, Jan 12, 2015 at 1:26 AM, David Chisnall <[hidden email]> wrote:
On 12 Jan 2015, at 08:07, Dimitry Andric <[hidden email]> wrote:
>
>
> On 15 Oct 2014, at 19:42, Richard Smith <[hidden email]> wrote:
>> On 15 Oct 2014 05:12, "Ed Schouten" <[hidden email]> wrote:
> ...
>> The test case in the LLVM tree is invalid and should be discarded. It
>> erroneously assumes that the encoding of wchar_t is independent of the
>> locale.
>>
> That makes no sense. These value are compile-time constants and cannot possibly depend on the locale.

I believe Richard is wrong here.  There are a number of similar compile-time constant macros in the C spec.  I believe the clue as to the correct reading of the spec is in the name of the macro: __STDC_MB_MIGHT_NEQ_WC__

Note the word *might*.  It means that it is not safe for code to assume that a cast will give the corresponding char value if one exists.  i.e. that assumption is not true for all locales.

You should read the definitions in the relevant standards rather than trying to guess what the macro means from its name. Here is the definition:

"The integer constant 1, intended to indicate that, in the encoding for wchar_t, a member of the basic character set need not have a code value equal to its value when used as the lone character in an integer character constant."

So the value 1 indicates that 'x' might not equal L'x' for some character x in the basic character set. (Note that the 'might' means that there might exist some *character* where this happens, not that there might exist some *locale* where this happens.) Since the value of 'x' and L'x' are determined at translation time, this property obviously cannot depend in any way on the current locale in the execution environment.

Note that the above property is *exactly* what the test is testing for.

However... the FreeBSD folks don't seem interested in fixing their bug, and it's technically conforming for an implementation to define this macro to 1 in any situation -- a member of the basic source character set "need not" have the same value as a narrow or wide character, even though they all actually do -- making this a quality-of-implementation issue, and I'm tired of discussing this, so I've relaxed the test for FreeBSD in r225751.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev