Re: Deprecating basic asm in a function - What now?
On 06/20/2016 07:40 PM, Andrew Haley wrote: > On 20/06/16 18:36, Michael Matz wrote: >> I see zero gain by deprecating them and only churn. What would be the >> advantage again? > > Correctness. It is very likely that many of these basic asms are not > robust in the face of compiler changes because they don't declare > their dependencies and therefore work only by accident. But the correctness problem is much more severe with extended asm. With basic asm, the compiler can be conservative. With extended asm, there is an expectation that it is not, and yet many of the constraints out there are slightly wrong and can lead to breakage any time. Florian
Re: Deprecating basic asm in a function - What now?
On 06/21/2016 06:53 PM, Andrew Haley wrote: > Me too. I wonder if there's anything else we can do to make basic asm > in a function a bit less of a time bomb. GCC could parse the assembly instructions and figure out the clobbers. Florian
Re: .debug_frame not generated by ARC gas
On Thursday 16 June 2016 09:44 PM, Vineet Gupta wrote: > Hi, > > ARC Linux has an in-kernel dwarf unwinder which has historically consumed > .debug_frame. The kernel is built with -gdwarf-2 and > -fasynchronous-unwind-tables > toggles which until recently used to generate both .debug_frame and .eh_frame > - > latter being discarded by the kernel linker script. > > With a recent ARC gas change to support asm cfi psuedo-ops - dwarf info is now > generated by gas and NOT gcc. But more importantly, we no longer get > .debug_frame > with above 2 toggles. If we drop -fasynchronous-unwind-tables then > .debug_frame is > generated. > > So here are the questions: > 1. Is it OK to drop -fasynchronous-unwind-tables toggle and still assume that > "precise" unwind info will be generated (as mentioned in gnu documentation) > 2. If not, how do we coax gas to generate .debug_frame even in presence of > -fasynchronous-unwind-tables Ping ! Apologies for explicit CC. Any response would be much appreciated ! -Vineet
Re: Deprecating basic asm in a function - What now?
In the end, my problems with basic-asm-in-functions (BAIF) come down to
reliably generating correct code.
Optimizations are based on the idea of "you can safely modify x if you
can prove y." But given that basic asm are opaque blocks, there is no
way to prove, well, much of anything. Adding 'volatile' and now
'memory' do help. But the very definition of "opaque blocks" means that
you absolutely cannot know what weird-ass crap someone might be trying.
And every time gcc tweaks any of the optimizers, there's a chance that
this untethered blob could bubble up or down within the code. There is
no way for any optimizer to safely decide whether a given position
violates the intent of the asm, since it can have no idea what that
intent is. Can even a one line displacement of arbitrary assembler code
cause race conditions or data corruption without causing a compiler
error? I'll bet it can.
And also, there is the problem of compatibility. I am told that the
mips "sync" instruction (used in multi-thread programming) requires a
memory clobber to work as intended. With that in mind, when I see this
code on some blog, is it safe?
asm("sync");
And of course the answer is that without context, there's no way to
know. It might have been safe for the compiler in the blogger's
environment. Or maybe he was an idiot. It's certainly not safe in any
released version of gcc. But unless the blog reader knows the blogger's
level of intelligence, development environment, and all the esoteric
differences between that environment and their own, they could easily
copy/paste that right into their own project, where it will compile
without error, and "nearly always" work just fine...
With Bernd's recent change, people who have this (incorrect) code in
their gcc project will suddenly have their code start working correctly,
and that's a good thing. Well, they will a year or so from now. If
they immediately start using v7.0. And if they prevent everyone from
trying to compile their code using 6.x, 5.x, 4.x etc where it will never
work correctly. So yes, it's a fix. But it can easily be years before
this change finally solves this problem. However, changing this to use
extended:
asm("sync":::"memory");
means that their very next source code release will immediately work
correctly on every version of gcc.
You make the point about how people changing this code could easily muck
things up. And I absolutely agree, they could. On the other hand, it's
possible that their code is already mucked up and they just don't know
it. But even if they change this code to asm("sync":::) (forcing it to
continue working the same way it has for over a decade), the
programmer's intent is clear (if wrong). A knowledgeable mips
programmer could look at that and say "Hey, that's not right." While
making that same observation with asm("sync") is all but impossible.
BAIF is fragile. That, combined with: unmet user expectations, bad user
code, inconsistent implementations between compilers, changing
implementations within compilers, years of bad docs, no "best practices"
guide and an area that is very complex all tell me that this is an area
filled with unfixable, ticking bombs. That's why I think it should be
deprecated.
Other comments inline:
On 20/06/16 18:36, Michael Matz wrote:
I see zero gain by deprecating them and only churn. What would be the
advantage again?
Correctness.
As said in the various threads about basic asms, all correctness
problems can be solved by making GCC more conservative in handling them
(or better said: not making it less conservative).
If you talk about cases where basic asms diddle registers expecting GCC to
have placed e.g. local variables into specific ones (without using local
reg vars, or extended asm) I won't believe any claims ...
It is very likely that many of these basic asms are not
robust
... of them being very likely without proof.
I don't have a sample of people accessing local variables, but I do have
one where someone was using 'scratch' registers in BAIF assuming the
compiler would just "handle it." And before you call that guy a dummy,
let me point out that under some compilers, that's a perfectly valid
assumption for asm. And even if not, it may have been working "just
fine" in his implementation for years. Which doesn't make it right.
They will have stopped
working with every change in compilation options or compiler version. In
contrast I think those that did survive a couple years in software very
likely _are_ correct, under the then documented (or implicit) assumptions.
Those usually are: clobbers and uses memory, processor state and fixed
registers.
As I was saying, a history of working doesn't make it right. It just
means the ticking hasn't finished yet.
How would you know if you have correctly followed the documented rules?
Don't expect the compiler to flag these violations for you.
in t
Re: Deprecating basic asm in a function - What now?
On 6/21/2016 9:43 AM, Jeff Law wrote: > I think there's enough resistance to deprecating basic asms within a function that we should probably punt that idea. I don't disagree that there has been pushback. I just wish less of it was of the form "Because I don't wanna." A few examples of "Here's something that has to be in basic asm because..." might have produced a more interesting discussion. I think if people had to defend (even to themselves) why they were using BAIF, there might be more converts. And I *get* that it takes time to re-write this, and people have schedules, lives, a need for sleep. But even under the most insanely aggressive schedule I can imagine (if gcc continue to release ~1/year), it will be at least a year before there's a release that has the (disable-able) warning, and another year before we could even think about actually removing this. So someone who plans to use v8.0 in their production code on the day it is released still has a minimum of *two years* to get ready. > I do think we should look to stomp out our own uses of basic asms within functions just from a long term maintenance standpoint. Fixes.patch (from the start of this thread) seems mostly uncontested. Send it to patches? If someone wanted to clean up a bunch of these, they should take a look at CRT_CALL_STATIC_FUNCTION in gcc/config. This is defined for nearly every platform, and most of them do it with basic asm. I gotta wonder if there's a better way to do this. Isn't there an attribute for 'section'? > Finally I think we should continue to bring the implementation of basic asms more in-line with expectations and future proofing them I believe there are compilers that do safely use inline asm. However it appears that they accomplish this trick by parsing the asm. Not something I expect to see added to gcc anytime soon... > since I'm having a hard time seeing a reasonable path to deprecating their use. Umm. Hmm. Seems like the ideal answer here would be something that prevents new code from using BAIF, without putting the old-timers in an uproar. So how about the old "empty threat" gambit? We could *say* we are going to deprecate it, put the (disable-able) warning into the code and the stern-sounding text in the docs, and then *leave* it like that for a decade or so. The idea being that new code won't use it, but old code will still be supported. Hopefully 10 years from now, there might be so little code that uses BAIF that finally removing it may no longer be so controversial. It's not a lie, since deprecate means "express disapproval of" and yeah, that's about right. And since we don't specify precisely *when* we intend to remove it... dw
Re: Deprecating basic asm in a function - What now?
On Wed, Jun 22, 2016 at 02:23:46AM -0700, David Wohlferd wrote: > I don't have a sample of people accessing local variables, but I do have one > where someone was using 'scratch' registers in BAIF assuming the compiler > would just "handle it." And before you call that guy a dummy, let me point > out that under some compilers, that's a perfectly valid assumption for asm. > And even if not, it may have been working "just fine" in his implementation > for years. Which doesn't make it right. And how would deprecation of basic asm help with that? People can as well use 'scratch' registers in extended asm without mentioning them in outputs or clobbers (and there are many real-world examples of that that sometimes happen to "work" by accident). > On the other hand, there is no guarantee that they are actually correct > right now. Correct enough? Maybe so. But of course there's no guarantee > that tomorrow's newest optimization won't bork some of them because it > followed the rules and you didn't quite. You don't have such guarantee for extended asm either, lots of them are just ticking bombs that will fail when anything in the compiler is changed. Jakub
Re: Deprecating basic asm in a function - What now?
On 22/06/16 09:59, Florian Weimer wrote: > On 06/20/2016 07:40 PM, Andrew Haley wrote: >> On 20/06/16 18:36, Michael Matz wrote: >>> I see zero gain by deprecating them and only churn. What would be the >>> advantage again? >> >> Correctness. It is very likely that many of these basic asms are not >> robust in the face of compiler changes because they don't declare >> their dependencies and therefore work only by accident. > > But the correctness problem is much more severe with extended asm. With > basic asm, the compiler can be conservative. With extended asm, there > is an expectation that it is not, and yet many of the constraints out > there are slightly wrong and can lead to breakage any time. Yes, that's true. However, at least in the case of extended asm there is a chance that the programmer has thought about it. But anyway, the decision has been made. None of this matters. Andrew.
Re: Deprecating basic asm in a function - What now?
On Mon, Jun 20, 2016 at 08:01:24PM +0200, Michael Matz wrote:
> You see, the experiment shows that there's a gazillion uses of basic asms
> out there.
I applied the proposed patch and built myself an allyesconfig AArch64 linux
kernel, the results were not pretty...
make | grep "warning: Deprecated: asm" | wc -l
8911
You could say I'm cheating as the asm in question appears in header files,
but this would be more than enough noise to guarantee the kernel will be
built with your warning disabled (and when the Linux kernel switches a
warning off, history suggests it won't be coming back on!). Remember that
while you might convince people to apply the proper fix for kernel version
N, you might struggle to get that fix backported across stable releases,
vendor releases, private releases etc. particularly when the alternative
fix of silencing the warning will appear to work fine.
There are 11 unique warnings for an arm64 Linux kernel build, 7 unique
warnings for an arm kernel build and 369 unique warnings for an x86_64
kernel build. Just for fun I counted how many warnings I get with x86_64
allyesconfig without filtering for unique; 14,697.
I haven't audited them to see which would be safe with the minimal changes
given in https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended (that document
looks buggy, should it not reccommend that you always add a volatile when
moving from basic to extended?). The sorts of things I see in the arm/arm64
port are sleep loops for CPUs guarded by a conditional, asm guarded by other
asm barriers, text added to mergeable read-only section for common strings,
other things that are not obviously broken uses of basic asm.
On the other hand, some of the the x86_64 examples in lib/raid6/sse2.c are
super scary and have back-to-back instructions with hard-coded registers...
asm volatile("pcmpgtb %xmm4,%xmm5");
asm volatile("paddb %xmm4,%xmm4");
asm volatile("pand %xmm0,%xmm5");
I can't defend them, and they look very fragile! Fixing this code would
require more substantial work.
I'm only looking at one consumer of our compiler here, but I think anything
that would cause the kernel community this much pain is a risky move, and is
indicative of how frequently we'd see this warning fire in the wild.
Permanently removing basic asm in a future GCC version is certainly not a
workable solution. So what is the value of a noisy warning?
Jeff and others have already come out against this patch, I'd like to add
my vote against it too.
Thanks,
James
Re: Deprecating basic asm in a function - What now?
On 06/22/2016 09:23 AM, James Greenhalgh wrote:
On the other hand, some of the the x86_64 examples in lib/raid6/sse2.c are
super scary and have back-to-back instructions with hard-coded registers...
asm volatile("pcmpgtb %xmm4,%xmm5");
asm volatile("paddb %xmm4,%xmm4");
asm volatile("pand %xmm0,%xmm5");
I can't defend them, and they look very fragile! Fixing this code would
require more substantial work.
Yow! This kind of crap is all over that file. Fragile indeed!
Jeff and others have already come out against this patch, I'd like to add
my vote against it too.
To be clear, given all I've seen I would actively object at this point.
We can't inflict this much pain on the user base.
jeff
Re: Deprecating basic asm in a function - What now?
On 22/06/16 10:02, Florian Weimer wrote: On 06/21/2016 06:53 PM, Andrew Haley wrote: Me too. I wonder if there's anything else we can do to make basic asm in a function a bit less of a time bomb. GCC could parse the assembly instructions and figure out the clobbers. Which is also needed for various things, such as providing better diagnostics: http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/70335 http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html https://www.reddit.com/r/programming/comments/bnhxb/clang_now_with_inline_assembly_diagnostics/ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 Of course, that would require a closer integration with binutils. There has been some work in that direction in the past: https://sourceware.org/ml/binutils/2015-06/msg00010.html but like the GCC-GDB integration, it seems to have stalled or be happening behind closed doors. Cheers, Manuel.
Re: Deprecating basic asm in a function - What now?
On Wed, Jun 22, 2016 at 10:59 AM, Manuel López-Ibáñez wrote: > On 22/06/16 10:02, Florian Weimer wrote: >> >> On 06/21/2016 06:53 PM, Andrew Haley wrote: >>> >>> Me too. I wonder if there's anything else we can do to make basic asm >>> in a function a bit less of a time bomb. >> >> >> GCC could parse the assembly instructions and figure out the clobbers. > > > Which is also needed for various things, such as providing better > diagnostics: > > http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/70335 Actually GCC outputs markers that modern gas understands and you get much better diagnostic already compared to what was reported above. Note each target in gas has its own way of parsing assembly code which is one of the reason why it is so hard todo the above and also each target has its own wording which can confuse people. I think if you want better diagnostic from assembly code, then working on binutils to unify things including error messages (and subtarget support) would be a much better use of time than integrating binutils into gcc. Thanks, Andrew > http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html > https://www.reddit.com/r/programming/comments/bnhxb/clang_now_with_inline_assembly_diagnostics/ > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 > > Of course, that would require a closer integration with binutils. There has > been some work in that direction in the past: > https://sourceware.org/ml/binutils/2015-06/msg00010.html > > but like the GCC-GDB integration, it seems to have stalled or be happening > behind closed doors. > > Cheers, > > Manuel.
Should we import gnulib under gcc/ or at the top-level like libiberty?
Hi, I am working on importing gnulib library inside the gcc tree. Should the library be imported in the top level directory along with other libraries (like libiberty, libatomic, liboffloadmic etc), or should it be imported inside gcc/ like it is done in the binutils-gdb tree. There they have a gnulib directory inside gdb/ in the top level directory. -- Thanks, Ayush Goel
Re: Deprecating basic asm in a function - What now?
On 22 June 2016 at 19:05, Andrew Pinski wrote: > On Wed, Jun 22, 2016 at 10:59 AM, Manuel López-Ibáñez > wrote: >> On 22/06/16 10:02, Florian Weimer wrote: >>> GCC could parse the assembly instructions and figure out the clobbers. >> >> >> Which is also needed for various things, such as providing better >> diagnostics: >> >> http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/70335 > > Actually GCC outputs markers that modern gas understands and you get > much better diagnostic already compared to what was reported above. We get better diagnostics than in the past, but not as good as Clang's. And there are many limitations of the "markers" approach: Not only there is no column info, line info is often wrong: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 And there remains a lot of work to get GAS to output diagnostics like GCC does nowadays (colors, caret, fix-it hints, etc.). And additional work to make GAS obey GCC settings (if GCC disables colors, then GAS should not output colors). Most of that work will be duplication of what GCC already does. Besides diagnostics, the integrated assembler is faster (as proven by David Malcom's experiments) and it provides additional info to GCC (the point raised by Florian). > Note each target in gas has its own way of parsing assembly code which > is one of the reason why it is so hard todo the above and also each > target has its own wording which can confuse people. I think if you I didn't say it was easy. Yet, Clang/LLVM did it. > want better diagnostic from assembly code, then working on binutils to > unify things including error messages (and subtarget support) would be > a much better use of time than integrating binutils into gcc. Unifying error messages does not seem to be a feature used to advertise Clang as a replacement for GCC. It doesn't seem to be what users discuss in various forums (including the reddit thread I quoted above). It won't help with the issues discussed in this thread. Cheers, Manuel.
Re: Deprecating basic asm in a function - What now?
On Wed, Jun 22, 2016 at 12:26 PM, Manuel López-Ibáñez wrote: > On 22 June 2016 at 19:05, Andrew Pinski wrote: >> On Wed, Jun 22, 2016 at 10:59 AM, Manuel López-Ibáñez >> wrote: >>> On 22/06/16 10:02, Florian Weimer wrote: GCC could parse the assembly instructions and figure out the clobbers. >>> >>> >>> Which is also needed for various things, such as providing better >>> diagnostics: >>> >>> http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/70335 >> >> Actually GCC outputs markers that modern gas understands and you get >> much better diagnostic already compared to what was reported above. > > We get better diagnostics than in the past, but not as good as > Clang's. And there are many limitations of the "markers" approach: Not > only there is no column info, line info is often wrong: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 > > And there remains a lot of work to get GAS to output diagnostics like > GCC does nowadays (colors, caret, fix-it hints, etc.). And additional > work to make GAS obey GCC settings (if GCC disables colors, then GAS > should not output colors). Most of that work will be duplication of > what GCC already does. > > Besides diagnostics, the integrated assembler is faster (as proven by > David Malcom's experiments) and it provides additional info to GCC > (the point raised by Florian). > >> Note each target in gas has its own way of parsing assembly code which >> is one of the reason why it is so hard todo the above and also each >> target has its own wording which can confuse people. I think if you > > I didn't say it was easy. Yet, Clang/LLVM did it. That is because there are less targets on the Clang/LLVM side of things. > >> want better diagnostic from assembly code, then working on binutils to >> unify things including error messages (and subtarget support) would be >> a much better use of time than integrating binutils into gcc. > > Unifying error messages does not seem to be a feature used to > advertise Clang as a replacement for GCC. It doesn't seem to be what > users discuss in various forums (including the reddit thread I quoted > above). It won't help with the issues discussed in this thread. > > Cheers, > > Manuel.
Re: Deprecating basic asm in a function - What now?
On 22 June 2016 at 20:28, Andrew Pinski wrote: > On Wed, Jun 22, 2016 at 12:26 PM, Manuel López-Ibáñez > wrote: >> On 22 June 2016 at 19:05, Andrew Pinski wrote: >>> Note each target in gas has its own way of parsing assembly code which >>> is one of the reason why it is so hard todo the above and also each >>> target has its own wording which can confuse people. I think if you >> >> I didn't say it was easy. Yet, Clang/LLVM did it. > > That is because there are less targets on the Clang/LLVM side of things. And not even all of them have an integrated assembler. Yet, having it for the most popular targets is enough. Having the infrastructure in place is far more important, since it allows people interested in the less popular ones to do the work necessary to implement it. Cheers, Manuel.
Re: Should we import gnulib under gcc/ or at the top-level like libiberty?
On Wed, 22 Jun 2016, ayush goel wrote: > I am working on importing gnulib library inside the gcc tree. Should the > library be imported in the top level directory along with other > libraries (like libiberty, libatomic, liboffloadmic etc), or should it > be imported inside gcc/ like it is done in the binutils-gdb tree. There > they have a gnulib directory inside gdb/ in the top level directory. I think top-level will be easier. Note that, like libiberty, gnulib will need to be built for the build system (for use by generator programs) as well as for the host. -- Joseph S. Myers jos...@codesourcery.com
gcc-4.9-20160622 is now available
Snapshot gcc-4.9-20160622 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160622/ 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 237721 You'll find: gcc-4.9-20160622.tar.bz2 Complete GCC MD5=0f907231bacb71cfc8761f562c443364 SHA1=5cec347cf75c8dac4103436ca771a7c7e6ec8ca3 Diffs from 4.9-20160615 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.
libstdc++ deque allocation
Hi there- quick question, does deque as defined in libstdc++ allocate upon initialisation or upon first insertion? Trying to dig through the code but can't figure it out. Reason being, it's insertion graphs seem to show a surprisingly linear progression from small amounts of N to large amounts. Thanks in advance, Matt
