Re: trying out openacc 2.0
Mark Farnell wrote: > Has OpenACC 2.0 support been merged into the trunk yet? If not, then > is it contained in gomp-4_0-branch? > > If so, what parameters should I pass to ./configure to enable OpenACC > 2.0, and relevant backends such as CUDA, MIC and other GPGPU/manycore > architecture? > > Also, I have a feeling that OpenACC 2.0 did NOT make it to gcc 5.0, am > I correct? If I am correct, then will it be included in gcc 5.1? If > I am wrong and it is already included into gcc 5.0, then I would > really really like to use it. > > In the latter case, will I be able to write OpenACC 2.0 / OpenMP 4.0 > code that runs on my nvidia GPU and/or Intel Xeon Phi? Let's start from the end: OpenMP 4 support for Intel's Xeon Phi is in the trunk and - in principle - working. The only problem is that only Knights Landing (knl) is supported and not the old Knights Corner (knc); given that Knights Landing is not yet available, you currently can only use it with a simulator. Regarding the question how to build GCC with accelerator support, see https://gcc.gnu.org/wiki/Offloading - That page applies both to OpenACC and OpenMP and to KNL and Nvidia's PTX. However, it is currently still a bit KNL centric. Regarding OpenACC: The support has not yet been merged, however, I think the goal is still to get it included in GCC 5. The first bits - like PTX support - have already been merged. I think the gomp-4_0-branch provides all what's needed and it has been recently updated to match the trunk (last Sunday). For building the branch and using OpenACC+PTX, again start with https://gcc.gnu.org/wiki/Offloading Tobias, who has yet to try offloading himself
Re: no response to cfarm request
Hi, On 9 December 2014 at 09:16, Jay Foad wrote: > I've followed the instructions to request access to the GCC compile > farm (https://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F) but > heard nothing for two weeks, despite a ping. Are the instructions > still correct? Is there anyone else I can contact about it? I've pinged again and waited another week with no response. Is there no-one else who can administer compile farm accounts? Thanks, Jay.
Re: Regular darwin builds
Hi FX, On 15 Dec 2014, at 21:11, FX wrote: > Hi all, > > I’ve set up daily builds and regtests on a darwin box. The results should > appear directly on gcc-testresults > (https://gcc.gnu.org/ml/gcc-testresults/current/). > This should, in the future, help track down regressions affecting darwin > (PIC-related, in particular!) Great!! If you want me to build a bootstrap compiler including Ada - then let me know (I am sure that a darwin13 4.9 Ada compiler should be suitable for bootstrapping trunk on darwin14). I can make the most-stripped-down possible (c,c++,ada) and upload it wherever we can find some common space. > The hardware is new, the OS is the latest and greatest > (x86_64-apple-darwin14), and will be updated to keep it that way. However, > it’s not very powerful (it’s a Mac Mini). Bootstrap (C, C++, Obj-C, Obj-C++, > Fortran, Java, LTO) takes about 2 hours, regtesting both 32 and 64-bit takes > a bit over 3 hours. My 1-year-old mac mini with 16G of RAM takes (on darwin13) ~ 74mins for all langs including Ada, so memory is possibly the determining factor (unless we have some slow-down with darwin14 :( ). > I plan to schedule it for: > > - daily bootstrap + regtest of trunk > - weekly bootstrap of latest release branch (currently 4.9) > > If you have other ideas, I’m open to suggestions. I wonder if we can cook up an incremental build scheme, that tries to do every commit that doesn't touch config files. Also, if/when I get some ns (hopefully over the holiday period things might calm down enough) I'll push my WIP branches and prototype GAS ports to github (and some of the patches to the list). Dunno if you would consider it worth building the "vendor branch" for 4.9 once in a while. One of my colleagues got his hands on two G5s and I made up some darwin9 boot disks for him - we might well try to resurrect a powerpc-darwin9 build-bot (shared between GCC and LLVM, since we have ports for both to test). My machines are always running at capacity just testing patched branches, so not much use for this kind of stuff. cheers and thanks for the work! Iain
Re: no response to cfarm request
On Tue, Dec 16, 2014 at 10:13 AM, Jay Foad wrote: > I've pinged again and waited another week with no response. Is there > no-one else who can administer compile farm accounts? Maybe you should try the gcc-cfarm mailing list: https://mail.gna.org/listinfo/gcc-cfarm-users It seems very responsive.
bug in lra-constraints.c (simple_move_p register_move_cost)
Hi, I may have found a bug when I was trying to port my private backend to new LRA pass (using gcc 4.9.2+patches). In lra-constraints.c, in function simple_move_p, the target hook targetm.register_move_cost is called with two badly swapped parameters : targetm.register_move_cost (GET_MODE (src), sclass, dclass) should be : targetm.register_move_cost (GET_MODE (src), dclass, sclass) In my port of GCC it leads to an error when checking constrain_operands at the end of LRA pass Regards, Selim Belbachir
Re: [RFC] GCC vector extension: binary operators vs. differing signedness
Richard Biener wrote: > On Fri, Dec 12, 2014 at 1:08 PM, Ulrich Weigand wrote: > > Richard Biener wrote: > >> On Thu, Dec 11, 2014 at 4:04 PM, Ulrich Weigand > >> wrote: > >> > However, if we make that change, there will be some cases that regress: > >> > the > >> > problem is that an expression "x + y" has *one* result type, and some > >> > things > >> > you do with the result will require that type to match precisely > >> > (including > >> > signedness). So *any* change that affects what that result type is will > >> > regress some code that happened to rely on the precise result type ... > >> > >> True, but IMHO that's still better. You may want to check the openCL spec > >> which we tried to follow losely as to what we allow. > >> > >> So again, implementing your A is ok with me. > > > > Well, the openCL spec says that operations between signed and unsigned > > vectors are simply prohibited (both openCL 1.2 and openCL 2.0 agree on > > this, and it matches the behavior of my old openCL compiler ...): [snip] > The question is what the fallout is if we reject this by default (I suppose > we accept it with -flax-vector-conversions). I'm ok with following > OpenCL as well, > that is either solution that makes behavior consistent between C and C++. I agree that we should certainly continue to support mixed types with -flax-vector-conversions. (This means we really should fix the C/C++ inconsistency as to return type in any case, even if we disable mixed type support by default.) What the fallout of disabling mixed types by default would be is hard to say. On the one hand, all other standards I've looked at (OpenCL, Altivec/VSX, Cell SPU) prohibit mixing signed/unsigned types. So this hopefully means users of the GCC extension don't use this feature (much). [Of course, Altivec does not really talk about operators, but ideally GCC's a + b should be equivalent to the Altivec vec_add (a, b), which does not support mixing signed/unsigned types.] On the other hand, I've noticed at least two related areas where disabling mixed types could result in unexpected fallout: opaque types and platform specific vector types (e.g. "vector bool" on Altivec). Opaque types are a somewhat under-specified GCC feature that is used for different purposes by various platforms and the middle-end itself: - some platform-specific types (PPC SPE __ev64_opaque__ or MEP cp_vector) - function parameters for overloaded builtins in C before resolution - the output of vector comparison operators and vector truth_type_for It should be possible to use an opaque type together with vectors of different types, even with -flax-vector-conversions (and even if we disable support for signed/unsigned mixed types); the result of an operation on an opaque type and a non-opaque type should be the non-opaque type; it's not quite clear to me how operations on two different opaque types are (should be?) defined. Platform-specific types like Altivec "vector bool" are not really known to the middle-end; this particular case is treated just like a normal unsigned integer vector type. This means that as a side-effect of disabling signed/unsigned mixed types, we would also disallow mixing signed/bool types. But at least for Altivec vec_add, the latter is explicitly *allowed* (returning the signed type). It would certainly be preferable for + to be compatible to vec_add also for the bool types. [ Note that the current implementation also does not fully match that goal, because while signed + bool is allowed, the return value is sometimes the bool type instead of the signed type. ] This can probably only be fully solved by making the middle-end aware that things like "vector bool" need to be handled specially. I had thought that maybe the back-end simply needs to mark "vector bool" as an opaque type (after all, the middle-end also uses this for vector truth types), but that doesn't work as-is, since one of the other features of opaque types is that they cannot be initialized. (Altivec vector bool *can* be initialized.) Maybe those two features should be decoupled, so we can have opaque types used as truth types, and those that cannot be initialized ... So overall the list of actions probably looks like this: 1. Fix the selection of the common type to use for binary vector operations - C and C++ need to be consistent - If one type is opaque and the other isn't, use the non-opaque type - If one type is unsigned and the other is signed, use the unsigned type - What to do with different types where neither of the above rules apply? 2. Rework support for opaque and platform-specific vector types - Instead of the single "opaque" bit, have two flags: * Mark type as compatible with other types in assignment/operations * Mark type as "cannot be initialized" - Use initializable opaque types for Altivec "vector bool" (and others?) 3. Disable mixing signed/unsigned types in binary operations - This remains allowed if
Re: Regular darwin builds
Hi FX, Thanks for doing that. Looking at your results for gcc 5.0, I see a lot of gcc.dg/ubsan/* failures I don’t see in my tests. Any idea why? Dominique > Le 15 déc. 2014 à 22:11, FX a écrit : > > Hi all, > > I’ve set up daily builds and regtests on a darwin box. The results should > appear directly on gcc-testresults > (https://gcc.gnu.org/ml/gcc-testresults/current/). > This should, in the future, help track down regressions affecting darwin > (PIC-related, in particular!). > > The hardware is new, the OS is the latest and greatest > (x86_64-apple-darwin14), and will be updated to keep it that way. However, > it’s not very powerful (it’s a Mac Mini). Bootstrap (C, C++, Obj-C, Obj-C++, > Fortran, Java, LTO) takes about 2 hours, regtesting both 32 and 64-bit takes > a bit over 3 hours. > > I plan to schedule it for: > > - daily bootstrap + regtest of trunk > - weekly bootstrap of latest release branch (currently 4.9) > > If you have other ideas, I’m open to suggestions. > > FX
Re: Regular darwin builds
On 16 Dec 2014, at 19:38, Dominique d'Humières wrote: > Looking at your results for gcc 5.0, I see a lot of gcc.dg/ubsan/* failures I > don’t see in my tests. Any idea why? I think that there will be ubsan fails until the library is installed (which implies that the testing is not setting the right DYLD_LIBRARY_PATH). Iain > >> Le 15 déc. 2014 à 22:11, FX a écrit : >> >> Hi all, >> >> I’ve set up daily builds and regtests on a darwin box. The results should >> appear directly on gcc-testresults >> (https://gcc.gnu.org/ml/gcc-testresults/current/). >> This should, in the future, help track down regressions affecting darwin >> (PIC-related, in particular!). >> >> The hardware is new, the OS is the latest and greatest >> (x86_64-apple-darwin14), and will be updated to keep it that way. However, >> it’s not very powerful (it’s a Mac Mini). Bootstrap (C, C++, Obj-C, Obj-C++, >> Fortran, Java, LTO) takes about 2 hours, regtesting both 32 and 64-bit takes >> a bit over 3 hours. >> >> I plan to schedule it for: >> >> - daily bootstrap + regtest of trunk >> - weekly bootstrap of latest release branch (currently 4.9) >> >> If you have other ideas, I’m open to suggestions. >> >> FX >
Re: trying out openacc 2.0
That's good news. Does it mean that if I want to try out openACC with KNL and PTX support, then all I need to do is to compile the gomp-4_0-branch *without* any extra parameters into ./configure ? Also, are other GPUs such as the AMD ATI and the built-in GPUs such as the Intel GPU and AMD fusion supported? If so, are they already supported in the trunk, or only specific branch? Finally, when will support of Knights Corner (knc) be added to the trunk and/or one of the branches? Thanks! Mark On Tue, Dec 16, 2014 at 9:22 PM, Tobias Burnus wrote: > Mark Farnell wrote: >> Has OpenACC 2.0 support been merged into the trunk yet? If not, then >> is it contained in gomp-4_0-branch? >> >> If so, what parameters should I pass to ./configure to enable OpenACC >> 2.0, and relevant backends such as CUDA, MIC and other GPGPU/manycore >> architecture? >> >> Also, I have a feeling that OpenACC 2.0 did NOT make it to gcc 5.0, am >> I correct? If I am correct, then will it be included in gcc 5.1? If >> I am wrong and it is already included into gcc 5.0, then I would >> really really like to use it. >> >> In the latter case, will I be able to write OpenACC 2.0 / OpenMP 4.0 >> code that runs on my nvidia GPU and/or Intel Xeon Phi? > > Let's start from the end: OpenMP 4 support for Intel's Xeon Phi is in the > trunk and - in principle - working. The only problem is that only > Knights Landing (knl) is supported and not the old Knights Corner (knc); > given that Knights Landing is not yet available, you currently can only use > it with a simulator. > > Regarding the question how to build GCC with accelerator support, see > https://gcc.gnu.org/wiki/Offloading - That page applies both to OpenACC > and OpenMP and to KNL and Nvidia's PTX. However, it is currently still a bit > KNL centric. > > Regarding OpenACC: The support has not yet been merged, however, I think the > goal is still to get it included in GCC 5. The first bits - like PTX support - > have already been merged. I think the gomp-4_0-branch provides all what's > needed and it has been recently updated to match the trunk (last Sunday). > For building the branch and using OpenACC+PTX, again start with > https://gcc.gnu.org/wiki/Offloading > > Tobias, > who has yet to try offloading himself
Re: Regular darwin builds
Is it again the difference between testing before or after install? Dominique > Le 16 déc. 2014 à 20:50, Iain Sandoe a écrit : > > > On 16 Dec 2014, at 19:38, Dominique d'Humières wrote: > >> Looking at your results for gcc 5.0, I see a lot of gcc.dg/ubsan/* failures >> I don’t see in my tests. Any idea why? > > I think that there will be ubsan fails until the library is installed (which > implies that the testing is not setting the right DYLD_LIBRARY_PATH). > > Iain
Re: trying out openacc 2.0
On Wed, Dec 17, 2014 at 08:54:06AM +1300, Mark Farnell wrote: > That's good news. Does it mean that if I want to try out openACC with > KNL and PTX support, then all I need to do is to compile the > gomp-4_0-branch *without* any extra parameters into ./configure ? No. Please read the wiki page Tobias mentioned, you need to build 2 compilers and pass some configure options to get OpenMP + KNL support. OpenACC has not been committed to trunk yet, but even when it will make it in, you'll still need similarly to build 2 compilers and configure them non-default way. > Also, are other GPUs such as the AMD ATI and the built-in GPUs such as > the Intel GPU and AMD fusion supported? If so, are they already > supported in the trunk, or only specific branch? Some AMD HSA support is on the hsa svn branch, but AFAIK OpenMP 4.0 offloading nor OpenACC is supported there yet (instead just auto-offloading some OpenMP 3.x loops I believe). > Finally, when will support of Knights Corner (knc) be added to the > trunk and/or one of the branches? Unlikely. The advantage of KNL is that it uses the same vector ISA as the future desktop/server CPUs, not a different one; to support KNC we'd need to make the i?86 backend larger and more complicated for something that is not going to be used in any? future CPUs. Jakub
Re: Regular darwin builds
Yes, the ubsan issues are about setting DYLD_LIBRARY_PATH: dyld: Symbol not found: __ZTIN10__cxxabiv117__class_type_infoE Referenced from: /Users/fx/autobuilds/builds/gcc-trunk-218778/x86_64-apple-darwin14.0.0/i386/libsanitizer/ubsan/.libs/libubsan.0.dylib Expected in: /usr/lib/libstdc++.6.dylib in /Users/fx/autobuilds/builds/gcc-trunk-218778/x86_64-apple-darwin14.0.0/i386/libsanitizer/ubsan/.libs/libubsan.0.dylib Another testsuite issue on darwin is that testsuite doesn’t clean up the .dSYM directories it generates. This gets really annoying on my autotester :( FX
Re: Regular darwin builds
> Another testsuite issue on darwin is that testsuite doesn’t clean up the > .dSYM directories it generates. This gets really annoying on my autotester :( I have a patch for that, but Iain does not like it!-( Dominique
Re: Regular darwin builds
On 16 Dec 2014, at 20:40, Dominique d'Humières wrote: > >> Another testsuite issue on darwin is that testsuite doesn’t clean up the >> .dSYM directories it generates. This gets really annoying on my autotester :( > > I have a patch for that, but Iain does not like it!-( Hmm .. I like the patch in principle, ... the problem is that it doesn't clean up when one does cross-testing or installed testing - so it needed tweaking to use the right approach to deleting files on the remote/host - we (erm, probably I, in truth) never got around to finding the right recipe. Might I suggest pulling it out of storage - and getting a review, perhaps from Mike who might be able to identify the best place to do the job. Iain
Re: Regular darwin builds
On Dec 16, 2014, at 12:46 PM, Iain Sandoe wrote: > > On 16 Dec 2014, at 20:40, Dominique d'Humières wrote: >> >>> Another testsuite issue on darwin is that testsuite doesn’t clean up the >>> .dSYM directories it generates. This gets really annoying on my autotester >>> :( >> >> I have a patch for that, but Iain does not like it!-( > > Hmm .. I like the patch in principle, > ... the problem is that it doesn't clean up when one does cross-testing or > installed testing - so it needed tweaking to use the right approach to > deleting files on the remote/host - we (erm, probably I, in truth) never got > around to finding the right recipe. > > Might I suggest pulling it out of storage - and getting a review, perhaps > from Mike who might be able to identify the best place to do the job. I won’t be too picky. if is_native cleanup_native isn't unreasonable. https://gcc.gnu.org/ml/gcc/2012-03/msg00364.html So, I can’t help but think, we don’t need to slow the world down, and we can just do a find . \*.DSYM -exec rm type of thing at the end. Simple, easy, works for native and the old cross is native ppc builds on x86. Life goes on.
Re: Regular darwin builds
My patch is different and I am attaching it (it is quite old, so it may not apply cleanly). The problem for more evolved form is that *.dSYM are directories and ASAICT there is no command in derange to remove them. At least my patch tracks all the locations giving *.dSYM. Dominique patch-dsym3 Description: Binary data > Le 16 déc. 2014 à 21:55, Mike Stump a écrit : > > On Dec 16, 2014, at 12:46 PM, Iain Sandoe wrote: >> >> On 16 Dec 2014, at 20:40, Dominique d'Humières wrote: >>> Another testsuite issue on darwin is that testsuite doesn’t clean up the .dSYM directories it generates. This gets really annoying on my autotester :( >>> >>> I have a patch for that, but Iain does not like it!-( >> >> Hmm .. I like the patch in principle, >> ... the problem is that it doesn't clean up when one does cross-testing or >> installed testing - so it needed tweaking to use the right approach to >> deleting files on the remote/host - we (erm, probably I, in truth) never got >> around to finding the right recipe. >> >> Might I suggest pulling it out of storage - and getting a review, perhaps >> from Mike who might be able to identify the best place to do the job. > > I won’t be too picky. if is_native cleanup_native isn't unreasonable. > > https://gcc.gnu.org/ml/gcc/2012-03/msg00364.html > > So, I can’t help but think, we don’t need to slow the world down, and we can > just do a find . \*.DSYM -exec rm type of thing at the end. Simple, easy, > works for native and the old cross is native ppc builds on x86. Life goes on.
Re: Regular darwin builds
On Dec 16, 2014, at 1:24 PM, Dominique d'Humières wrote:
> My patch is different and I am attaching it (it is quite old, so it may not
> apply cleanly). The problem for more evolved form is that *.dSYM are
> directories and ASAICT there is no command in derange to remove them.
>
> At least my patch tracks all the locations giving *.dSYM.
So, I think it would be better to do:
remote_file build deletedir $dsym_file
And then replace standard_file (from remote.exp) with a patched routine that
adds:
deletedir {
foreach x $args {
if { [file exists $x] && [file isdirectory $x] } {
exec rm -rf $x
}
}
return
}
and:
deletedir {
foreach x $args {
if { [file exists $x] && [file isdirectory $x] } {
exec rm -rf $x
}
}
return
}
and try that. The patched routine can go into dejagnu144-fixes.exp then you
just include this way up at the top from the same thing that include the thing
that includes remote.exp. That patch can be submitted to dejagnu, and when
that comes out, we should just return from the 144-fixes.exp file when the
version number is >= the fixed version.
If that’s too annoying, how about:
remote_file_build_deletedir $dsym_file
and then define that to do the operation, protected by:
if { [is_remote target] } { return }
That’s pretty good, and once we switch to a dejagnu that supports deleting a
directory, we could then remove it and just use remote_file.
It is a shame that there are a zillion places where this idiom is repeated.
What a nightmare. I can’t help but wonder if we aren’t better off just doing:
find $testingdir . -type d -name \*.dSYM -exec rm -rf
at the end of testing, and be done with it, forever, no squirrelly lines all
over the place, and 0 chance it will ever need maintenance or that someone
might add a new fragment that won’t cleanup on darwin. Might even be faster.
Not pretty, but dSYM didn’t start out pretty either. Also, less of an eyesore
in the general code.
Re: trying out openacc 2.0
So what parameters will I need to pass to ./configure if I want to support PTX offloading? So if I want to have CPU, KNL and PTX, do I end up building three compilers? And is it true that running in both the offload mode, and the KNL native mode, would require two set of toolchains? Finally, is the nvptx-tools project mentioned in Tobia's page aiming at replacing the CUDA toolchain? Thanks! Mark On Wed, Dec 17, 2014 at 9:05 AM, Jakub Jelinek wrote: > On Wed, Dec 17, 2014 at 08:54:06AM +1300, Mark Farnell wrote: >> That's good news. Does it mean that if I want to try out openACC with >> KNL and PTX support, then all I need to do is to compile the >> gomp-4_0-branch *without* any extra parameters into ./configure ? > > No. Please read the wiki page Tobias mentioned, you need to build 2 > compilers and pass some configure options to get OpenMP + KNL support. > OpenACC has not been committed to trunk yet, but even when it will make it > in, you'll still need similarly to build 2 compilers and configure them > non-default way. > >> Also, are other GPUs such as the AMD ATI and the built-in GPUs such as >> the Intel GPU and AMD fusion supported? If so, are they already >> supported in the trunk, or only specific branch? > > Some AMD HSA support is on the hsa svn branch, but AFAIK OpenMP 4.0 > offloading nor OpenACC is supported there yet (instead just auto-offloading > some OpenMP 3.x loops I believe). > >> Finally, when will support of Knights Corner (knc) be added to the >> trunk and/or one of the branches? > > Unlikely. The advantage of KNL is that it uses the same vector ISA as > the future desktop/server CPUs, not a different one; to support KNC we'd > need to make the i?86 backend larger and more complicated for something that > is not going to be used in any? future CPUs. > > Jakub
