Clarification required about bitfields

[Konstantin Vladimirov]

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.u33 != 0)
abort();

  exit (0);
}

Compiled on GCC 5.2 passes, compiled on Clang 3.7 aborts. But when I
filed bug https://llvm.org/bugs/show_bug.cgi?id=25852 against clang on
this, it was resolved as invalid with comment that GCC behaves
incorrect here.

How do you think: who is right and should I file this bug in gcc bugzilla now?

---
With best regards, Konstantin

Re: Clarification required about bitfields

[Richard Biener]

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;
>};
>
>struct s a = { 0x10, 0x10, 0x10 };
>
>int
>main (void)
>{
>  if (a.u33 * a.u33 != 0)
>abort();
>
>  exit (0);
>}
>
>Compiled on GCC 5.2 passes, compiled on Clang 3.7 aborts. But when I
>filed bug https://llvm.org/bugs/show_bug.cgi?id=25852 against clang on
>this, it was resolved as invalid with comment that GCC behaves
>incorrect here.
>
>How do you think: who is right and should I file this bug in gcc
>bugzilla now?

GCCs reasoning is that types bigger than long do not promote thus the compute 
happens in a trivially 33bit type.

Richard.

>---
>With best regards, Konstantin

Question on repeating -march flags

[Yuri D'Elia]

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 for the opteron ISA, as if -march=native
had special treatment. Specifying -march=opteron alone works as intended.

Since I generally override the default flags in makefiles by appending
exceptions where needed, I'd sort of expected the regular behavior.

Is this intended? If not, should I try to generate a small test case?

Thanks.

Re: Clarification required about bitfields

[Joseph Myers]

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 unspecified 
(they can only arise when an implementation defines that types other than 
"a qualified or unqualified version of _Bool, signed int, unsigned int" 
can be used to declare bit-fields).

Nothing has ever defined how conversions to store out-of-range values in 
bit-fields (other than _Bool bit-fields) would work for C if an 
implementation defines such a bit-field not to have its own type (whereas 
as noted in DR#120, this all falls out naturally if you treat the type as 
including the width).

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-4.9-20151223 is now available

[gccadmin]

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/gcc-4_9-branch 
revision 231938

You'll find:

 gcc-4.9-20151223.tar.bz2 Complete GCC

  MD5=dad1fb3b90b282c0b266d34c21ee3bba
  SHA1=9acdd251062548a1e73129abe1c81e76f7cdb2a8

Diffs from 4.9-20151216 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

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

[AKASHI Takahiro]

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   Location(49 entries)
-   
  0) 4088  16   __local_bh_enable_ip+0x18/0xd8
  1) 4072  32   _raw_read_unlock_bh+0x38/0x48
  2) 4040  32   xs_udp_write_space+0x44/0x50
  3) 4008  32   sock_wfree+0x88/0x90
  4) 3976  32   skb_release_head_state+0x70/0xa0
 [snip]
 44)  808  32   load_elf_binary+0x29c/0x10d0
 45)  776 224   search_binary_handler+0xbc/0x208
 46)  552  96   do_execveat_common.isra.15+0x4e4/0x690
 47)  456 112   SyS_execve+0x4c/0x60
 48)  344 344   el0_svc_naked+0x24/0x28
--->8---

Here, "Depth" (and hence "Size") is determined, after scanning a stack,
by saved fp pointer (more precisely + 0x10) in a stack frame instead
of (not saved) stack pointer. (Please note that arm64 kernel is always
compiled with -fno-omit-frame-pointer.)

As fp is updated after branching into a function, and allocates not only
a function's stack frame but also callee's local variables, using this
saved value of fp as "Depth", or sp of a caller function, is not
appropriate for calculating a stack size of a function.

So I'd like to introduce a function prologue analyzer to determine
a size allocated by a function's prologue and deduce it from "Depth".
My implementation of this analyzer has been submitted to
linux-arm-kernel mailing list[1].
I borrowed some ideas from gdb's analyzer[2], especially a loop of
instruction decoding as well as stop of decoding at exiting a basic block,
but implemented my own simplified one because gdb version seems to do
a bit more than what we expect here.
Anyhow, since it is somewhat heuristic (and may not be maintainable for
a long term), could you review it from a broader viewpoint of toolchain,
please?

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/393721.html
[2] aarch64_analyze_prologue() in gdb/aarch64-tdep.c


Thanks,
-Takahiro AKASHI