Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make failing #8

Closed
claczny opened this issue May 20, 2019 · 5 comments
Closed

Make failing #8

claczny opened this issue May 20, 2019 · 5 comments
Labels
compatibility compiler, OS and hardware related issues

Comments

@claczny
Copy link

claczny commented May 20, 2019

Hi,

I just tried do build the latest commit

$ git rev-parse HEAD
42fb5b4f2ff825b2339a8e7b254ec400e822130c

but received the following error:

$ make
  AR       libdeflate.a
  CXX      programs/gunzip.o
In file included from programs/../lib/deflate_decompress.hpp:61:0,
                 from programs/../lib/gzip_decompress.hpp:40,
                 from programs/gunzip.cpp:28:
programs/../lib/input_stream.hpp: In member function ‘bool InputStream::set_position_bits(size_t)’:
programs/../lib/input_stream.hpp:233:16: warning: declaration of ‘bits’ shadows a member of ‘InputStream’ [-Wshadow]
         size_t bits  = bit_pos & 7;
                ^~~~
programs/../lib/input_stream.hpp:282:39: note: shadowed declaration is here
     template<typename T = uint32_t> T bits(bitbuf_size_t n = 8 * sizeof(T)) const
                                       ^~~~
In file included from programs/../lib/deflate_decompress.hpp:58:0,
                 from programs/../lib/gzip_decompress.hpp:40,
                 from programs/gunzip.cpp:28:
programs/../lib/memory.hpp: In instantiation of ‘unique_span<T, D>::unique_span() [with T = unsigned char; D = lock_releaser<std::mutex>]’:
programs/../lib/deflate_decompress.hpp:946:42:   required from here
programs/../lib/memory.hpp:227:21: error: no matching function for call to ‘lock_releaser<std::mutex>::lock_releaser()’
       , _end(nullptr)
                     ^
programs/../lib/memory.hpp:436:39: note: candidate: lock_releaser<std::mutex>::lock_releaser(std::unique_lock<std::mutex>::mutex_type&)
     using std::unique_lock<Lockable>::unique_lock;
                                       ^~~~~~~~~~~
programs/../lib/memory.hpp:436:39: note:   candidate expects 1 argument, 0 provided
programs/../lib/memory.hpp:436:39: note: candidate: lock_releaser<std::mutex>::lock_releaser(std::unique_lock<std::mutex>::mutex_type&, std::defer_lock_t)
programs/../lib/memory.hpp:436:39: note:   candidate expects 2 arguments, 0 provided
programs/../lib/memory.hpp:436:39: note: candidate: lock_releaser<std::mutex>::lock_releaser(std::unique_lock<std::mutex>::mutex_type&, std::try_to_lock_t)
programs/../lib/memory.hpp:436:39: note:   candidate expects 2 arguments, 0 provided
programs/../lib/memory.hpp:436:39: note: candidate: lock_releaser<std::mutex>::lock_releaser(std::unique_lock<std::mutex>::mutex_type&, std::adopt_lock_t)
programs/../lib/memory.hpp:436:39: note:   candidate expects 2 arguments, 0 provided
programs/../lib/memory.hpp:436:39: note: candidate: template<class _Clock, class _Duration> lock_releaser<std::mutex>::lock_releaser(std::unique_lock<std::mutex>::mutex_type&, const std::chrono::time_point<_Clock, _Duration1>&)
programs/../lib/memory.hpp:436:39: note:   template argument deduction/substitution failed:
programs/../lib/memory.hpp:227:21: note:   candidate expects 2 arguments, 0 provided
       , _end(nullptr)
                     ^
programs/../lib/memory.hpp:436:39: note: candidate: template<class _Rep, class _Period> lock_releaser<std::mutex>::lock_releaser(std::unique_lock<std::mutex>::mutex_type&, const std::chrono::duration<_Rep1, _Period1>&)
     using std::unique_lock<Lockable>::unique_lock;
                                       ^~~~~~~~~~~
programs/../lib/memory.hpp:436:39: note:   template argument deduction/substitution failed:
programs/../lib/memory.hpp:227:21: note:   candidate expects 2 arguments, 0 provided
       , _end(nullptr)
                     ^
programs/../lib/memory.hpp:438:5: note: candidate: lock_releaser<Lockable>::lock_releaser(std::unique_lock<_Mutex>&&) [with Lockable = std::mutex]
     lock_releaser(std::unique_lock<Lockable>&& lock) noexcept
     ^~~~~~~~~~~~~
programs/../lib/memory.hpp:438:5: note:   candidate expects 1 argument, 0 provided
programs/../lib/memory.hpp:434:49: note: candidate: lock_releaser<std::mutex>::lock_releaser(lock_releaser<std::mutex>&&)
 template<typename Lockable = std::mutex> struct lock_releaser : private std::unique_lock<Lockable>
                                                 ^~~~~~~~~~~~~
programs/../lib/memory.hpp:434:49: note:   candidate expects 1 argument, 0 provided
make: *** [programs/gunzip.o] Error 1

My compiler:

$ g++ --version
g++ (GCC) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Not sure what I missed here.

Thank you for your input on this issue!

Best,

Cedric

Piezoid added a commit that referenced this issue May 20, 2019
@Piezoid
Copy link
Owner

Piezoid commented May 20, 2019

Thanks for the report.
It should be fixed in master.

It's a suitability in constructor inheritance with older version of GCC. Not sure what happened exactly...

@Piezoid Piezoid added the compatibility compiler, OS and hardware related issues label May 20, 2019
@rchikhi rchikhi closed this as completed May 21, 2019
@Piezoid
Copy link
Owner

Piezoid commented May 21, 2019

Is the problem solved on your side ?
(closing for now, assuming it's resolved)

@claczny
Copy link
Author

claczny commented May 21, 2019

Yes, I could compile and run the bigger_benchmarck.sh.
Thank you for the quick fix!

On our uni.lu HPC on a node with 28 cores, I got 255 MB/s (decompressing with pugz) and 2154 MB/s (counting lines with pugz).

Nice tool :)

@Piezoid
Copy link
Owner

Piezoid commented May 21, 2019

Thanks !

Yes it shows how costly in wall time it is to synchronize threads for output. I think this could be improved.

@rchikhi
Copy link
Collaborator

rchikhi commented May 21, 2019

Also of note, for things like a FASTQ parser, such a costly synchronization won't be necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility compiler, OS and hardware related issues
Projects
None yet
Development

No branches or pull requests

3 participants