Fix build
Fix namespace issue on isnan/isinf on OS X
Bug fix with instance merging -- never merge the group entry layer.

It turns out that it's a bad idea to do "instance merging" of the last
layer, also known as the "group entry" layer. It's very rare that the
circumstances would lead to it in any real world shader groups, but I
ran across it in a contrived layered example (with two layers of the
same shader master, no connections, same instance parameter values, no
outputs used) The bottom line is that the group entry layer must
generate a proper LLVM function, and having it marked as "unused"
because of merging leads to a cascade of hard-to-understand errors.
Allow renderer outputs to be specified as "layer.param".

This allows you to designate a named output to be a "renderer output"
(thus immune from unused output elision, among other things) only if it
is part of a particular layer, if you so desire. Of course, you can just
give a plain unqualified name, too, which would designate ANY outputs of
the same name (in any layer) as being so preserved, as it always has
worked.

As an example, this may come in handy if you have shader group where a
bunch of the instances have output parameters named "Cout", but only a
particular one is designated as needing to be queried by the renderer
after shader execution (so the others may be free to be optimized away).

Because this makes the instance->is_renderer_output() test much more
expensive (because it needs to concatenate the string), we also refactor
slightly so the "is it an output" test is done just once for each
instance param at the start of runtime optimization, the result stored
in a bit in the Symbol struct, so can be very easily tested the zillions
of times the optimizer may need to know.
Fix bug in assigning elements of struct arrays.

This kind of thing:

    struct S { float x; }
    S a[2];
    a[1] = a[0];

The generated code would not properly copy a[0].x to a[1].x.

LG is submitting this, but the patch is actually from Derek Haase.
LG confirms that it fixes the bug, doesn't break anything else, and
looks correct.
Spec: add a chapter explaining our standard serialization syntax for shader groups
Rebuild PDF spec
CHANGES and docs fixes
OSLQuery: reliably tell when no constant default is available for a param.

There's always been a 'validdefault' field in the OSLQuery::Parameter
structure, but it was always set to true.

* oslc -- add a %initexpr hint in the oso for parameters that are initialized
  by expressions (like myparam = u, or myparam = noise(P), i.e. is not a
  constant value at shader compilation time.

* oslquery -- if this hint is encountered for a parameter, mark its
  valliddefault = false.

Thus, a program using OSLQuery ought to be able to check the validdefault
field, and if it's true, the default constant is valid, but if it's false,
you can't count on the default constant being the true default.
Compilation error fix for strict compiler flags
Allow memory-aligned closure component classes

The root of the issue which this change is addressed to solve is related
on fact that sometimes external defined closure classes might want to be
aligned to some boundary in memory in order to utilize SIMD instructions.

Adding alignment attributes to such classes might give compiler some tips
about possible optimization (which are hidden to developer). And the issue
is that compiler thinks such classes are being allocated using genuine C++
allocation, which takes care of alignment. This case is being violated by
the ClosureRegistry which allocates closures in a pool.

With such way of class allocation it's nearly impossible to use SIMD in
the closure classes, because there's no way to make sure data is properly
aligned in memory.

One of the possible solutions is to not use SIMD in the closures, but
this becomes a real PITA to glue the SIMD logic of the rest of the render
engine with non-SIMD-aware storage of the closure itself.

Better solution is to make memory pool aware of memory alignment requests
and allow external engines to declare if the closure needs to be aligned
in the memory.

This commit tries to implement this logic, and it's more or less straight
forward.

To be mentioned, the SimplePool now allows non-aligned size to be allocated
in the pool. It seemed quite an artificial limitation which i'm not sure why
it'll give issues.

System aligned malloc functions doesn't have such limitation and this gives
some flexibility IMO.
credits