GCC: new inter-procedural constant propagation pass

GCC 4.7 has "the inter-procedural constant propagation pass" rewritten, which
brought generic function specialization to C world.

Suppose, we have the following example:

 void foo(bool f)
 {
        char *p;
        if (f) {
                p = (char *) malloc(256);
                if (!p) {
                        printf("Mem alloc error\n");
                        return;
                }
            /* something extremly valuable */
                free(p);
        } else {
                p = (char *) malloc(256);
                if (!p) {
                        printf("Mem alloc error\n");
                        return;
                }
            /* something very important */
                free(p);
        }
}


int main()
{
         foo(TRUE);
         foo(FALSE);
         return 0;
} 

GCC now able to produce the following main():

(gdb) disassemble main
<+0>:    push   %rax
<+1>:    callq  0x4005cc <foo.part.0>
<+6>:    xor    %edi,%edi
<+8>:    callq  0x400649 <foo>
<+13>:    xor    %eax,%eax
<+15>:    pop    %rdx
<+16>:    retq  


Note, that GCC has actually generated two functions:
-- foo.part.0 at 0x4005cc
-- foo at 0x400649

for each possible arg values: TRUE and FALSE.

Since compiler now changes function call code it has to protect himself from "incorrect"
outside calls, e.g. foo(TRUE) instead of foo.part.0(TRUE)

That's the reason "master" copy of foo() has switch() at the beginning:
(gdb) disassemble foo
<+0>:    test   %dil,%dil
<+3>:    je     0x400653 <foo+10>
<+5>:    jmpq   0x4005cc  <foo.part.0>
<+10>:    push   %rbx
<+11>:    mov    $0x40079e,%edi
[...]

ext4 noacl mount option

Brace your mtabs/fstabs/proc/self/mounts!
The error line makes it pretty clear:

EXT4-fs: Mount option "noacl" will be removed by 3.5
Contact linux-ext4@vger.kernel.org if you think we should keep it.

gcc 4.7.0

Hm, is that only happens to me that the same kernel built with gcc 4.7.0
is 11 MiBs bigger than the one built with gcc 4.6.0...

Josuttis on C++11

Nicolai Josuttis talks about C++ and why C++ is not his favorite programming
language

Nicolai Josuttis: You know, I didn’t follow the standardization process of C++11. At the end of 2008 I looked first into the new standard by comparing the C++98/03 versions of classes, such as pair and vector, with their new versions. I was shocked. I had trouble understanding what I found: “What the hell does && mean in declarations?” So if you ask me about the difference, my first answer is: Everything is different! The way you write simple programs and the way you define complicated classes have changed dramatically. C++11's pair<>, for instance, doubled the number of lines.

Nevertheless, the changes go in the right direction. C++11 consequently focuses on the power of C++ -- performance. However, it still has the drawback of making it even harder for programmers to design good classes. Well, it might not be harder, if you know all you have to know; but it’s harder to know all you have to know, now. To some extent, C++11 is a new language, and my new edition simply reflects this change, covering both the new C++ programming style and new classes.

 Please read the full story at informit.com

C++11 ratio

20.10.2 Header synopsis

quote from cppreference 

template<

    std::intmax_t Num,
    std::intmax_t Denom = 1

> class ratio;

The class template std::ratio provides compile-time rational arithmetic support. Each instantiation of this template exactly represents any finite rational number as long as its numerator Num and denominator Denom are representable as compile-time constants of type std::intmax_t.

 typedefs:

typedef ratio<1, 1000000000000000000000000> yocto;
typedef ratio<1,    1000000000000000000000> zepto;
typedef ratio<1,       1000000000000000000> atto;
typedef ratio<1,          1000000000000000> femto;
typedef ratio<1,             1000000000000> pico;
typedef ratio<1,                1000000000> nano;
typedef ratio<1,                   1000000> micro;
typedef ratio<1,                      1000> milli;
typedef ratio<1,                       100> centi;
typedef ratio<1,                        10> deci;
typedef ratio<                       10, 1> deca;
typedef ratio<                      100, 1> hecto;
typedef ratio<                     1000, 1> kilo;
typedef ratio<                  1000000, 1> mega;
typedef ratio<               1000000000, 1> giga;
typedef ratio<            1000000000000, 1> tera;
typedef ratio<         1000000000000000, 1> peta;
typedef ratio<      1000000000000000000, 1> exa;
typedef ratio<   1000000000000000000000, 1> zetta;
typedef ratio<1000000000000000000000000, 1> yotta;

ReFS

Microsoft talks a bit about ReFS -- a new server side file system with some
ZFS and Btrfs features.

phoronix has some good notes for those who interested in short key
features list:

- Unlike NTFS, Microsoft ReFS does share some common traits with Btrfs. ReFS is copy-on-write, provides integrity checksums / ECC, extended attributes, and B-trees. The Sun/Oracle ZFS file-system also shares most of the same features. The storage engine of ReFS is using B+ trees exclusively compared to normal B-trees in Btrfs, with the difference of the plus variant being records stored at the leaf-level of the tree and keys being within the interior nodes.

- ReFS has similar volume/file/directory size limits to EXT4 and Btrfs.

- At least for Windows 8, Microsoft is not providing any upgrade path from NTFS to ReFS, but requires re-formatting the drive and copying any data. Within Windows 8, ReFS is also not supported as a boot partition or for use on removable media/drives.

- Below are the official "key features of ReFS" as said by Microsoft.

- Metadata integrity with checksums
- Integrity streams providing optional user data integrity
- Allocate on write transactional model for robust disk updates (also known as copy on write)
- Large volume, file and directory sizes
- Storage pooling and virtualization makes file system creation and management easy
- Data striping for performance (bandwidth can be managed) and redundancy for fault tolerance
- Disk scrubbing for protection against latent disk errors
- Resiliency to corruptions with "salvage" for maximum volume availability in all cases
- Shared storage pools across machines for additional failure tolerance and load balancing

- ReFS does not support data de-duplication, copy-on-write snapshots (a ZFS and Btrfs feature, but ReFS snapshots can be done when paired with the Microsoft Storage Spaces), file-level encryption (dropped from NTFS), or compression (Btrfs can now do Gzip, LZO, and Snappy).

- In what may partially help supporting ReFS in Linux and other platforms, Steven Sinofsky of Microsoft says, "data stored on ReFS is accessible through the same file access APIs on clients that are used on any operating system that can access today’s NTFS volumes." The upper-layer engine is nearly the same as what's found in NTFS, but it's the underlying on-disk storage engine and format that's changed with ReFS.
Read the full story

GnuPG MPILIB

Looks like the linux kernel 3.3 will have GnuPG MPILIB within.

Multiprecision maths library (MPILIB) [N/m/y/?] (NEW) ?

CONFIG_MPILIB:

Multiprecision maths library from GnuPG.
It is used to implement RSA digital signature verification,
which is used by IMA/EVM digital signature extension.

Symbol: MPILIB [=n]
Type  : tristate
Prompt: Multiprecision maths library
  Defined at lib/Kconfig:288
  Location:
    -> Library routines
  Selected by: DIGSIG [=n] && KEYS [=y]

In-kernel signature checker (DIGSIG) [N/m/y/?] (NEW) ?

CONFIG_DIGSIG:

Digital signature verification. Currently only RSA is supported.
Implementation is done using GnuPG MPI library

Symbol: DIGSIG [=n]
Type  : tristate
Prompt: In-kernel signature checker
  Defined at lib/Kconfig:305
  Depends on: KEYS [=y]
  Location:
    -> Library routines
  Selects: MPILIB [=m]
  Selected by: INTEGRITY_DIGSIG [=n] && INTEGRITY [=n] && KEYS [=y]

Happy New Year!

image via the mockturtle

C/C++ alternative preprocessing tokens

C++ has a set of alternative preprocessing tokens:
2.5/1
 and_eq &=
 and &&
 xor_eq ^=
 or ||
[..]


It turned out that C has them as well:
7.9

The header iso646.h defines the following eleven macros (on the left) that expand to
the corresponding tokens (on the right):

cat 4.6.3/include/iso646.h

#ifndef _ISO646_H
#define _ISO646_H

#ifndef __cplusplus
#define and     &&
#define and_eq  &=
#define bitand  &
#define bitor   |
#define compl   ~
#define not     !
#define not_eq  !=
#define or      ||
#define or_eq   |=
#define xor     ^
#define xor_eq  ^=
#endif

#endif

rq_of_rt_rq...

 kernel/sched_rt.c

 [..]

 113 static void dec_rt_migration(struct sched_rt_entity *rt_se, struct rt_rq *rt_rq)
 114 {
 115         if (!rt_entity_is_task(rt_se))
 116                 return;
 117
 118         rt_rq = &rq_of_rt_rq(rt_rq)->rt;
 119
 120         rt_rq->rt_nr_total--;
 121         if (rt_se->nr_cpus_allowed > 1)
 122                 rt_rq->rt_nr_migratory--;
[..]

Try to read `rt_rq = &rq_of_rt_rq(rt_rq)->rt;' fluently :-)

LinuxFr.org: Interview with Andrew Tanenbaum

Andrew Tanenbaum on Linux, GPL and stuff

LinuxFr.org : Do you think the Linux success is a proof he was right
or is it unrelated?

Andrew Tanenbaum : No, Linux "succeeded" because BSD was frozen out of
the market by AT&T at a crucial time. That's just dumb luck. Also, success
is relative. I run a political website that ordinary people read. On that
site statistics show that about 5% is Linux, 30% is Macintosh (which is BSD
inside) and the rest is Windows. These are ordinary people, not computer
geeks. I don't think of 5% as that big a success story.

2.373

Scott Aaronson writes:

For twenty years, the fastest known algorithm to multiply two n-by-n matrices, due to Coppersmith and Winograd, took a leisurely O(n^2.376) steps.   Last year, though, buried deep in his PhD thesis where hardly anyone saw it, Andy Stothers discussed an improvement to O(n^2.374) steps.  And today,  Virginia Vassilevska Williams of Berkeley and Stanford, released a breakthrough paper that improves the matrix-multiplication time to a lightning-fast O(n^2.373) steps.

...The world will not be the same!

C++11 N2765: user-defined literals

C++11 will have tons of new features and concepts. One among them is
N2765: user-defined literals (scheduled for GCC 4.7). Quite possible I'm dumb
and ugly, but frankly, "user-defined literals" is something I've so many doubts
about. There're already lots of examples, though I haven't seen anything really
neat so far (only speaking for myself).


For example:

constexpr long double operator"" _degrees (long double d)
{
        return d * 0.0175;
}

long double pi = 180_degrees;

Or (link)

typedef std::map MyMap;
MyMap create_map()
{
    MyMap m;
    m["lol"] = 7;
    return m;
}

auto m = create_map();

int& operator "" m(const char *key, size_t length)
{
        return m[key];
}

int main(void)
{
    std::cout << "lol"m << std::endl;
    // 7
    "lol"m = 2;
    std::cout << "lol"m << std::endl;
    // 2
    return 0;
}


Or (link)

template struct __checkbits
{
    static const bool valid = false;
};

template struct __checkbits
{
    static const bool valid = (High == '0' || High == '1')
                   && __checkbits::valid;
};

template struct __checkbits
{
    static const bool valid = (High == '0' || High == '1');
};

template
  inline constexpr std::bitset
  operator"" _bits() noexcept
{
    static_assert(__checkbits::valid, "invalid digit in binary string");
    return std::bitset((char []){Bits..., '\0'});
}

int main()
{
  auto bits = 010101010101010101010101010101010101010101_bits;
  std::cout << bits << std::endl;
  std::cout << "size = " << bits.size() << std::endl;
  std::cout << "count = " << bits.count() << std::endl;
  std::cout << "value = " << bits.to_ullong() << std::endl;

  //  This triggers the static_assert at compile time.
  auto badbits = 21010101010101010101010101010101010101_bits;

  //  This throws at run time.
  std::bitset<64> badbits2("21010101010101010101010110101010101_bits");
}


-ss

GCC 4.7.0: transactional memory

Eventually GCC 4.7.0 will have transactional memory, which has been
merged several days ago. Draft of still-in-progress design document can
be found here.

In short, (atomic) transaction is something similar to this:

    __transaction_atomic { x++; }

Any operation performed within the __transaction_atomic block will be atomic and
isolated from other transactions, operations within __transaction {} either be visible to other threads in its entirety or not at all.

Quote from lwn

Details on the specific implementation are scarce; it appears that, in the current patch set,
transactions will be implemented using a global lock. GCC developers debated for a bit over
whether this code was ready for merging or not. In the end, though, the possibility of being
the first to support an interesting new feature seemed to win out. Current plans are to
release 4.7.0 sometime around next April.

Refer to gcc.gnu.org (or gcc 4.7 svn repository) for details.

Prettiness of git hooks

Haven't blogged for a while, so just to keep this blog alive, some easy reading.
Recently due to project needs we had to organize external .git repository mirror for
code drops. The below notes probably will not discover anything new to you, though
still may be interesting. Just in case.

Well, to start with, we have several developer's trees and one master tree (obviously
for merging, pushing and keeping stuff(tm)). We also have to perform regular code drops
(say, several times a week) with .git directory included. The usual solution could be
just to perform `clone, pull, pull,...' on the remote machine, which, however, didn't
work for us because of some company policies.

So I performed trivial scp of cloned master tree to the remote machine (which is possibly
not the best thing to do, but I didn't feel like doing all that git init, scp files,
git add, git commit with "Initial commit" message, etc.), and cleaned up .git/config.

For scp-ed repo we should perform:
git config --bool core.bare true
otherwise an attempt to push will make git suspicious that you may accidentally screw
things up:
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

The thing is that on the remote side we have to create --tag each time we perform
a code drop. And this is kind of error prone because it's so easy just to forget
perform git tag..., git push --tags.

So I created an alias for tagging on the remote machine

.git/config
[alias]
        datetag = !git tag "project_name_"`date +%Y%m%d%H%M`

(or perhaps time zone aware one via `TZ='REGION/CITY' date +%Y%m%d%H%M`).


The next thing was tagging automation. Which was simply achieved by
git hooks (git book). There are lots of them (you can find examples within
.git/hooks/ directory). In order to enable hook, just remove .sample at the end
of file name.

The ideal candidate was:
post-receive
GIT_DIR/hooks/post-receive
This hook is invoked by 'git-receive-pack' on the remote repository, which happens when a
'git-push' is done on a local repository. It executes on the remote repository once after
all the refs have been updated.


With somewhat trivial implementation:
.git/hooks/post-receive
#!/bin/sh
#
# To enable this hook, rename this file to "post-update".

exec git datetag



Since hooks are shell scripts it's really almost up to you to decide
the level of `complexity' and `sophistication'.


On the local host I created addition 'remote' config
.git/config
[remote "drop"]
        url = git@remote_host_name:/project_repository_path

and set appropriate ssh IdentityFile for Host in ~/.ssh/config file.

So now I can perform
1) git push
for pushing to local master

2) git push drop
for pushing and tagging to the remote host


That's it, git is really awesome.

-ss