Re: More consistency for Git log messages?
On Mon, 28 Dec 2020, 23:55 Gerald Pfeifer, wrote: > Having spent a bit more time with GCC sources (as opposed to wwwdocs) > recently and looking for prior art to guide me, I noticed there's a > lot of options to specific the ChangeLog file(s) to use. > > And correspondingly a lot of inconsistency. > > Right now we seem to allow for > > 1. gcc/cp/ChangeLog > 2. gcc/cp/ChangeLog: > 3. gcc/cp > 4. gcc/cp: > 5. gcc/cp/ > > and probably more. > We also allow not specifying the directory at all, if it can be deduced from the changed files. > Can we streamline this a bit and converge on one of the forms 3-5? > > Personally I'd suggest 3 (the shortest) or 5 (the directory), but whatever > ... as long as things become more consistent, which is easier on newbies > and reading logs (or automatically processing them later on). > We already process them automatically. It's worth noting that some people generate then automatically too, and the mklog.py hook uses form 2 IIRC.
Re: Any possibility to support link with msvc stl just like clang??
On Tue, 29 Dec 2020, 05:23 sotrdg sotrdg via Gcc, wrote: > That would be fun. > First you'd need to patch GCC to understand all the MSVC intrinsics or patch MS STL to use GCC intrinsics. Both are open source so it is probably possible, but you should be prepared do the work yourself, since you're the one asking for it. Most GCC developers have other priorities.
What is the type of vector signed + vector unsigned?
Any thoughts on what f should return in the following testcase, given the
usual GNU behaviour of treating signed >> as arithmetic shift right?
typedef int vs4 __attribute__((vector_size(16)));
typedef unsigned int vu4 __attribute__((vector_size(16)));
int
f (void)
{
vs4 x = { -1, -1, -1, -1 };
vu4 y = { 0, 0, 0, 0 };
return ((x + y) >> 1)[0];
}
The C frontend takes the type of x+y from the first operand, so x+y
is signed and f returns -1.
The C++ frontend applies similar rules to x+y as it would to scalars,
with unsigned T having a higher rank than signed T, so x+y is unsigned
and f returns 0x7fff.
FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++.
[Was looking at this in the context of PR96377.]
Thanks,
Richard
Re: What is the type of vector signed + vector unsigned?
On Tue, 29 Dec 2020, Richard Sandiford via Gcc wrote:
Any thoughts on what f should return in the following testcase, given the
usual GNU behaviour of treating signed >> as arithmetic shift right?
typedef int vs4 __attribute__((vector_size(16)));
typedef unsigned int vu4 __attribute__((vector_size(16)));
int
f (void)
{
vs4 x = { -1, -1, -1, -1 };
vu4 y = { 0, 0, 0, 0 };
return ((x + y) >> 1)[0];
}
The C frontend takes the type of x+y from the first operand, so x+y
is signed and f returns -1.
Symmetry is an important property of addition in C/C++.
The C++ frontend applies similar rules to x+y as it would to scalars,
with unsigned T having a higher rank than signed T, so x+y is unsigned
and f returns 0x7fff.
That looks like the most natural choice.
FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++.
I think clang follows gcc and uses the type of the first operand.
--
Marc Glisse
Re: What is the type of vector signed + vector unsigned?
On December 29, 2020 6:42:30 PM GMT+01:00, Marc Glisse
wrote:
>On Tue, 29 Dec 2020, Richard Sandiford via Gcc wrote:
>
>> Any thoughts on what f should return in the following testcase, given
>the
>> usual GNU behaviour of treating signed >> as arithmetic shift right?
>>
>>typedef int vs4 __attribute__((vector_size(16)));
>>typedef unsigned int vu4 __attribute__((vector_size(16)));
>>int
>>f (void)
>>{
>> vs4 x = { -1, -1, -1, -1 };
>> vu4 y = { 0, 0, 0, 0 };
>> return ((x + y) >> 1)[0];
>>}
>>
>> The C frontend takes the type of x+y from the first operand, so x+y
>> is signed and f returns -1.
>
>Symmetry is an important property of addition in C/C++.
>
>> The C++ frontend applies similar rules to x+y as it would to scalars,
>> with unsigned T having a higher rank than signed T, so x+y is
>unsigned
>> and f returns 0x7fff.
>
>That looks like the most natural choice.
>
>> FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++.
>
>I think clang follows gcc and uses the type of the first operand.
The desired behavior is the one that OpenCL specifies. If it is implementation
defined we should document behavior. I agree symmetry is nice but eventually
the current C behavior is what OpenCL specifies.
Richard.
Re: What is the type of vector signed + vector unsigned?
On Tue, 29 Dec 2020, Richard Biener via Gcc wrote: > >I think clang follows gcc and uses the type of the first operand. > > The desired behavior is the one that OpenCL specifies. If it is implementation > defined we should document behavior. I agree symmetry is nice but eventually > the current C behavior is what OpenCL specifies. Where does OpenCL specify that? Checking the 1.2 OpenCL standard I see the opposite (the code would fail to compile): 6.2.1 Implicit Conversions [...] Implicit conversions between built-in vector data types are disallowed. Alexander
Re: about -stdlib=libc++ toggle. what about recognize v1 as libc++ if libstdc++ is installed at the same location with libc++?
unlvsur unlvsur wrote: <3E6B1CF4201340D8BCCB373AE127FCC7.png> Sent from Mail for Windows 10 The -stdlib= option is an “enabling” change; As things stand, the packaging of the libc++ headers (and libc++ itself) needs intervention by the distribution (e.g. to add a coroutine header or to install the library on linux). I don’t think ‘automagical' adding of the option is appropriate (at least not yet). Iain
