[GSoC 2019]: Interested in "Make C/C++ not automatically promote memory_order_consume to memory_order_acquire"
Hello all, I am a 2nd year Master's student at IIT Bombay. The project "Make C/C++ not automatically promote memory_order_consume to memory_order_acquire" caught my eye and I would like to be the part of it. I have taken advance compiler courses in past semesters. I have already build gcc and have gone through this document P0190R4:Proposal for New memory order consume Definition (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf). Can anyone suggest some more prerequisites ? Thanks, Akshat Garg
Re: Idea: extend gcc to save C from the hell of intel vector instructions
On Mon, Feb 18, 2019 at 11:15 AM Warren D Smith wrote:
>
> There are a lot of weird intel vector instructions like
> #include
>
> __m128i alignas(16) A, B, C, D, X, Y;
> A = _mm_shuffle_epi8(D, Y);
> C = _mm_unpackhi_epi16(A, B);
> where my gcc seems to know about the latter but not the former
> (I have no idea why, and it is very annoying to arbitrarily support the second
> and not the first).
>
> Anyhow. If you write code like that, it is horrible to read.
>
> But here is a simple idea for improving the C language which would make
> lots of such code easy to read. And write.
>
> First of all, there should be (and pretty much are, see stdint.h,
> inttypes.h)
> int and uint types of various power of 2 bit sizes, e.g.
>
> int16 a;
> uint64 b;
> uint128 c;
>
> uint256 d;
> uint512 e;
> uint4 f;
>
> where again my gcc supports the first 3 (after appropriate renamings)
> but not the last 3. (Again, very annoying arbitrariness.)
>
> But more importantly, we should add new types like this:
>
> uint128.16 a, b;
> meaning a is 128 bits wide, and consists of 16 chunks, each 8 bits wide,
> each regarded as an 8-bit-wide unsigned int.
>
> uint256.8 y, z;
> and so on.
>
> Note the use of DOTS inside the type name. You could consider other
> notations,
> I am not fixated on this one. Another might be uint128{16}.
>
> OK, now we could do
> uint128.16 a, b, c;
> c = a+b; //adds the 16-element vectors a and b elementwise
> c = a-b; //subtracts vectors
> etc.
>
> Life is SO much nicer now. It's practically sane again.
GCC already has most of this support. See
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Vector-Extensions.html#Vector-Extensions
The dot in the typenames are not going to supported though.
Thanks,
Andrew
>
> Don't have to keep coming up with all the horrible
> names for each possible kind of vector operation, the compiler does it for
> you.
> Compiler can check type compatibility and complain if try to
> add incompatible types. etc etc.
>
> And for stuff that really should have funny names,
>b = shuffle(c, d)
> will have meaning pretty obvious from the types of b,c,d,
> and again can complain about type mismatches.
> And the type names will no longer be horrible unreadable strings of
> nonsense characters.
> They will be perfectly readable and logical simple names like uint128.16.
>
> The present hellish situation is partly intel's fault and partly gcc's fault,
> but it is absurd, that is for sure, and this hell is entirely
> unnecessary, that is
> what really rubs your face in it over and over.
>
> --
> Warren D. Smith
> http://RangeVoting.org <-- add your endorsement (by clicking
> "endorse" as 1st step)
Idea: extend gcc to save C from the hell of intel vector instructions
There are a lot of weird intel vector instructions like
#include
__m128i alignas(16) A, B, C, D, X, Y;
A = _mm_shuffle_epi8(D, Y);
C = _mm_unpackhi_epi16(A, B);
where my gcc seems to know about the latter but not the former
(I have no idea why, and it is very annoying to arbitrarily support the second
and not the first).
Anyhow. If you write code like that, it is horrible to read.
But here is a simple idea for improving the C language which would make
lots of such code easy to read. And write.
First of all, there should be (and pretty much are, see stdint.h, inttypes.h)
int and uint types of various power of 2 bit sizes, e.g.
int16 a;
uint64 b;
uint128 c;
uint256 d;
uint512 e;
uint4 f;
where again my gcc supports the first 3 (after appropriate renamings)
but not the last 3. (Again, very annoying arbitrariness.)
But more importantly, we should add new types like this:
uint128.16 a, b;
meaning a is 128 bits wide, and consists of 16 chunks, each 8 bits wide,
each regarded as an 8-bit-wide unsigned int.
uint256.8 y, z;
and so on.
Note the use of DOTS inside the type name. You could consider other notations,
I am not fixated on this one. Another might be uint128{16}.
OK, now we could do
uint128.16 a, b, c;
c = a+b; //adds the 16-element vectors a and b elementwise
c = a-b; //subtracts vectors
etc.
Life is SO much nicer now. It's practically sane again.
Don't have to keep coming up with all the horrible
names for each possible kind of vector operation, the compiler does it for you.
Compiler can check type compatibility and complain if try to
add incompatible types. etc etc.
And for stuff that really should have funny names,
b = shuffle(c, d)
will have meaning pretty obvious from the types of b,c,d,
and again can complain about type mismatches.
And the type names will no longer be horrible unreadable strings of
nonsense characters.
They will be perfectly readable and logical simple names like uint128.16.
The present hellish situation is partly intel's fault and partly gcc's fault,
but it is absurd, that is for sure, and this hell is entirely
unnecessary, that is
what really rubs your face in it over and over.
--
Warren D. Smith
http://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)
Question regarding constraint usage within inline asm
I have a question about constraint usage in inline asm when we have
an early clobber output operand. The test case is from PR89313 and
looks like the code below (I'm using "r3" for the reg on ppc, but
you could also use "rax" on x86_64, etc.).
long input;
long
bug (void)
{
register long output asm ("r3");
asm ("blah %0, %1, %2" : "=&r" (output) : "r" (input), "0" (input));
return output;
}
I know an input operand can have a matching constraint associated with
an early clobber operand, as there seems to be code that explicitly
mentions this scenario. In this case, the user has to manually ensure
that the input operand is not clobbered by the early clobber operand.
In the case that the input operand uses an "r" constraint, we just
ensure that the early clobber operand and the input operand are assigned
different registers. My question is, what about the case above where
we have the same variable being used for two different inputs with
constraints that seem to be incompatible? Clearly, we cannot assign
a register to the "input" variable that is both the same and different
to the register that is assigned to "output".
Is this outright invalid to have "input" use both a matching and
non-matching constraint with an early clobber operand? Or is is
expected that reload/LRA will come along and fix up the "r" usage
to use a different register?
My guess is that this is invalid usage and I have a patch to
expand_asm_stmt() to catch this, but it only works if we've
preassigned "output" to a hard register. If this is truly
invalid, should I flag this even if "output" isn't preassigned?
If it is valid, then should match_asm_constraints_1() really rewrite
all of the uses of "input" with the register assigned to output as
it is doing now, which is what is causing the problems in LRA.
LRA sees that both input operands are using r3 and it catches the
constraint violation of the "r" input and tries to spill it, but
it's not a pseudo, but an explicit hard register already. I'm not
sure LRA can really safely spill an operand that is an explicit hard
register.
Thoughts?
Peter
Re: GCC GSOC 2019
Hello Shubham, On Sun, Feb 10 2019, Shubham Narlawar wrote: > Hi, > > I am Shubham Narlawar. Currently, I am a Computer Engineering undergrad > student at Pune University, India. I am interested in contributing to GCC > for GSOC 2019. > > We have done a project from GCC GSOC 2018 idea list which is implementing > Csmith fuzzer leveraging GCC C Extensions under the guidance of Andi Kleen. > > Csmith is a C fuzzer which generates standard C code but no extensions. We > implemented few of GCC C extensions in Csmith (which now we call it as > "Extended Csmith"). Extended Csmith is now able to fuzz extensions along > with standard C code. > > Following GCC C Extensions are implemented in Csmith currently - > 1. Labels as Values (Computed Goto) > 2. Local Labels > 3. Typeof > 4. __int128 - Signed and unsigned integer of size 128 bits. > 5. Cast to Union > 6. Label attributes - hot cold > 7. Variable attributes - a) aligned > b) unused > c) section > 8. Binary constants > 9. Statement Expression > > 10. Transactional memory relaxed - tm_relaxed (not a GCC C extension) > > Note - Different Combinations of these extensions can be used while > generating random C code using extended csmith. > > Here is the github link of the project. > https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions > > Currently, We are running extended csmith on gcc10 of GCC Compile Farm > Project and found following bugs - > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89153 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87118 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223 > > We expect to find more bugs in GCC as the gcc compiler is being stress > tested now. > > Code coverage - Csmith vs Extended Csmith > > Csmith i.e. [without gcc extn ] > line - 35.2 > function - 43.2 > branch - 25.7 > > Extended Csmith [with gcc extn] > line - 35.7 > function - 43.9 > branch - 26.1 > > %gain > line - 0.5% > function - 0.7% > branch - 0.4% > > For GSOC 2019, I am proposing below project idea - > > Implementation of following extensions in the Csmith - > 1. Function attributes - aligned, alloc_align, always_inline, hot, cold, > deprecated, nothrow, used, etc > 2. Vector extensions > 3. Transactional Memory extensions > 4. Type attributes > and remaining GCC C extensions. > > Benefits to GCC - > 1. Increased code coverage. > 2. There is a possibility of finding more bugs after adding the above > extensions. > Thank you very much for sending us your project idea. I have noted it down and am looking forward to your project submission (assuming Google approves us as a participating organization, of course). Meanwhile, if you have any technical questions, regarding the GCC extensions you listed above, feel free to ask here on the list. Thank you, Martin
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
Hello Sameeran, On Sun, Feb 10 2019, sameeran joshi wrote: > Hi,I am an undergraduate student currently in final year of computer > science and engineering degree course from Pune University, India. I > and Shubham have been working on Last year's GSoC project idea : > > Implement a fuzzer leveraging GCC extensions. Fuzzers like csmith are > fairly good at finding compiler bugs. But they only generate standard > C, but no extensions. GCC has many extensions, which are not covered. > It would be good to extend a fuzzer like csmith to fuzz extensions > like OpenMP, attributes, vector extensions, etc. Then run the fuzzer > and report compiler bugs. > > since June 2018 under the guidance of mentor Andi Kleen. > I worked on generating GCC C language extensions here is the link > (coverage reports,implemented extension's list,bugs found,test cases, > and usage are in README file on github) > github Link: https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions > > We choose this as our university project as well, and are still > fuzzing the extensions on compiler farm. > > Based on the previous work I would like to propose the following idea > for GSoC 2019: > Extending Csmith for OpenMP extensions. > > I would implement following constructs of OpenMP > > 1.PARALLEL CONSTRUCT > 2.WORKSHARING CONSTRUCTS - > 2.1 sections > 2.2 single > 2.3 loop constructs > 2.4 master construct > 3.TEAMS CONSTRUCT > 4.TASKING CONSTRUCT - > 4.1 task > 4.2 taskloop > 4.3 taskloop simd > 4.4 taskyield > 5.SYNCHRONIZATION CONSTRUCTS - > 5.1 critical > 5.2 atomic > 5.3 barrier > 5.4 taskwait > 5.5 taskgroup > 6.DATA SHARING ATTRIBUTES - > 6.1 private > 6.2 public > 6.3 firstprivate > 6.4 lastprivate > Also, I would like to work on the target constrains if time permits. > The main challenge what I think would be to ensure that there aren't > any data races and data conflicts so that the parallelized program is > not undefined. > > Usage for the GCC community : > 1. It might have slight large increments in code coverage and trigger > a lot of unique code . > > I have watched >A "Hands-on" Introduction to OpenMP | Tim Mattson, Intel all 4 > parts >https://www.youtube.com/watch?v=pRtTIW9-Nr0 > > I have started reading the specification of latest 5.0 standard. > Please suggest if this could be an interesting idea for upcoming GSoC ? > Indeed it is, you clearly have it thought out very well. I have noted it down and am looking forward to your project submission (assuming Google approves us as a participating organization, of course). Meanwhile, if you have any technical questions, regarding the GCC extensions you listed above, feel free to ask here on the list. Good luck diving into the OpenMP spec and thank you, Martin
