Loading ...
Sorry, an error occurred while loading the content.

Re: [ggnfs] Re: lasieve windows 64Bits question

Expand Messages
  • Jeff Gilchrist
    ... Great find, this has been updated in the SVN code so it will not longer produce that output. ... That is a very good question. I m not sure if anyone here
    Message 1 of 9 , Nov 5, 2009
    • 0 Attachment
      On Wed, Aug 26, 2009 at 2:26 PM, lars_dausch<dausch@...> wrote:

      > I found the lines that create the strange output with 64 Bit windows
      > sievers.

      Great find, this has been updated in the SVN code so it will not
      longer produce that output.

      > When you remove the printf line everything looks like in 32Bit mode.
      > The question stays why is this triggered in 64Bit and not in 32 Bit.

      That is a very good question. I'm not sure if anyone here knows the
      answer to that, at lot of stuff in the code is a mystery to many
      people.

      > Then I have another problem with the latest svn version. In redu2.c
      > there is now some code using a function "trunc". The linker comlains about
      > an unresolved external now. So I reverted back to the old version. Can
      > anybody tell me which header I am missing?

      I think that has been updated again so try the latest SVN and it might
      have been removed.

      Jeff.
    • Anton Korobeynikov
      Hello, Everyone ... What was the sort of garbage seen? ... wrong. We have: printf( %d %lu %u ,x,qx,ulqx); x here is of type i16_t qx - u64_t ulqx - u32_t The
      Message 2 of 9 , Nov 6, 2009
      • 0 Attachment
        Hello, Everyone

        > > When you remove the printf line everything looks like in 32Bit mode.
        > > The question stays why is this triggered in 64Bit and not in 32 Bit.
        > That is a very good question. I'm not sure if anyone here knows the
        > answer to that, at lot of stuff in the code is a mystery to many
        > people.
        What was the sort of garbage seen?

        >From the first point of view - the use of format specifiers is totally
        wrong. We have:

        printf("%d %lu %u ",x,qx,ulqx);

        x here is of type i16_t
        qx - u64_t
        ulqx - u32_t

        The %lu format specifier is bogus, since it means "long unsigned int",
        which might (or not, depending on the platform) equal to u64_t.

        The proper solution will be to drop all typedef junk from
        siever-config.h files and use types from stdint.h (and C99 format
        specifiers, if necessary).


        --
        With best regards, Anton Korobeynikov.

        Faculty of Mathematics & Mechanics, Saint Petersburg State University.
      • br_gladman
        ... That wouldn t work for the Windows build because the Microsoft compiler doesn t support most of the C99 stuff and has no stdint.h header file. We could
        Message 3 of 9 , Nov 6, 2009
        • 0 Attachment
          --- In ggnfs@yahoogroups.com, Anton Korobeynikov <asl@...> wrote:
          >
          > Hello, Everyone
          >
          > > > When you remove the printf line everything looks like in 32Bit mode.
          > > > The question stays why is this triggered in 64Bit and not in 32 Bit.
          > > That is a very good question. I'm not sure if anyone here knows the
          > > answer to that, at lot of stuff in the code is a mystery to many
          > > people.
          > What was the sort of garbage seen?
          >
          > >From the first point of view - the use of format specifiers is totally
          > wrong. We have:
          >
          > printf("%d %lu %u ",x,qx,ulqx);
          >
          > x here is of type i16_t
          > qx - u64_t
          > ulqx - u32_t
          >
          > The %lu format specifier is bogus, since it means "long unsigned int",
          > which might (or not, depending on the platform) equal to u64_t.
          >
          > The proper solution will be to drop all typedef junk from
          > siever-config.h files and use types from stdint.h (and C99 format
          > specifiers, if necessary).

          That wouldn't work for the Windows build because the Microsoft compiler doesn't support most of the C99 stuff and has no stdint.h header file. We could import one but I am not sure that's really much different to what we do now.

          Visual Studio 2010 does have stdint.h so this will be less of an issue next year - or even now if we were to move to the Visual Studio 2010 beta (which has a 'go live' license).

          Brian
        • Anton Korobeynikov
          Hello, Brian ... At least we need to use proper format specifiers, since unsigned long is still 32 bits on win64. I was told that stuff from
          Message 4 of 9 , Nov 6, 2009
          • 0 Attachment
            Hello, Brian

            > That wouldn't work for the Windows build because the Microsoft
            > compiler doesn't support most of the C99 stuff and has no stdint.h
            > header file. We could import one but I am not sure that's really much
            > different to what we do now.
            At least we need to use proper format specifiers, since "unsigned long"
            is still 32 bits on win64. I was told that stuff from
            http://code.google.com/p/msinttypes works without any problems. Also, we
            might tweak is slightly and instead of #error'ing in case of non-vcpp
            compiler do #include_next for 'real' stdint.h

            --
            With best regards, Anton Korobeynikov.

            Faculty of Mathematics & Mechanics, Saint Petersburg State University.
          • br_gladman
            ... Hello Anton I haven t tried the one you reference above but I have had trouble with earlier attempts to add inttypes.h to Visual Studio. In fact this might
            Message 5 of 9 , Nov 6, 2009
            • 0 Attachment
              --- In ggnfs@yahoogroups.com, Anton Korobeynikov <asl@...> wrote:
              >
              > Hello, Brian
              >
              > > That wouldn't work for the Windows build because the Microsoft
              > > compiler doesn't support most of the C99 stuff and has no stdint.h
              > > header file. We could import one but I am not sure that's really much
              > > different to what we do now.
              > At least we need to use proper format specifiers, since "unsigned long"
              > is still 32 bits on win64. I was told that stuff from
              > http://code.google.com/p/msinttypes works without any problems. Also, we
              > might tweak is slightly and instead of #error'ing in case of non-vcpp
              > compiler do #include_next for 'real' stdint.h
              >
              > --
              > With best regards, Anton Korobeynikov.
              >
              > Faculty of Mathematics & Mechanics, Saint Petersburg State University.
              >

              Hello Anton

              I haven't tried the one you reference above but I have had trouble with earlier attempts to add inttypes.h to Visual Studio.

              In fact this might soon get worse because Visual Studio 2010 has stdint.h but not inttypes.h. Since inttypes.h includes stdint.h, it is unclear that an external inttypes.h will work smoothly with the pre-existing VS 2010 stdint.h.

              Lets hope it does :-)

              best regards,

              Brian
            Your message has been successfully submitted and would be delivered to recipients shortly.