Re: Devirtualization causing undefined symbol references at link?
On 2015.11.16 at 14:18 -0800, Steven Noonan wrote:
> Hi folks,
>
> (I'm not subscribed to the list, so please CC me on all responses.)
>
> This is using GCC 5.2 on Linux x86_64. On a project at work I've found
> that one of our shared libraries refuses to link because of some
> symbol references it shouldn't be making. If I add "-fno-devirtualize
> -fno-devirtualize-speculatively" to the compile flags, the issue goes
> away and everything links/runs fine. The issue does *not* appear on
> GCC 4.8 (which is used by our current production toolchain).
>
> First of all, does anyone have any ideas off the top of their head why
> devirtualization would break like this?
>
> Second, I'm looking for any ideas on how to gather meaningful data to
> submit a useful bug report for this issue. The best idea I've come up
> with so far is to preprocess one of the sources with the incorrect
> references and use 'delta' to reduce it to a minimal preprocessed
> source file that references one of these incorrect symbols.
> Unfortunately this is a sluggish process because such a minimal test
> case would need to compile correctly to an object file -- so "delta"
> is reducing it very slowly. So far I'm down from 11MB preprocessed
> source to 1.1MB preprocessed source after running delta a few times.
These undefined references are normally user errors. For example, when
you define an inline function, you need to link with the symbols it
uses.
markus@x4 /tmp % cat main.ii
struct A {
void foo();
};
struct B {
A v;
virtual void bar() { v.foo(); }
};
struct C {
B *w;
void Test() {
if (!w)
return;
while (1)
w->bar();
}
};
C a;
int main() { a.Test(); }
markus@x4 /tmp % g++ -fno-devirtualize -O2 -Wl,--no-undefined main.ii
markus@x4 /tmp % g++ -O2 -Wl,--no-undefined main.ii
/tmp/ccEvh2dL.o:main.ii:function B::bar(): error: undefined reference to
'A::foo()'
/tmp/ccEvh2dL.o:main.ii:function main: error: undefined reference to 'A::foo()'
collect2: error: ld returned 1 exit status
Instead of using delta you could try creduce instead. It is normally
much quicker:
https://github.com/csmith-project/creduce
--
Markus
Re: basic asm and memory clobbers
On 17/11/15 05:55, David Wohlferd wrote: > How much pessimism are we talking here? Wouldn't clobbering everything > effectively force the reloading of (some? most? all?) registers? And > more memory will be needed to store things that used to just require > registers? No, really not. It only affects locals whose address has been taken and is live at that point. > Along with a few more memory writes? A single line of basic asm, > even a comment, could have a non-trivial impact on the code that > gets generated. > > One common use I've seen for basic asm is "int $3" on x86 to break into > the debugger (the basic asm docs use this as a sample). Changing this to > a clobber-everything will make what used to be a minimally intrusive way > to debug code into a high impact operation that may obscure the very > thing being debugged. I think that's really pretty unlikely. Besides, if you need a breakpoint for debugging you really don't want operations to move across that breakpoint. Andrew.
Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
On Sat, 14 Nov 2015, Maciej W. Rozycki wrote: > Any or all of these options may have effects beyond propagating the IEEE > Std 754 compliance mode down to the assembler and the linker. In > particular `-mieee=strict' is expected to guarantee code generated to > fully comply to IEEE Std 754 rather than only as far as NaN representation > is concerned. "guarantee" seems rather strong given the various known issues with (lack of) Annex F support in GCC. Do you have any actual configuration in mind it would affect, MIPS-specific or otherwise? For non-architecture-specific things, -std= options for C standards conformance are meant to enable whatever options are required (e.g. they disable the default -ffp-contract=fast), without affecting things not required by the standards by default (so they don't enable -frounding-math or -fsignaling-nans, for example). -- Joseph S. Myers jos...@codesourcery.com
Re: basic asm and memory clobbers
On 11/16/2015 10:55 PM, David Wohlferd wrote:
- There is no standard that says it must do this.
True. But these after all are extensions and extensions have been
notoriously under-documented through the years.
- I'm only aware of 1 person who has ever asked for this change. And the
request has been deemed so unimportant it has languished for a very long
time.
True. But I'd say for this case it means it just hasn't been high
enough on anyone's priority list to get resolved. I wouldn't be at all
surprised if Richard filed this bug to ensure that it didn't get lost.
That's standard development procedure for items we notice, but aren't
actively working on.
It's unfortunate that Andrew muddied the waters. Andrew's conclusions,
particularly in c#6 are simply wrong.
- There is a plausible work-around with extended asm, which (mostly) has
clear semantics regarding clobbers.
Converting an old-style asm to extended asm can be painful. ANd in the
case of legacy code the conversion process itself is a potential source
of bugs.
- While the change probably won't introduce bad code, if it does it will
be in ways that are going to be difficult to track down, in an area
where few have the expertise to debug.
- Existing code that currently does things 'right' (ie push/pop any
modified registers) will suddenly be doing things 'wrong,' or at least
wastefully.
- Other than top-level asm, it seems like every existing basic asm will
(probably) get a new performance penalty (memory usage + code size +
cycles) to allow for situations they may already be handling correctly
or that don't apply.
True, these aren't particularly compelling reasons to not make the
change. But I also don't see any compelling benefits to offset them.
The benefit is traditional asms do the expected thing. With no way to
describe dataflow, the only rational behaviour for a traditional asm is
that it has to be considered a use/clobber of memory and hard registers.
The fact that it wasn't documented that way eons ago is simply a
documentation bug -- likely due to the fact that back when the
documentation for traditional asms was written, there were virtually no
optimizations of memory referencing instructions -- essentially folks
didn't ponder (much less document) how these asms would interact with
memory.
In fact, if you go back to the change I made back in 1999 referenced by
this BZ, you'll find that we had a mis-compilation of code around an ASM
by a pass to remove redundant stores that had just been significantly
improved.
For existing users, presumably they have already found whatever solution
they need and will just be annoyed that they have to revisit their code
to see the impact of this change. Will they need to #if to ensure
consistent performance/function between gcc versions? For future users,
they will have the docs telling them the behavior, and pointing them to
the (now well documented) extended asm. Where's the benefit?
Existing users have to change nothing when we fix 24414. The whole
point behind 24414 is to point out a case where we are not honoring the
uses/clobbers all hard regs and memory semantics of traditional asms.
But changing this so gcc tries (probably futilely) to emulate other
implementations of asm... That seems like a weak case to support a
change to this long-time behavior. Unless there are other benefits I'm
just not seeing?
When we fix 24414 by honoring the "uses/clobbers all hard registers and
memory" semantics for old-style asms, those old-style asms will be
*less* likely to cause problems in the presence of ever-improving
optimization techniques.
--
Ok, that's my best shot. You have way more expertise and experience
here than I do, so I expect that after you think it over, you'll make
the right call. And despite my attempt here to defend the opposite
side, I'm not entirely sure what the right call is. But these seem like
the right questions.
Either way, let me know if I can help.
About the only immediate task would be to ensure that the documentation
for traditional asms clearly documents the desired semantics and somehow
note that there are known bugs in the implementation (ie 24414, handling
of flags registers, and probably other oddities)
Whether that means clobbering memory or not, I don't much care -- with
the status quo, if you want your asm to clobber memory you have to use
extended asm; if basic asm is made to clobber memory, if you want your
asm to *not* clobber memory you have to use extended asm (which you
can with no operands by writing e.g. asm("bork" : ); ). So both
behaviours are available whether we make a change or not.
But changing things now will likely break user code.
Having an traditional asm clobber memory should not break user code.
It may pessimize it slightly, but if it does, that code was already
broken.
How much pessimism are we talking here? Wouldn't clobbering everything
effectively force
Re: basic asm and memory clobbers
On Wed, Nov 18, 2015 at 5:31 AM, Jeff Law wrote: > On 11/16/2015 10:55 PM, David Wohlferd wrote: >> >> >> - There is no standard that says it must do this. > > True. But these after all are extensions and extensions have been > notoriously under-documented through the years. > >> - I'm only aware of 1 person who has ever asked for this change. And the >> request has been deemed so unimportant it has languished for a very long >> time. > > True. But I'd say for this case it means it just hasn't been high enough on > anyone's priority list to get resolved. I wouldn't be at all surprised if > Richard filed this bug to ensure that it didn't get lost. That's standard > development procedure for items we notice, but aren't actively working on. > > It's unfortunate that Andrew muddied the waters. Andrew's conclusions, > particularly in c#6 are simply wrong. Sorry about that. I have since changed my views on this matter to say old-style asm should clobber memory. I should have written this sooner but I have been busy with other things. Thanks, Andrew > > >> - There is a plausible work-around with extended asm, which (mostly) has >> clear semantics regarding clobbers. > > Converting an old-style asm to extended asm can be painful. ANd in the case > of legacy code the conversion process itself is a potential source of bugs. > > > > >> - While the change probably won't introduce bad code, if it does it will >> be in ways that are going to be difficult to track down, in an area >> where few have the expertise to debug. >> - Existing code that currently does things 'right' (ie push/pop any >> modified registers) will suddenly be doing things 'wrong,' or at least >> wastefully. >> - Other than top-level asm, it seems like every existing basic asm will >> (probably) get a new performance penalty (memory usage + code size + >> cycles) to allow for situations they may already be handling correctly >> or that don't apply. >> True, these aren't particularly compelling reasons to not make the >> change. But I also don't see any compelling benefits to offset them. > > The benefit is traditional asms do the expected thing. With no way to > describe dataflow, the only rational behaviour for a traditional asm is that > it has to be considered a use/clobber of memory and hard registers. > > The fact that it wasn't documented that way eons ago is simply a > documentation bug -- likely due to the fact that back when the documentation > for traditional asms was written, there were virtually no optimizations of > memory referencing instructions -- essentially folks didn't ponder (much > less document) how these asms would interact with memory. > > In fact, if you go back to the change I made back in 1999 referenced by this > BZ, you'll find that we had a mis-compilation of code around an ASM by a > pass to remove redundant stores that had just been significantly improved. > > > >> >> For existing users, presumably they have already found whatever solution >> they need and will just be annoyed that they have to revisit their code >> to see the impact of this change. Will they need to #if to ensure >> consistent performance/function between gcc versions? For future users, >> they will have the docs telling them the behavior, and pointing them to >> the (now well documented) extended asm. Where's the benefit? > > Existing users have to change nothing when we fix 24414. The whole point > behind 24414 is to point out a case where we are not honoring the > uses/clobbers all hard regs and memory semantics of traditional asms. > > >> >> But changing this so gcc tries (probably futilely) to emulate other >> implementations of asm... That seems like a weak case to support a >> change to this long-time behavior. Unless there are other benefits I'm >> just not seeing? > > When we fix 24414 by honoring the "uses/clobbers all hard registers and > memory" semantics for old-style asms, those old-style asms will be *less* > likely to cause problems in the presence of ever-improving optimization > techniques. > > >> >> -- >> Ok, that's my best shot. You have way more expertise and experience >> here than I do, so I expect that after you think it over, you'll make >> the right call. And despite my attempt here to defend the opposite >> side, I'm not entirely sure what the right call is. But these seem like >> the right questions. >> >> Either way, let me know if I can help. > > About the only immediate task would be to ensure that the documentation for > traditional asms clearly documents the desired semantics and somehow note > that there are known bugs in the implementation (ie 24414, handling of flags > registers, and probably other oddities) > > Whether that means clobbering memory or not, I don't much care -- with > the status quo, if you want your asm to clobber memory you have to use > extended asm; if basic asm is made to clobber memory, if you want your > asm to *not* clobber memory you have t
gcc-5-20151117 is now available
Snapshot gcc-5-20151117 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20151117/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 230508 You'll find: gcc-5-20151117.tar.bz2 Complete GCC MD5=50887aa024c891d385d40929c1ff24ff SHA1=d76ce23834a8942dbcc3f882fe3e4f98b8997824 Diffs from 5-20151110 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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: basic asm and memory clobbers
On Tue, Nov 17, 2015 at 02:31:29PM -0700, Jeff Law wrote: > >- There is a plausible work-around with extended asm, which (mostly) has > >clear semantics regarding clobbers. > Converting an old-style asm to extended asm can be painful. ANd in the > case of legacy code the conversion process itself is a potential source > of bugs. > >- While the change probably won't introduce bad code, if it does it will > >be in ways that are going to be difficult to track down, in an area > >where few have the expertise to debug. > >- Existing code that currently does things 'right' (ie push/pop any > >modified registers) will suddenly be doing things 'wrong,' or at least > >wastefully. Basic asm does not do this, and hasn't for a very long time. So there simply cannot be existing users that rely on this behaviour. fwprop1 removes the save/restore already, in most cases. > The fact that it wasn't documented that way eons ago is simply a > documentation bug -- likely due to the fact that back when the > documentation for traditional asms was written, there were virtually no > optimizations of memory referencing instructions -- essentially folks > didn't ponder (much less document) how these asms would interact with > memory. _Does_ basic asm as currently implemented have a memory clobber? If not, it seems we can just remove basic asm completely and everything would still work the same! Segher
x32 libraries
Is there a reason why libmpx and libgccjit aren't build for x32? This is in the case when building IA-32, x86-64, and x32 all together. Haven't tested any other way to build. I suspect it's just an oversight in the way configuration works since I cannot see a technical reason.
