Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 14 20:49
    letmaik opened #39
  • Oct 25 09:35

    szaghi on master

    update submodules update travis config (compare)

  • Oct 25 09:30

    szaghi on master

    update submodules (compare)

  • Oct 25 09:19

    szaghi on master

    update submodules update travis config (compare)

  • Oct 21 06:34
    rakowsk commented #7
  • Oct 20 16:09
    unfurl-links[bot] commented #7
  • Oct 20 16:09
    rakowsk commented #7
  • Oct 12 17:49
    ShatrovOA commented #38
  • Oct 11 15:25
    szaghi labeled #38
  • Oct 11 15:25
    szaghi assigned #38
  • Oct 11 15:25
    szaghi commented #38
  • Oct 11 13:52
    ShatrovOA edited #38
  • Oct 11 13:44
    ShatrovOA opened #38
  • Sep 19 11:19
    szaghi commented #7
  • Sep 19 11:08

    szaghi on master

    Fix parsing bug issue#7 The me… update travis config Merge branch 'release/0.1.0' (compare)

  • Sep 19 11:06

    szaghi on fix-parsing-bug-issue#7

    (compare)

  • Sep 19 07:54

    szaghi on fix-parsing-bug-issue#7

    (compare)

  • Sep 19 07:52
    szaghi commented #7
  • Sep 19 07:51
    szaghi labeled #7
  • Sep 19 07:51
    szaghi assigned #7
Michel Müller
@muellermichel
they have some of the standards committee members here
victorsndvg
@victorsndvg
Great! :+1:
Michel Müller
@muellermichel
@szaghi regarding CUDA Fortran being evil: could you expand a little bit why you think so? just because it's proprietary / closed source, or is there a deeper reason as well?
Stefano Zaghi
@szaghi
@muellermichel Hi Michel, happy to hear you again (I am sorry for my silence, I am doing very few Fortran in last months...). Yes, essentially because I do not like to chain my self to a closed-proprietary, non standard features. The concept is cool, the implementation could be nice (I do not test is), but the fact that is not a standard rather a proprietary extension let me think that it is not worth to spend my time (which time????) to use it
Michel Müller
@muellermichel
the thing is, I'd rather have one vendor to take GPU support on Fortran seriously and do it with proprietary technology, rather than having no good GPU support at all. During my years of doing GPU on Fortran, CUDA Fortran has been the one thing that's actually stable, performant and with reasonable tooling support.
I generally tend to be more pragmatic with these things. I like to make my work open where possible, but I understand when and why corporations choose to monetize things when they have an edge on the market. The encumbents, like AMD, tend to make their stuff open in order to get a foot in the door, so their motives are far from altruistic either. Personally I hope that AMD with their new successes in x86 can get enough cash to catch up o NVIDIA and build up their source compatible version of "CUDA" - so far I'm not aware of much Fortran support there, but that might change when they see what bigger HPC customers require.
chriselrod
@chriselrod

AMD's ROCm can compile C++ to run the GPU with both g++ and their own hipcc compiler (based on Clang).
Would be great to broader support, and more documentation. Not sure what it would take to add support to more llvm-compiled languages (which would include Flang).

Anyone know anything about BRIG? https://www.phoronix.com/scan.php?page=news_item&px=GCC-9.0-BRIG-Improvements
I can't find anything in the latest (8.2) gcc manual https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/
but perhaps something will come of that.

Giacomo Rossi
@giacombum
I start to look to latest OpenMP standard: it seems very promising because it has some intresting instructions and pragmas for GPU offloading. What do you think about it?
Michel Müller
@muellermichel
Haven't tried OpenMP for GPU yet. I didn't have the best experience with OpenACC either, and so far OpenMP appears to be a poorer version of that to me.
matrixbot
@matrixbot
@astrojuanlu:matrix.org hi all 👋🏽
Ondřej Čertík
@certik
Hi, we have recently open sourced LFortran: https://lfortran.org/, it might be of interest to this group.
We have written up the motivation in a blog post: https://lfortran.org/blog/2019/04/why-we-created-lfortran/
Stefano Zaghi
@szaghi
@certik Hi, thanks for alert, I will read the blog post
My new deskpad... do you like it? https://imgur.com/a/I0xynun
@zbeekman How are you?
matrixbot
@matrixbot
captain_solo And there is fortran channel here on Fractal. Amazing!
Stefano Zaghi
@szaghi
@matrixbot :+1:
Stefano Zaghi
@szaghi
Hi guys, I have just faced with an ICE with gfortran 9.1.0 with a finalize TBP
do you know about open bugs regarding finalization TBPs?
@zbeekman
Chris MacMackin
@cmacmackin
According to the latest gfortran info finalization still isn't performed
See gcc.gnu.org/bugzilla/show_bug?I'd=37336
Chris MacMackin
@cmacmackin
Still missing: LHS during intrinsic assignment, function results after use, structure/array constructors after use. There has been no progress or work on this for over 5 years.
Neil Carlson
@nncarlson
And some aspects that supposedly work, don't in some circumstances. The ICE I encountered a couple years ago: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 involved a structure with an array component of a type with a finalizer. Pretty generic stuff. The last comment there shows a workaround.
Stefano Zaghi
@szaghi
Damn, thank you guys. I was surprised because the same library worked for a year with GCC8.x and I have realized about the finalization issue just trying the new GCC9.1
Neil Carlson
@nncarlson
I've had really bad luck this last year with regressions in gfortran. I'd find that some snapshot of 8.2, for example, was finally working for me, only to discover a couple months later that some commit in the meantime had broken it in some other way. I think it's a combination of an inadequate test suite and a compiler code base that has grown far too complicated for the developers to fully understand the way they really need to. (Obligatory link to big ball of mud http://www.laputan.org/pub/foote/mud.pdf)
Stefano Zaghi
@szaghi
Hi guys, I am thinking to start to use Paramatrized Derived Type. How is matute its implementations in GNU Fortran and Intel Fortran Compilers? Have you experience with PDT on these two compilers?
Neil Carlson
@nncarlson
The PDT implementation gfortran is broken, being based on a fundamental misunderstanding of the standard it appears to me. It uses invalid syntax and rejects valid syntax. I think the basic issue is that it has implemented the type parameters as regular components of the type, and they are absolutely not. This is particularly apparent when it comes to arrays of a PDT. I uncovered this a year or two ago when I was working through the gfortran test suite as applied to the NAG compiler, and I submitted a number of gfortran bug reports on PDT which are still open. Paul Thomas has the intention of going back and fixing things, but he just hasn't found the time yet.
Neil Carlson
@nncarlson
I've played a bit with PDT with the Intel and NAG compilers and there are still some issues, so I've avoided them for the time being. I also had a discussion way back with a NAG developer who indicated that there were significant performance issues with the length parameters, particularly when composing types. I didn't understand what that was all about, but it's made me very leery about taking the plunge.
Rand Huso
@rchuso
Thanks @nncarlson - I've been trying to build up some code with PDT, but the FINAL method is being rejected for no apparent reason that I can see. Works without the parameters; with them the other methods compile but not the FINAL. I'm using gfortran 8.3.0 from the Ubuntu 8.3.0-6ubuntu1-19-04.1 Linux Mint. I'll try without the LEN parameters. And if anyone has a good example of gfortran working with parameterized types, please link it for me.
Stefano Zaghi
@szaghi
@nncarlson thank you very much. I have played few days with PDT with both GNU and Intel compilers and both seem to have bugs (GNU is particurally not usable, I faced with severe bug).
I am now really in trouble because I discovered that some of my libraries are not standard compliant and I do not know how to achieve a sort of kind-parametrization while being standard...
Damian Rouson
@rouson
This is a great time to report PDT issues to the gfortran mailing list and submit reports via Bugzilla. Paul Thomas, who implemented PDT support, is going to be focusing on improving PDT support in gfortran in the coming weeks or months.
Stefano Zaghi
@szaghi
@rouson I will try to submit my issues, bugzilla is indeed really a nigthmare for me... but I will try