Re: AW: basic asm and memory clobbers - Proposed solution
On 02/12/15 08:51, Bernd Edlinger wrote:
> On 1.12.2015, David Wohlferd wrote:
> On 12/1/2015 10:10 AM, Bernd Edlinger wrote:
>>> But IMHO asm("bla":) isn't any better than asm("bla").
>>> I think _any_ asm with non-empty assembler string, that
>>> claims to clobber _nothing_ is highly suspicious, and worth to be
>>> warned about. I don't see any exceptions from this rule.
>>
>> There's one right now in the basic asm docs: asm("int $3");
>>
>> And I've seen others: asm volatile ("nop"), asm(".byte 0xf1\n"). I've
>> seen a bunch more, but you get the idea.
>
>
> I disagree.
>
> Consider this example where "nop" should be injected
> to guarantee a minimum pulse length:
>
>
> int x;
>
> x = 1;
> asm volatile ("nop");
> x = 0;
>
> resulting code at -O2 is something like this:
>
> nop
> movl $0,x
>
> That is because this asm statement allows
> gcc to move the assembler code anywhere.
> It is only guaranteed to be executed once,
> but it not guaranteed to be executed between
> the two assignments. To avoid that we have
> to use a "memory" clobber.
>
Surely in code like that, you would make "x" volatile? Memory clobbers
are not a substitute for correct use of volatile accesses.
Re: AW: basic asm and memory clobbers - Proposed solution
Hi,
> Surely in code like that, you would make "x" volatile? Memory clobbers
> are not a substitute for correct use of volatile accesses.
No,
It is as I wrote, a memory clobber is the only way to guarantee that
the asm statement is not move somewhere else.
I changed the example to use volatile and compiled it
with gcc-Version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
volatile int x;
void
test()
{
x = 1;
asm volatile("nop");
x = 0;
}
gcc -S -O2 test.c gives:
test:
.LFB0:
.cfi_startproc
movl$1, x(%rip)
movl$0, x(%rip)
#APP
# 6 "test.c" 1
nop
# 0 "" 2
#NO_APP
ret
.cfi_endproc
While it works with asm volatile("nop" ::: "memory").
Likewise for "cli" and "sti" if you try to implement critical sections.
Although, these instructions do not touch any memory, we
need the memory clobber to prevent code motion.
Bernd.
Re: Solaris vtv port breaks x32 build
Sorry for replying so late: I'd been away from my mail for an extended weekend. Jeff Law writes: > On 12/01/2015 07:17 AM, Ulrich Drepper wrote: >> On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote: >>> that might be another instance of >>> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html >>> Does something like this help? >> >> No, same problem as before. This macro doesn't actually generate any >> code in configure. > From looking at your configure line, I see that > --build = x86_64-redhat-linux > --host = x86_64-redhat-linux > > and no --target > > That to me looks like a native setup and thus I would expect > $cross_compiling to be "no". Hence the behaviour you're seeing. Exactly: it would be good if Ulrich could post the canonical build, host, and target values determined by configure, so we can be sure. > Essentially you've got a native toolchain, but with one or more multilibs > that can't actually be executed. Right: I saw exactly the same behaviour in the distant past when bootstrapping on an IRIX host that couldn't execute 64-bit binaries or on Solaris/SPARC with a non-SPARCv9 capable cpu. At that time, the only workaround was to configure with --disable-multilib. > Which in turn suggests looking more closely at Matthias's suggestion. Exactly: moving AM_ENABLE_MULTILIB up as Matthias suggested sets cross_compiling=maybe for non-default multilibs early, which should achieve the desired behaviour. All other libraries that invoke both macros already do so in this order. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: AW: basic asm and memory clobbers - Proposed solution
On 02/12/15 12:34, Bernd Edlinger wrote:
> Hi,
>
>> Surely in code like that, you would make "x" volatile? Memory clobbers
>> are not a substitute for correct use of volatile accesses.
>
> No,
>
> It is as I wrote, a memory clobber is the only way to guarantee that
> the asm statement is not move somewhere else.
>
> I changed the example to use volatile and compiled it
> with gcc-Version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>
> volatile int x;
> void
> test()
> {
>x = 1;
>asm volatile("nop");
>x = 0;
> }
>
> gcc -S -O2 test.c gives:
>
>
> test:
> .LFB0:
> .cfi_startproc
> movl$1, x(%rip)
> movl$0, x(%rip)
> #APP
> # 6 "test.c" 1
> nop
> # 0 "" 2
> #NO_APP
> ret
> .cfi_endproc
>
>
> While it works with asm volatile("nop" ::: "memory").
> Likewise for "cli" and "sti" if you try to implement critical sections.
> Although, these instructions do not touch any memory, we
> need the memory clobber to prevent code motion.
>
That is clearly a bug in gcc, and not one that I see on my system (gcc
4.5 or gcc 4.9 on amd64). The compiler is not allowed to re-arrange the
order of volatile accesses with respect to each other, and "asm
volatile" counts as a volatile access. The compiler /is/ allowed to
re-arrange volatile and non-volatile accesses, which is why you need
volatiles in the right place (or the sledgehammer approach, a memory
clobber).
It is common to put memory clobbers with instructions like "cli" and
"sti" for critical sections, but that is to help people who don't always
get their "volatile" right (or for those that understand it fine, but
choose memory clobbers as a neater alternative for the code in question).
Re: Solaris vtv port breaks x32 build
On Tue, 1 Dec 2015 09:17:48, Ulrich Drepper wrote: > On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote: > > that might be another instance of > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html > > Does something like this help? > > No, same problem as before. This macro doesn't actually generate any > code in configure. Hmm, did you forget to run autoconf?
Re: Solaris vtv port breaks x32 build
On 02.12.2015 13:29, Rainer Orth wrote: Exactly: moving AM_ENABLE_MULTILIB up as Matthias suggested sets cross_compiling=maybe for non-default multilibs early, which should achieve the desired behaviour. All other libraries that invoke both macros already do so in this order. now committed. 2015-12-02 Matthias Klose * configure.ac: Move AM_ENABLE_MULTILIB before GCC_LIBSTDCXX_RAW_CXX_FLAGS. * configure: Regenerate.
gcc-4.9-20151202 is now available
Snapshot gcc-4.9-20151202 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20151202/ 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 231210 You'll find: gcc-4.9-20151202.tar.bz2 Complete GCC MD5=7cb45f766d7bebf03bef2fe9edb299b5 SHA1=42d5fad2d1b9badda6370c7ba43352fafc2fc7f1 Diffs from 4.9-20151125 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.
Re: AW: basic asm and memory clobbers - Proposed solution
On 12/2/2015 3:34 AM, Bernd Edlinger wrote:
Hi,
Surely in code like that, you would make "x" volatile? Memory clobbers
are not a substitute for correct use of volatile accesses.
No,
It is as I wrote, a memory clobber is the only way to guarantee that
the asm statement is not move somewhere else.
I changed the example to use volatile and compiled it
with gcc-Version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
volatile int x;
void
test()
{
x = 1;
asm volatile("nop");
x = 0;
}
gcc -S -O2 test.c gives:
test:
.LFB0:
.cfi_startproc
movl$1, x(%rip)
movl$0, x(%rip)
#APP
# 6 "test.c" 1
nop
# 0 "" 2
#NO_APP
ret
.cfi_endproc
While it works with asm volatile("nop" ::: "memory").
Likewise for "cli" and "sti" if you try to implement critical sections.
Although, these instructions do not touch any memory, we
need the memory clobber to prevent code motion.
If the goal is to order things wrt x, why wouldn't you just reference x?
x = 1;
asm volatile("nop":"+m"(x));
x = 0;
If you have a dependency, stating it explicitly seems a much better
approach than hoping that the implied semantics of a memory clobber
might get you what you want. Not only is it crystal clear for the
optimizers what the ordering needs to be, people maintaining the code
can better understand your intent as well.
In summary: Yes inline asm can float. Clobbers might help. But I don't
believe this is related to the "remove basic asm in functions" work. If
a warning here is merited (and I'm not yet convinced), a separate case
should be made for it.
However it does seem like a good fit for a section in a "How to convert
basic asm to extended asm" doc. The extended docs don't mention this
need or how extended can be used to address it. It's a good reason for
basic asm users to switch.
dw
building gcc with macro support for gdb?
Is there any way to easily build a stage1 gcc with macro support for debugging? I tried setting CFLAGS, and CXXFLAGS to specify "-O0 -g3" via the command line before running configure, but that only includes those flags for some of the compilation steps. I was only successful after I manually edited the makefile to replace "-g" with "-g3".
Re: building gcc with macro support for gdb?
On Wed, 2015-12-02 at 20:05 -0500, Ryan Burn wrote: > Is there any way to easily build a stage1 gcc with macro support for > debugging? > > I tried setting CFLAGS, and CXXFLAGS to specify "-O0 -g3" via the > command line before running configure, but that only includes those > flags for some of the compilation steps. > > I was only successful after I manually edited the makefile to replace > "-g" with "-g3". Try CFLAGS_FOR_TARGET='-O0 -g3 -fno-inline' and CXXFLAGS_FOR_TARGET='-O0 -g3 -fno-inline' Peter
Re: basic asm and memory clobbers - Proposed solution
On 03.12.2015 00:27 David Wohlferd wrote:
> On 12/2/2015 3:34 AM, Bernd Edlinger wrote:
>> Hi,
>>
>>> Surely in code like that, you would make "x" volatile? Memory clobbers
>>> are not a substitute for correct use of volatile accesses.
>> No,
>>
>> It is as I wrote, a memory clobber is the only way to guarantee that
>> the asm statement is not move somewhere else.
>>
>> I changed the example to use volatile and compiled it
>> with gcc-Version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>
>> volatile int x;
>> void
>> test()
>> {
>> x = 1;
>> asm volatile("nop");
>> x = 0;
>> }
>>
>> gcc -S -O2 test.c gives:
>>
>>
>> test:
>> .LFB0:
>> .cfi_startproc
>> movl$1, x(%rip)
>> movl$0, x(%rip)
>> #APP
>> # 6 "test.c" 1
>> nop
>> # 0 "" 2
>> #NO_APP
>> ret
>> .cfi_endproc
>>
>>
>> While it works with asm volatile("nop" ::: "memory").
>> Likewise for "cli" and "sti" if you try to implement critical sections.
>> Although, these instructions do not touch any memory, we
>> need the memory clobber to prevent code motion.
>
> If the goal is to order things wrt x, why wouldn't you just reference x?
>
>x = 1;
>asm volatile("nop":"+m"(x));
>x = 0;
>
Exactly, that is what I mean. Either the asm can use memory clobber
or it can use output and/or input clobbers or any combination of that.
The problem with basic asm is not that it is basic, but that it does not
have any outputs nor any inputs and it has no way to specify what it
might clobber.
Therefore I think the condition for the warning should not be that the
asm is "basic", but that has zero outputs, zero inputs and zero clobbers.
That would make more sense to me.
Bernd.
> If you have a dependency, stating it explicitly seems a much better
> approach than hoping that the implied semantics of a memory clobber
> might get you what you want. Not only is it crystal clear for the
> optimizers what the ordering needs to be, people maintaining the code
> can better understand your intent as well.
>
> In summary: Yes inline asm can float. Clobbers might help. But I
> don't believe this is related to the "remove basic asm in functions"
> work. If a warning here is merited (and I'm not yet convinced), a
> separate case should be made for it.
>
> However it does seem like a good fit for a section in a "How to
> convert basic asm to extended asm" doc. The extended docs don't
> mention this need or how extended can be used to address it. It's a
> good reason for basic asm users to switch.
>
> dw
Identifying a pointer to a structure
We are implementing points-to analysis in GCC 4.7.2 and need to distinguish
between
pointers to scalars and the pointers to structures. This distinction by using
the TYPE (TREE_TYPE)
hierarchy of the tree node of the pointer. We have two questions:
(a) Is it sufficient to check for the presence of RECORD_TYPE in type hierarchy?
(b) Is it safe to assume that the RECORD_TYPE always appears as a leaf node in
the type description of any pointer to structure?
As an example, the tree nodes of a pointer to an integer (y) and a pointer to a
structure (f)
below. It seems to support our hunch.
For example, the tree node of y which is a pointer to an integer is as follows:
unit size
align 32 symtab 0 alias set 3 canonical type 0x40524360 precision 32 min
max
pointer_to_this >
unsigned SI
size
unit size
align 32 symtab 0 alias set 2 canonical type 0x40524a80
pointer_to_this >
used static unsigned SI file struct0.c line 15 col 11
size
constant 32>
unit size
constant 4>
align 32 context
(mem/f/c:SI (symbol_ref:SI ("y") [flags 0x2] ) [2 y+0
S4 A32])>
_
_ Similarly, the tree node of f which is a pointer to a structure is as follows:
unit size
align 32 symtab 0 alias set 4 canonical type 0x405cf060 fields context
pointer_to_this chain >
public unsigned SI
size
unit size
align 32 symtab 0 alias set 2 canonical type 0x405cf1e0
pointer_to_this >
used static unsigned SI file struct0.c line 14 col 25
size
constant 32>
unit size
constant 4>
align 32 context
(mem/f/c:SI (symbol_ref:SI ("f") [flags 0x2] ) [2 f+0
S4 A32])>
Thanks and regards,
Uday Khedker.
