Clarification required about bitfields

Hi, Now LLVM and GCC essentially disagrees on simple test (minimized from one of dejagnu tests): #include struct s { unsigned long long u33: 33; unsigned long long u40: 40; unsigned long long u41: 41; }; struct s a = { 0x10, 0x10, 0x10 }; int main (void) { if (a.u33 * a.u3

Re: Clarification required about bitfields

On December 23, 2015 9:28:32 AM GMT+01:00, Konstantin Vladimirov wrote: >Hi, > >Now LLVM and GCC essentially disagrees on simple test (minimized from >one of dejagnu tests): > >#include > >struct s { > unsigned long long u33: 33; > unsigned long long u40: 40; > unsigned long long u41: 41; >};

Question on repeating -march flags

I couldn't find anything on the matter, but what happens if -march is repeated more than once? I would assume the usual behavior that the last flag "wins". On a haswell host, the following: gcc -march=native -march=opteron or gcc -march=opteron -march=native both emit code which is illegal fo

Re: Clarification required about bitfields

See the WG14 reflector thread starting with , and the reference back to the analysis of the textual history in . Effectively, you can treat choices in this area as being implementation-defined or unspec

gcc-4.9-20151223 is now available

Snapshot gcc-4.9-20151223 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20151223/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

[RFC][AArch64] function prologue analyzer in linux kernel

Hi, I'm the author of ftrace support on arm64(aarch64) linux. As part of ftrace, we can utilize "stack tracer" which reports the maximum usage of kernel stack: ---8<--- # cat /sys/kernel/debug/tracing/stack_max_size 4088 # cat /sys/kernel/debug/tracing/stack_trace DepthSize Locatio