<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 September 2015 at 17:05, Michael Hordijk via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, that's a good summary. bug 11272 is the request for this type of documentation. In general I think more people will be looking for this type of documentation such that the can determine how using this implementation will effect them.<br>
<br>
In the near term we need a direct answer as to whether clang supports implementation defined behavior under C11 6.7.2.1 P 5, specifically the use of enums as bit fields.<br>
<br>
We're starting to run into some issues that are indicating that it may not be supported, which is fine but we need to know the intentions for this behavior.<br>
<br>
I suppose that technically if the implementation does not define the behavior then the behavior is not supported/undefined. If it's going to be supported we'd like to avoid unnecessary code churn. On the flip side we could just go remove this behavior and we won't have to worry about it if we decide to use a different implementation.<br></blockquote><div><br></div><div>Implemmentation defined behaviour that is not "defined" is not the same as undefined behaviour. There is a distinct difference in that implementation defined behaviour is supposed to "work" (do something reasonably meaningful) or not compile, where UB is allowed to result in just about anything [covering both "works as you expect" (whatever "expect" may entail) and "crashes" or "fails to compile"]. <br><br>Of course, the spec also states that IDB should be documented, so technically, the clang compiler is not fulfilling the specifications in this respect.<br><br></div><div>I suspect, however, that if you are seeing a behaviour where the code compiles, but isn't behaving as you expect, it's quite possibly a compiler bug, rather than "implementation is intended to behave this way". <br><br></div><div>If the compiler does not support this, I'd very much expect the compiler to NOT accept the source code, so in that respect it's a bug either way. But it probably requires a small test-case to show the problem behaviour.<br></div><div><br>--<br></div><div>Mats<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- michael<span class=""><br>
<br>
On 8/26/15 4:38, mats petersson via cfe-dev wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
@Serge:<br>
<br>
I think the point of bug 11272 is to actually document [directly or<br>
referring to some other documentation elsewhere] ALL of the clang<br>
implementation defined behaviour, which includes the behaviour with<br>
bitfields from enums (and I expect it is identical to gcc's behaviour,<br>
but I don't KNOW that this is the case).<br>
<br>
--<br>
Mats<br>
<br>
On 26 August 2015 at 11:27, Serge Pavlov<br>
<<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>>> wrote:<br>
<br>
Hi,<br>
<br>
Bug 11272 - document implementation-defined behavior<br></span>
<<a href="https://llvm.org/bugs/show_bug.cgi?id=11272" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=11272</a>> says nothing about bit<span class=""><br>
fields.<br>
<br>
Thanks,<br>
--Serge<br>
<br>
2015-08-26 15:28 GMT+06:00 mats petersson via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br></span>
<mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>>:<span class=""><br>
<br>
Bug number would be 11272 - the text has been mime-encoded to<br>
replace the = with =3D (since mime uses = as a special<br>
character, and =3D is the escaped = sign). Obviously, some step<br>
on the way didn't understand the encoding and left it as plain<br>
text without decoding it.<br>
<br>
--<br>
Mats<br>
<br>
On 26 August 2015 at 08:29, Csaba Raduly via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br></span><div><div class="h5">
<mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>> wrote:<br>
<br>
Hi.<br>
<br>
On Mon, Aug 24, 2015 at 10:29 PM, Hordijk, Michael via<br>
cfe-dev wrote:<br>
> The short question:<br>
><br>
> Does clang support using an enum as a type for a bit-field?<br>
><br>
> C11 (6.7.2.1 P 5):<br>
><br>
> A bit-field shall have a type that is a qualified or unqualified version<br>
> of _Bool, signed int, unsigned int, or some other implementation-defined<br>
> type.<br>
...<br>
> So I'm curious as to whether clang supports it. I did find this on<br>
> bugzilla:<br>
><br>
><a href="https://llvm.org/bugs/show_bug.cgi?id=3D11272" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=3D11272</a><br>
<br>
LLVM Bugzilla says:<br>
<br>
'3D11272' is not a valid bug number.<br>
<br>
<br>
Csaba<br>
--<br>
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++<br>
The Tao of math: The numbers you can count are not the real<br>
numbers.<br>
Life is complex, with real and imaginary parts.<br>
"Ok, it boots. Which means it must be bug-free and perfect.<br>
" -- Linus Torvalds<br>
"People disagree with me. I just ignore them." -- Linus Torvalds<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br></div></div>
<mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><span class=""><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br></span>
<mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><span class=""><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>