Announcement

Collapse
No announcement yet.

PathScale Open-Sources The EKOPath 4 Compiler Suite

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Hi,

    I just tried to build Python 2.7.2 with the nightly build (I'm running Debian testing) and IPA, and sadly it segfaulted (pathcc, not python).

    This is exactly what I did:
    Code:
    CC=pathcc CFLAGS="-ipa" LDFLAGS="-ipa" ./configure --without-gcc
    make
    The resulting output is the following: http://bpaste.net/show/16987/

    I used clean sources, of course.
    Now I know this is not the bugtracker for ekopath, but I didn't find a better place to post it, so here you go. Maybe the result is useful to others, too^^

    Comment


    • Trying to compile minerd, Olimit was exceeded, so I put -OPT:Olimit=0 in CFLAGS and tried again, but I got another error:
      Code:
      ### Assertion failure at line 1892 of /var/jenkins/workspace/Linux_Packages/src/compiler/src/be/cg/cgemit.cxx:
      ### Compiler Error in file sha256_4way.c during Assembly phase:
      ### Result and the first opnd use different register.
      Here's the output of both compilation attempts:
      Without Olimit=0, With Olimit=0.

      Is it the compiler, the program, or my lack of RAM? Looking at top, it didn't look like anything was using much RAM, though.

      Edit: It actually gets a little further with -Ofast, but still fails with the same error (in a different file, "minerd.ipatAOIwM/1.I").
      Last edited by Nobu; 20 June 2011, 12:19 AM.

      Comment


      • I've investigated a bit the question why path64 / open64 is a lot faster than gcc in the c-ray benchmark and the reason seems to be that gcc is not as aggressively inlining functions as path64 / open64 do.

        http://openbenchmarking.org/result/1...D1SA-CRAYCOM67

        So if you use -finline-limit to tweak gcc, gcc takes the lead again

        Comment


        • Originally posted by d1saster View Post
          I've investigated a bit the question why path64 / open64 is a lot faster than gcc in the c-ray benchmark and the reason seems to be that gcc is not as aggressively inlining functions as path64 / open64 do.

          http://openbenchmarking.org/result/1...D1SA-CRAYCOM67

          So if you use -finline-limit to tweak gcc, gcc takes the lead again
          So I guess that since ekopath says "if it's not faster, report it as a bug", they'll get a hell of a lot of bug reports

          Comment


          • WARNING

            it seems, peoples are NOT alowed to share binaries compiled with the opensourceEkoPath!

            http://linuxcommercial.blogspot.com/...ke-is-lie.html

            Comment


            • Originally posted by Geri View Post
              WARNING

              it seems, peoples are NOT alowed to share binaries compiled with the opensourceEkoPath!

              http://linuxcommercial.blogspot.com/...ke-is-lie.html
              That blog post looks like it was written by a child. I wouldn't trust a word it says.

              Comment


              • If you compare the nickname, you'll notice that the guy who posted it here is also the author of the blog post.

                Comment


                • Originally posted by Geri View Post
                  WARNING

                  it seems, peoples are NOT alowed to share binaries compiled with the opensourceEkoPath!

                  http://linuxcommercial.blogspot.com/...ke-is-lie.html
                  They haven't said anything about the matter (looking only at that IRC log). They only expressed that they don't like you in a very rude way (which isn't deserved IMO, cause the GPL allows that usage, and you asked nicely).

                  If it's GPL then there's nothing to worry about, despite what a random guy says in an IRC.

                  Comment


                  • Originally posted by bwat47 View Post
                    That blog post looks like it was written by a child. I wouldn't trust a word it says.
                    On the other hand, the person he was conversing with (if indeed the chat log isn't forged) is the CTO of PathScale. If he's behaving this way towards the inquirer, either he asked a _really_ stupid question in chat that the blogger chose not to post, or else Mr. Codestrom really hates people/projects who try to use EkoPath for proprietary applications.

                    However, you have to keep in mind that, if the EkoPath compiler is indeed released under a mix of the unmodified GNU GPL and MIT/X11/BSD licenses, none of those licenses restrict the use of a compiler for proprietary applications in any way. In fact, they would be contradicting the licensing terms upon which they released the software if they tried to prevent you from doing that. This would be as much of a breach of contract (on their behalf) as you violating the terms of the license as written. Any attempt to string you up in court on this point would be dismissed and PathScale would be charged your legal fees.

                    Of course, with the proprietary / trialware EkoPath as available on their website, that's a whole different story. I have no idea what license that is under, and it may very well prohibit compiling and distributing proprietary applications.

                    Comment


                    • That was not a random guy. Hes got op rights and that was the official support channel and i think that was the CTO. Notice the nicknames end: codestr0m


                      "For the past 2 years PathScale has engaged more and more in the open source community and this marks a turning point with a full commitment, our core product the EKOPath 4 Compiler Suite going open source," says C. Bergstrom, PathScale CTO.

                      Comment

                      Working...
                      X