FYI: IA-32 psABI draft version 0.1
Here is the link: https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 -- H.J.
Re: organization of C Extensions in manual
On 01/18/15 09:47, Sandra Loosemore wrote: Arrays and Vectors Designated Inits: Labeling elements of initializers. I think this one might better be placed in a section on initializers. With a pointer/reference in the Array/Vector section. Pointers to Arrays: Pointers to arrays with qualifiers work as expected. Subscripting: Any array can be subscripted, even if not an lvalue. Variable Length: Arrays whose length is computed at run time. Vector Extensions: Using vector instructions through built-in functions. I'm not sure where this one belongs, but it doesn't seem to go with array extensions. It's not really about builtins, either. If there isn't a better place, then let's put it with arrays since the ability to create these vectors and subscript them like arrays to get at individual elements it at least related. Zero Length: Zero-length arrays. Attributes Attribute Syntax: Formal syntax for attributes. Function Attributes: Declaring that functions have no side effects, or that they can never return. Inline: Defining inline functions (as fast as macros). Doesn't seem to belong here. Given that inline isn't really an extension anymore, one could argue this isn't relevant anymore. Type Attributes: Specifying attributes of types. Variable Attributes: Specifying attributes of variables. Volatiles: What constitutes an access to a volatile object. Or this one. We could have a whole section on volatile :-) Variable Attributes might be a better place for the thread-local-storage stuff. jeff
Re: [LLVMdev] FYI: IA-32 psABI draft version 0.1
On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu wrote: > Here is the link: > > https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 The document contains this claim (as do many other psABI documents): "Bit-fields that are neither signed nor unsigned always have non-negative values. Although they may have type char, short, int, or long (which can have negative values), these bit-fields have the same range as a bit-field of the same size with the corresponding unsigned type." This does not reflect the ABI as widely implemented, and is incompatible with C++ (in which plain bit-fields are required to be signed). GCC documents why they ignore the psABI in this regard here: https://gcc.gnu.org/onlinedocs/gcc/Non-bugs.html#Non-bugs I would suggest either removing this specification from the psABI or correcting it to reflect actual implementation practice: plain bit-fields are signed.
Re: [LLVMdev] FYI: IA-32 psABI draft version 0.1
On Thu, Jan 22, 2015 at 11:54 AM, Richard Smith wrote: > On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu wrote: >> Here is the link: >> >> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 > > The document contains this claim (as do many other psABI documents): > > "Bit-fields that are neither signed nor unsigned > always have non-negative values. Although they may have type char, > short, int, or long (which can have negative values), these bit-fields > have the same range as a bit-field of the same size with the > corresponding unsigned type." > Can you show me where this paragraph in IA-32 psABI? I couldn't find it in my copy. -- H.J.
Re: [LLVMdev] FYI: IA-32 psABI draft version 0.1
On Thu, Jan 22, 2015 at 12:00 PM, H.J. Lu wrote: > On Thu, Jan 22, 2015 at 11:54 AM, Richard Smith wrote: >> On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu wrote: >>> Here is the link: >>> >>> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 >> >> The document contains this claim (as do many other psABI documents): >> >> "Bit-fields that are neither signed nor unsigned >> always have non-negative values. Although they may have type char, >> short, int, or long (which can have negative values), these bit-fields >> have the same range as a bit-field of the same size with the >> corresponding unsigned type." >> > > Can you show me where this paragraph in IA-32 psABI? > I couldn't find it in my copy. > FYI :-): commit 2496a6db377b489668e49c39b6f477a4f8f0ec22 Author: H.J. Lu Date: Wed Jan 7 13:05:49 2015 -0800 Remove Bit-Fields -- H.J.
Re: FYI: IA-32 psABI draft version 0.1
On Thu, 22 Jan 2015, H.J. Lu wrote: > Here is the link: > > https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 I sent the following reply to the ia32-abi list but haven't yet received it back from the list - you might want to check if it's stuck in moderation somewhere: I would suggest that rather than using old terms such as "single", "double" and "128-bit extended" to describe floating-point formats, and rather than referring to "IEEE-754R", the names from IEEE 754-2008 should be used. That is, binary32, binary64, binary128. (When referring to decimal32, decimal64, decimal128 you still need to specify somewhere that it's BID rather than DPD. And you'll still need to refer to 80-bit extended since that's not an IEEE interchange format.) -- Joseph S. Myers jos...@codesourcery.com
Re: organization of C Extensions in manual
On Thu, 22 Jan 2015, Jeff Law wrote: > > > Inline: Defining inline functions (as fast as macros). > > > > Doesn't seem to belong here. > Given that inline isn't really an extension anymore, one could argue this > isn't relevant anymore. Well, we need to document -std=gnu89 / __gnu_inline__ attribute semantics. And the fact that a C99 feature is accepted as an extension in C89 mode is something that needs documenting. Though for C extensions maybe the documentation would better describe exceptions - extensions from newer C standards that are *not* enabled in older standard modes, or that are only enabled when you use alternative keywords such as __inline. Then you wouldn't need to go into the details e.g. of long long, just that it's an extension accepted in C89 / C++98 mode. (For C++ there may be more features than for C that require -std=c++11 to enable them, so listing exceptions may not be the right approach for C++.) Ways in which GNU C features go beyond the corresponding standard feature do also need documenting. (So VLA documentation needs to refer to VLAs in structures, and to the interaction with alloca, and to parameter forward declarations, even if the basic feature is described in terms of a C99 feature also supported in C89 mode and for C++ and there's less need to describe the C99 semantics.) -- Joseph S. Myers jos...@codesourcery.com
C++ Standard Question
Hi
I think this is a glibc issue but since this method is defined in the C++
standards, I thought there were plenty of language lawyers here. :)
class strstreambuf : public basic_streambuf >
ISSUE > int pcount() const; <= ISSUE
My reading of the C++03 and draft C++14 says that the int pcount() method
in this class is not const. glibc has it const in the glibc shipped with
Fedora 20
and CentOS 6.
This is a simple test case:
#include
int main() {
int (std::strstreambuf::*dummy)() = &std::strstreambuf::pcount;
/*-- pcount is conformant --*/
return 0;
}
What's the consensus?
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: FYI: IA-32 psABI draft version 0.1
On Thu, Jan 22, 2015 at 1:13 PM, Joseph Myers wrote: > On Thu, 22 Jan 2015, H.J. Lu wrote: > >> Here is the link: >> >> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 > > I sent the following reply to the ia32-abi list but haven't yet received > it back from the list - you might want to check if it's stuck in > moderation somewhere: Gmail put the message in "Promotion" category :-). > I would suggest that rather than using old terms such as "single", > "double" and "128-bit extended" to describe floating-point formats, and > rather than referring to "IEEE-754R", the names from IEEE 754-2008 should > be used. That is, binary32, binary64, binary128. (When referring to > decimal32, decimal64, decimal128 you still need to specify somewhere that > it's BID rather than DPD. And you'll still need to refer to 80-bit > extended since that's not an IEEE interchange format.) > This change should be made in x86-64 psABI first before cherry-picked into IA-32 psABI. -- H.J.
Re: C++ Standard Question
On Thu, 22 Jan 2015, Joel Sherrill wrote:
I think this is a glibc issue but since this method is defined in the C++
standards, I thought there were plenty of language lawyers here. :)
s/glibc/libstdc++/ and they have their own ML.
That's deprecated, isn't it?
class strstreambuf : public basic_streambuf >
ISSUE > int pcount() const; <= ISSUE
My reading of the C++03 and draft C++14 says that the int pcount() method
in this class is not const. glibc has it const in the glibc shipped with
Fedora 20
and CentOS 6.
This is a simple test case:
#include
int main() {
int (std::strstreambuf::*dummy)() = &std::strstreambuf::pcount;
/*-- pcount is conformant --*/
return 0;
}
What's the consensus?
The exact signature of member functions is not mandated by the standard,
implementations are allowed to make the function const if that works (or
provide both a const and a non-const version). Your code is not guaranteed
to work. Lambdas usually provide a fine workaround.
--
Marc Glisse
Re: C++ Standard Question
On 1/22/2015 3:44 PM, Marc Glisse wrote:
> On Thu, 22 Jan 2015, Joel Sherrill wrote:
>
>> I think this is a glibc issue but since this method is defined in the C++
>> standards, I thought there were plenty of language lawyers here. :)
> s/glibc/libstdc++/ and they have their own ML.
Thank you.
>>
> That's deprecated, isn't it?
Yes. There is also a warning about that coming from the test code.
I don't know how long it has been deprecated since even with
-std=c++03, the warning is present.
>> class strstreambuf : public basic_streambuf >
>> ISSUE > int pcount() const; <= ISSUE
>>
>> My reading of the C++03 and draft C++14 says that the int pcount() method
>> in this class is not const. glibc has it const in the glibc shipped with
>> Fedora 20
>> and CentOS 6.
>>
>> This is a simple test case:
>>
>>#include
>>
>>int main() {
>>int (std::strstreambuf::*dummy)() = &std::strstreambuf::pcount;
>> /*-- pcount is conformant --*/
>>return 0;
>>}
>>
>> What's the consensus?
> The exact signature of member functions is not mandated by the standard,
> implementations are allowed to make the function const if that works (or
> provide both a const and a non-const version). Your code is not guaranteed
> to work. Lambdas usually provide a fine workaround.
>
This code is actually from the Open Group FACE Conformance Test Suite.
It uses code like this to check the presence of methods from the C Standard
Library, POSIX APIs, and the C++ Standard Library. It would be really
helpful
if you could cite the place in the C++ standard so I can provide that as
feedback
to the authors of the test suite.
On a positive note, the test suite isn't flagging much using this
technique. This
may be the only method. But I would like to provide the correct feedback to
them so no one else deals with this.
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: [LLVMdev] FYI: IA-32 psABI draft version 0.1
On Thu, Jan 22, 2015 at 12:05 PM, H.J. Lu wrote:
> On Thu, Jan 22, 2015 at 12:00 PM, H.J. Lu wrote:
>> On Thu, Jan 22, 2015 at 11:54 AM, Richard Smith
>> wrote:
>>> On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu wrote:
Here is the link:
https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4
>>>
>>> The document contains this claim (as do many other psABI documents):
>>>
>>> "Bit-fields that are neither signed nor unsigned
>>> always have non-negative values. Although they may have type char,
>>> short, int, or long (which can have negative values), these bit-fields
>>> have the same range as a bit-field of the same size with the
>>> corresponding unsigned type."
>>>
>>
>> Can you show me where this paragraph in IA-32 psABI?
>> I couldn't find it in my copy.
>>
>
> FYI :-):
>
> commit 2496a6db377b489668e49c39b6f477a4f8f0ec22
> Author: H.J. Lu
> Date: Wed Jan 7 13:05:49 2015 -0800
>
> Remove Bit-Fields
Ah, I was looking at the wrong branch ('master' instead of
'hjl/x86/master'). Thanks =)
gcc-4.8-20150122 is now available
Snapshot gcc-4.8-20150122 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150122/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 220017 You'll find: gcc-4.8-20150122.tar.bz2 Complete GCC MD5=0157fb6b61421a5881b8d6e607fd3996 SHA1=c220bc9f66cc549cdcb08718393ef5b34cc7a6ad Diffs from 4.8-20150115 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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.
building accelerators for both KNL and nvptx
I have just read the updated manual: https://gcc.gnu.org/wiki/Offloading It says to build an accel compiler, one need to: ./configure --build=x86_64-intelmicemul-linux-gnu --host=x86_64-intelmicemul-linux-gnu --target=x86_64-intelmicemul-linux-gnu --enable-as-accelerator-for=x86_64-pc-linux-gnu make make install DESTDIR=/install However does such accelerator also enable acceleration on nvptx? If not, then suppose if I have a machine that has both KNL and nvptx, then how can I build the toolchain for nvptx compiler? Also for the host, the website says: ./configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-offload-targets=x86_64-intelmicemul-linux-gnu=/install/prefix make make install DESTDIR=/install However if the host were to support offloading for both nvptx and KNL, then what EXTRA parameters do I need to pass in? Or does it by default support offloading to ANY architectures? Thanks! Mark
