Re: About sink load from memory in tree-ssa-sink.c
On Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther wrote: > On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng wrote: > > I don't understand method 2. I'd do > > start at the single predecessor of the sink-to block > > foreach stmt from the end to the beginning of that block > if the stmt has a VDEF or the same VUSE as the stmt we sink, break > > (continue searching for VDEFs in predecessors - that now gets more expensive, > I suppose limiting sinking to the cases where the above finds sth > would be easiest, > even limiting sinking to never sink across any stores) > > walk the vuse -> vdef chain, using refs_anti_dependent_p to see whether > the load is clobbered. > > But I'd suggest limiting the sinking to never sink across stores - the alias > memory model we have in GCC seriously limits these anyway. How would > the numbers change if you do that? Interesting, maybe method 1 I implemented is too conservative. I implemented as you described, and the numbers are: 1)766, If the stop condition is "stmt_may_clobber_ref_p" 2)719, if the stop condition is "gimple_vdef || stmt_may_clobber_ref_p" Also, I past make check on x86 for 1). Is it good? I am not sure about it since bootstrapping builds gcc 2 times and libraries 3 times. Thanks -- Best Regards.
Re: Announce - Thread safety annotations no longer supported in GCC
On Thu, Apr 19, 2012 at 10:20 PM, Diego Novillo wrote: > On 4/19/12 4:14 PM, Andrew Pinski wrote: > >> How do you know it is a major effort? Has any issues related to >> changing Tuple/front-ends AST been raised to the mailing list and >> asked for help on how to implement these changes? > > > The kind of analysis that Annotalysis needs cannot be catered by GIMPLE, the > same way that LLVM's bitcode could not cater to it. Both representations > are geared towards code transformations, not source code analysis. It's not > an implementation issue, but a design one. It simply does not make sense > for GIMPLE or LLVM's bitcode to try to be a source code analysis framework. > > Annotalysis needs a high-fidelity representation of the original source > code. Today, that high-fidelity representation is provided exclusively by > Clang. > > Additionally, we are already supporting Clang as a front end to provide > syntax and semantic analysis. Given that Clang provides a much more > flexible framework for static analysis, the decision was a relatively simple > one. > > This is not to say that Clang provides everything needed by Annotalysis. > There is some need to use dataflow information which needs to be > incorporated in Clang. However, a large fraction of the support required > was already available in Clang. Our high-level AST is language specific. In case of C++ its GENERIC plus some C++ specific tree codes. There is no framework for building a CFG on top of that (not sure if you need that), but the cgraph is built over that representation. Of course non-optimizing ASTs will limit static analysis to TU scope, even with clang? Or does clang support a "LTO" source AST? Richard. > > Diego.
Re: About sink load from memory in tree-ssa-sink.c
On Fri, Apr 20, 2012 at 9:52 AM, Bin.Cheng wrote: > On Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther > wrote: >> On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng wrote: > >> >> I don't understand method 2. I'd do >> >> start at the single predecessor of the sink-to block >> >> foreach stmt from the end to the beginning of that block >> if the stmt has a VDEF or the same VUSE as the stmt we sink, break >> >> (continue searching for VDEFs in predecessors - that now gets more >> expensive, >> I suppose limiting sinking to the cases where the above finds sth >> would be easiest, >> even limiting sinking to never sink across any stores) >> >> walk the vuse -> vdef chain, using refs_anti_dependent_p to see whether >> the load is clobbered. >> >> But I'd suggest limiting the sinking to never sink across stores - the alias >> memory model we have in GCC seriously limits these anyway. How would >> the numbers change if you do that? > Interesting, maybe method 1 I implemented is too conservative. > I implemented as you described, and the numbers are: > 1) 766, If the stop condition is "stmt_may_clobber_ref_p" > 2) 719, if the stop condition is "gimple_vdef || stmt_may_clobber_ref_p" > > Also, I past make check on x86 for 1). > > Is it good? I am not sure about it since bootstrapping builds gcc 2 > times and libraries 3 times. For 2) it is enough to test for gimple_vdef. I think that's the most reasonable approach - we can improve on it once we see that doing so would improve things for a testcase. Richard. > Thanks > -- > Best Regards.
Re: About sink load from memory in tree-ssa-sink.c
On Fri, Apr 20, 2012 at 4:54 PM, Richard Guenther wrote: > On Fri, Apr 20, 2012 at 9:52 AM, Bin.Cheng wrote: >> On Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther >> wrote: >>> On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng wrote: >> >>> >>> I don't understand method 2. I'd do >>> >>> start at the single predecessor of the sink-to block >>> >>> foreach stmt from the end to the beginning of that block >>> if the stmt has a VDEF or the same VUSE as the stmt we sink, break >>> >>> (continue searching for VDEFs in predecessors - that now gets more >>> expensive, >>> I suppose limiting sinking to the cases where the above finds sth >>> would be easiest, >>> even limiting sinking to never sink across any stores) >>> >>> walk the vuse -> vdef chain, using refs_anti_dependent_p to see whether >>> the load is clobbered. >>> >>> But I'd suggest limiting the sinking to never sink across stores - the alias >>> memory model we have in GCC seriously limits these anyway. How would >>> the numbers change if you do that? >> Interesting, maybe method 1 I implemented is too conservative. >> I implemented as you described, and the numbers are: >> 1) 766, If the stop condition is "stmt_may_clobber_ref_p" >> 2) 719, if the stop condition is "gimple_vdef || stmt_may_clobber_ref_p" >> >> Also, I past make check on x86 for 1). >> >> Is it good? I am not sure about it since bootstrapping builds gcc 2 >> times and libraries 3 times. > > For 2) it is enough to test for gimple_vdef. I think that's the most > reasonable > approach - we can improve on it once we see that doing so would improve > things for a testcase. I am a little confused. does not "gimple_code (stmt) == GIMPLE_ASM"/"call_may_clobber_ref_p_1 (stmt, ref)" matter? These are checked by stmt_may_clobber_ref_p. Thanks. -- Best Regards.
Re: About sink load from memory in tree-ssa-sink.c
On Fri, Apr 20, 2012 at 11:04 AM, Bin.Cheng wrote: > On Fri, Apr 20, 2012 at 4:54 PM, Richard Guenther > wrote: >> On Fri, Apr 20, 2012 at 9:52 AM, Bin.Cheng wrote: >>> On Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther >>> wrote: On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng wrote: >>> I don't understand method 2. I'd do start at the single predecessor of the sink-to block foreach stmt from the end to the beginning of that block if the stmt has a VDEF or the same VUSE as the stmt we sink, break (continue searching for VDEFs in predecessors - that now gets more expensive, I suppose limiting sinking to the cases where the above finds sth would be easiest, even limiting sinking to never sink across any stores) walk the vuse -> vdef chain, using refs_anti_dependent_p to see whether the load is clobbered. But I'd suggest limiting the sinking to never sink across stores - the alias memory model we have in GCC seriously limits these anyway. How would the numbers change if you do that? >>> Interesting, maybe method 1 I implemented is too conservative. >>> I implemented as you described, and the numbers are: >>> 1) 766, If the stop condition is "stmt_may_clobber_ref_p" >>> 2) 719, if the stop condition is "gimple_vdef || stmt_may_clobber_ref_p" >>> >>> Also, I past make check on x86 for 1). >>> >>> Is it good? I am not sure about it since bootstrapping builds gcc 2 >>> times and libraries 3 times. >> >> For 2) it is enough to test for gimple_vdef. I think that's the most >> reasonable >> approach - we can improve on it once we see that doing so would improve >> things for a testcase. > I am a little confused. > does not "gimple_code (stmt) == GIMPLE_ASM"/"call_may_clobber_ref_p_1 > (stmt, ref)" > matter? These are checked by stmt_may_clobber_ref_p. All things that clobber anything have gimple_vdef () != NULL. Thus in gimple_vdef () != NULL || stmt_may_clobber_ref_p, stmt_may_clobber_ref_p is never true if gimple_vdef () is NULL. stmt_may_clobber_ref_p isn't checking for a NULL gimple_vdef, but that's because you are not supposed to even have called it then. Richard. > Thanks. > > -- > Best Regards.
Re: Announce - Thread safety annotations no longer supported in GCC
Since nobody answered to Richard, and I find the discussion interesting to understand what the future of GCC might be > Our high-level AST is language specific. In case of C++ its GENERIC plus > some C++ specific tree codes. There is no framework for building a CFG > on top of that (not sure if you need that), but the cgraph is built over that > representation. C/C++ GENERIC does not accurately represent the original source code, and I understand that this is on purpose (or at least, it is not a goal). This is one of the major criticisms of GCC that (supposedly) led to the development of Clang (see the first 20 minutes of http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys ). > Of course non-optimizing ASTs will limit static analysis to TU scope, even > with clang? Or does clang support a "LTO" source AST? It seems it does: http://clang.llvm.org/doxygen/Index_8h.html http://clang.llvm.org/doxygen/dir_e9b826b1b01168f6fc5ffb2b00be9311.html And even if it didn't, it is a clearly expressed goal of Clang to support such uses. Quoting from http://clang.llvm.org/features.html#diverseclients "The problem with this goal is that different clients have very different requirements. Consider code generation, for example: a simple front-end that parses for code generation must analyze the code for validity and emit code in some intermediate form to pass off to a optimizer or backend. Because validity analysis and code generation can largely be done on the fly, there is not hard requirement that the front-end actually build up a full AST for all the expressions and statements in the code. TCC and GCC are examples of compilers that either build no real AST (in the former case) or build a stripped down and simplified AST (in the later case) because they focus primarily on codegen. On the opposite side of the spectrum, some clients (like refactoring) want highly detailed information about the original source code and want a complete AST to describe it with. Refactoring wants to have information about macro expansions, the location of every paren expression '(((x)))' vs 'x', full position information, and much more. Further, refactoring wants to look across the whole program to ensure that it is making transformations that are safe. Making this efficient and getting this right requires a significant amount of engineering and algorithmic work that simply are unnecessary for a simple static compiler." Cheers, Manuel.
Re: Announce - Thread safety annotations no longer supported in GCC
> Why wouldn't it be constructive?
>
> Even if it's impractical for gcc to change to the degree needed to fit
> your particular project (especially in the short term), hearing the
> details of how gcc's representations fell short, and how others may
> have done things better, seems useful.
My main concern is to avoid turning this into a "clang vs. gcc"
debate. The two compilers make different trade-offs, so it is hardly
surprising that one is better than the other for a particular use
case. That does not mean that one is better than the other overall.
But since it seems that there is significant interest, I have written
down some of the technical problems that we ran into when working with
gcc. Description and accompanying source code are enclosed.
-DeLesley
Annotalysis is a flow and path sensitive analysis, in which we track the set of
locks that are known to be held at each program point, and verify that any
access to guarded data, or call to a guarded method, is made while holding the
appropriate lock. Annotations are used to mark data members and methods as
"guarded".
In the ideal world of our imagination, we would like an intermediate
representation that supplies the following information, in order of priority:
(1) It must provide a CFG that accurately reflects the source code. This is
critical.
(2) It must provide accurate source-language type information for each
expression, so that we can find annotations on virtual methods.
(3) We need to look at the IR before any optimizations occur.
(4) It should be stable from release to release of the compiler.
(5) All local variables should be in SSA form; SSA makes life much easier.
(6) It should identify loads and stores.
(7) It should be simple and easy to traverse.
Gimple satisfies 5-7 almost perfectly, does 1-3 pretty well, and fails on 4.
Unfortunately, "pretty well" on 1-3 was not sufficient for our needs, and 4 was
getting to be a problem. I will provide a few examples of things that have
caused major headaches. These examples are enclosed in
gcc-problem-examples.cpp,
which you can compile with -fdump-tree-ssa to follow along. Descriptions
relate
to gcc 4.6; I have not tested with gcc 4.7.
(1) Inaccurate CFG
void foo1(Mutex* mu, bool c) {
mu->Lock();
if (c) {
MyClass mc;
if (c) {
mu->Unlock();
return;
}
// extra join point here to call ~MyClass()
}
mu->Unlock();
return;
};
The lowering to GIMPLE produces an extra join point in the CFG that is not
present in the source code, in order to call the destructor of MyClass. The
benefit from a codegen standpoint is that different paths in the CFG can share
the same destructor code, so this is ordinarily a good thing. However, our
analysis algorithm merges locksets whenever it hits a join point, so we get
false positives in this case. Fixing this problem would require a substantial
rewrite of the algorithm to handle conditionally held locks.
===
(2) Inaccurate type information.
void foo2(void* p) {
((MyClass*) p)->myMethod();
}
This is a minor nit. The virtual function call uses a type cast to grab the
vtable, but then passes p (with type void*) as 'this'. So when I go back
and try to locate the method later, I get a method lookup failure. To be fair,
this sort of thing does not happen very often.
(3) "local" optimizations with non-local effects.
Annotalysis is scheduled as a local optimization pass that runs before all
other optimizations. Unfortunately, some "local" optimizations have non-local
effects that interfere with the analysis. IPA-SRA has been the main source of
headaches:
class DummyMutex {
public:
void Lock() EXCLUSIVE_LOCK_FUNCTION(this) { }
void Unlock() UNLOCK_FUNCTION(this) { }
};
void foo3(DummyMutex* dmu1, DummyMutex* dmu2) {
dmu1->Lock();
dmu2->Lock();
dmu2->Unlock();
dmu1->Unlock();
}
DummyMutex is a class that implements the interface of a mutex without doing
anything. The LOCK_FUNCTION and UNLOCK_FUNCTION macros are annotations that
the analysis uses to build locksets. IPA-SRA will helpfully notice that the
body of these functions do not refer to 'this', and thus they can be lifted to
static methods; a good optimization. It fails to notice that the *annotation*
refers to 'this'. The lifting happens "locally", before the compilation of
foo3(), so when checking foo3, the analysis can no longer determine which
object is being locked or unlocked.
The net result of this change is that we get false positives when compiling
with optimizations turned on, even though the analysis is supposed to run
before any optimizations. (Compare the output of -fdump-tree-ssa when
compiling normally, versus compiling with -O3.)
(4) Unstable platform.
Problems (1) and (3) were both introduced in gcc 4.6; they did not exist in
earlier versions of the compiler. gcc 4.7 introduces new breakages that I have
not investigated. Th
RFC: Add STB_GNU_SECONDARY
Hi, We have a need to define a secondary symbol as backup in case there isn't a primary one. Here is a proposal for STB_GNU_SECONDARY. Any comments? Thanks. -- H.J. --- STB_GNU_SECONDARY Secondary symbols are similar to weak symbols, but their definitions have even lower precedence. Secondary symbols can only appear in a relocatable object. They must be either removed or converted to global or local symbols once it has become part of an executable or shared object. The difference between secondary symbols and weak symbols are 1. When the link editor searches an archive library, it must extracts archive members that contain the global, weak or common definition of the secondary symbol with the same name and ignore the secondary one. 2. When the link editor searches a shared object, it must honor the global or weak definition in the shared object and ignore the secondary one with the same name. 3. The link editor ignores the secondary definition if there is a global, weak or common definition with the same name. The purpose of this symbol binding is to provide the primary definition as a global, weak or common symbol in an archive library or a shared object while keeping a secondary definition in a relocatable object. If there is no primary definition, the secondary definition will be used. STB_GNU_SECONDARY is defined in OS-specific range: #define STB_LOOS10 /* OS-specific semantics */ #define STB_GNU_UNIQUE 10 /* Symbol is unique in namespace */ #define STB_GNU_SECONDARY 11 /* Secondary symbol */ #define STB_LOOS12 /* OS-specific semantics */
Re: RFC: Add STB_GNU_SECONDARY
Please provide an example that illustrates why you think you need this. Thanks, Roland
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 12:50 PM, Roland McGrath wrote: > Please provide an example that illustrates why you think you need this. > Currently we use weak undefined symbol, foo, to do if (&foo != 0) foo is defined. else foo isn't defined. We want is to define foo as a secondary symbol so that we can always use foo without checking. If there is a primary one in a .o file and .so file, we will get the primary one, otherwise, we will use the secondary one. -- H.J.
Re: Switching to C++ by default in 4.8
On Tue, 3 Apr 2012, Pawe�~B Sikora wrote: > i'm only suggesting that astyle (or another tool) can be used in svn > pre-commit > hook to verifying gnu formatting rules (incoming files can be extracted from I think it's a bad idea to check anything in a pre-commit hook that isn't also covered by a normal build and testsuite run. Commit time is too late for detecting problems with patches; if you want automatic style checks then make them cause the build or testsuite run to fail if there are problems. -- Joseph S. Myers jos...@codesourcery.com
Re: RFC: Add STB_GNU_SECONDARY
> Currently we use weak undefined symbol, foo, to do > > if (&foo != 0) > foo is defined. > else > foo isn't defined. > > We want is to define foo as a secondary symbol so that > we can always use foo without checking. If there is a primary > one in a .o file and .so file, we will get the primary one, > otherwise, we will use the secondary one. Why not use a weak definition in the file where you make the call?
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 1:26 PM, Roland McGrath wrote: >> Currently we use weak undefined symbol, foo, to do >> >> if (&foo != 0) >> foo is defined. >> else >> foo isn't defined. >> >> We want is to define foo as a secondary symbol so that >> we can always use foo without checking. If there is a primary >> one in a .o file and .so file, we will get the primary one, >> otherwise, we will use the secondary one. > > Why not use a weak definition in the file where you make the call? It doesn't work for us since a weak definition can't be overridden by another definition in a .so file. -- H.J.
Re: RFC: Add STB_GNU_SECONDARY
Quoting "H.J. Lu" : Hi, We have a need to define a secondary symbol as backup in case there isn't a primary one. Here is a proposal for STB_GNU_SECONDARY. Any comments? If two levels of prevedence (ordinary and weak) are not enough, why will three levels be so much better? If you use a signed fractional or even floating-point precedence value, you have a lot more space to accomodate afterthoughts - above, below, and in-between in precedence to existing values. Even better, you could use symbolic tags, and have the linker script assign precedence values to these tags.
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 1:55 PM, Joern Rennecke wrote: > Quoting "H.J. Lu" : > >> Hi, >> >> We have a need to define a secondary symbol as backup in >> case there isn't a primary one. Here is a proposal for >> STB_GNU_SECONDARY. Any comments? > > > If two levels of prevedence (ordinary and weak) are not enough, why will > three levels be so much better? The main issues with weak symbols are 1. A global definition in shared object won't override a weak definition in relocatable file. 2. A global definition in archive won't override a weak definition in relocatable file. > If you use a signed fractional or even floating-point precedence value, > you have a lot more space to accomodate afterthoughts - above, below, > and in-between in precedence to existing values. We only have very few bits to in STB_XXX field. > Even better, you could use symbolic tags, and have the linker script > assign precedence values to these tags. It won't help us. -- H.J.
Re: RFC: Add STB_GNU_SECONDARY
> We only have very few bits to in STB_XXX field. This is exactly why I'm not in favor of this extension. The feature doesn't seem compelling enough to use up one of these precious reserved values (in fact, you're using the next-to-last one that's reserved for OS use). You want a backup definition? Put a weak def at the end of the link line. -cary
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote: >> We only have very few bits to in STB_XXX field. > > This is exactly why I'm not in favor of this extension. The feature > doesn't seem compelling enough to use up one of these precious > reserved values (in fact, you're using the next-to-last one that's > reserved for OS use). > > You want a backup definition? Put a weak def at the end of the link line. > It doesn't work for us since the backup definition is always used even if there is a normal definition in a shared library or an archive. -- H.J.
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 3:47 PM, H.J. Lu wrote: > On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote: >>> We only have very few bits to in STB_XXX field. >> >> This is exactly why I'm not in favor of this extension. The feature >> doesn't seem compelling enough to use up one of these precious >> reserved values (in fact, you're using the next-to-last one that's >> reserved for OS use). >> >> You want a backup definition? Put a weak def at the end of the link line. >> > > It doesn't work for us since the backup definition is > always used even if there is a normal definition in > a shared library or an archive. > > In our usage, the backup definition may not be at the end of link command line. -- H.J.
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 01:11:34PM -0700, H.J. Lu wrote: > On Fri, Apr 20, 2012 at 12:50 PM, Roland McGrath wrote: > > Please provide an example that illustrates why you think you need this. > > > > Currently we use weak undefined symbol, foo, to do > > if (&foo != 0) > foo is defined. > else > foo isn't defined. > > We want is to define foo as a secondary symbol so that > we can always use foo without checking. If there is a primary > one in a .o file and .so file, we will get the primary one, > otherwise, we will use the secondary one. This is still a very general example. Does this concern a particular software package? Couldn't you use IFUNC to perform the if-statement above and supply the proper function? Petr "Pasky" Baudis
Re: RFC: Add STB_GNU_SECONDARY
"H.J. Lu" writes: > On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote: >>> We only have very few bits to in STB_XXX field. >> >> This is exactly why I'm not in favor of this extension. The feature >> doesn't seem compelling enough to use up one of these precious >> reserved values (in fact, you're using the next-to-last one that's >> reserved for OS use). >> >> You want a backup definition? Put a weak def at the end of the link line. >> > > It doesn't work for us since the backup definition is > always used even if there is a normal definition in > a shared library or an archive. Can you expand on that? How can you refer to the backup definition if there is a normal definition? Ian
gcc-4.6-20120420 is now available
Snapshot gcc-4.6-20120420 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120420/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 186645 You'll find: gcc-4.6-20120420.tar.bz2 Complete GCC MD5=cc43a641c942f64382da9f7a831a5ac9 SHA1=fc6f46fad1c4c4e25d3e4a68a1a440d27f1faddb Diffs from 4.6-20120413 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
What to do about pattern recognition not in .md order when the mode of a pattern operand is unspecified
Other target-patches exposed this for me. I have on the 4.7-branch an insn: (jump_insn 245 277 246 (set (pc) (label_ref:SI 312)) whatever.c:511 -1 (nil) -> 187) and two (or more) pattern candidates in the following .md file order: (define_insn "jump" [(set (pc) (label_ref (match_operand 0 "" "")))] "" "ba %l0%#" [(set_attr "slottable" "has_slot")]) (define_insn "*indirect_jump_non_v32" [(set (pc) (match_operand:SI 0 "nonimmediate_operand" "rm"))] "!TARGET_V32" "jump %0") As you know (or may want to dispute for some reason, so let's settle that first), operands without specified modes on matching patterns are wild-card matches; not VOIDmode matches or a kind of lesser-order matches. (ISTR some change, at least some discussion, that label_refs now should have modes, but if the change happened, the documentation wasn't sufficiently updated. If so, the mode on the "jump"-pattern above should be :SI, but when it's not specified, it's a wild-card, so should still *match*. It could also be that the :SI is put there in error, but still the pattern recognition order observation is valid.) It seems that since 4.3, some change now causes the generated pattern-matching tree in insn-recog.c:recog to try the pattern *with the specified mode* before (eventually, seemingly last) the one with the unspecified-mode label_ref. What I'll do next depends. Is there a reason to keep that change (and document it) or should the bug just be fixed? brgds, H-P
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 3:54 PM, Petr Baudis wrote: > On Fri, Apr 20, 2012 at 01:11:34PM -0700, H.J. Lu wrote: >> On Fri, Apr 20, 2012 at 12:50 PM, Roland McGrath >> wrote: >> > Please provide an example that illustrates why you think you need this. >> > >> >> Currently we use weak undefined symbol, foo, to do >> >> if (&foo != 0) >> foo is defined. >> else >> foo isn't defined. >> >> We want is to define foo as a secondary symbol so that >> we can always use foo without checking. If there is a primary >> one in a .o file and .so file, we will get the primary one, >> otherwise, we will use the secondary one. > > This is still a very general example. Does this concern a particular > software package? We have a compiler optimization feature which requires a backup definition just in case that the primary one doesn't exist in an archive or a DSO. > Couldn't you use IFUNC to perform the if-statement above and supply > the proper function? No. -- H.J.
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 3:59 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote: We only have very few bits to in STB_XXX field. >>> >>> This is exactly why I'm not in favor of this extension. The feature >>> doesn't seem compelling enough to use up one of these precious >>> reserved values (in fact, you're using the next-to-last one that's >>> reserved for OS use). >>> >>> You want a backup definition? Put a weak def at the end of the link line. >>> >> >> It doesn't work for us since the backup definition is >> always used even if there is a normal definition in >> a shared library or an archive. > > Can you expand on that? How can you refer to the backup definition if > there is a normal definition? > We need a definition for symbol, foo. Since we don't know if there is a definition of foo at the final link time. We provide the backup definition for foo. The backup one is ignored if there is a normal one in an archive or DSO at link time. -- H.J.
Duplicate Words In GCC 4.7.0 Changes Page
In Section "New Languages and Language specific improvements" In subsection "C Family" Objective-C is repeated twice. : "A new experimental -ftrack-macro-expansion option was added for C, C++, Objective-C, Objective-C and Fortran. It allows the compiler to emit diagnostic about the current macro expansion stack when a compilation error occurs in a macro expansion." Looking At The Above Bullet I Think That The Second One Should Be Changed To Objective-C++.
Re: RFC: Add STB_GNU_SECONDARY
"H.J. Lu" writes: > On Fri, Apr 20, 2012 at 3:59 PM, Ian Lance Taylor wrote: >> "H.J. Lu" writes: >> >>> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote: > We only have very few bits to in STB_XXX field. This is exactly why I'm not in favor of this extension. The feature doesn't seem compelling enough to use up one of these precious reserved values (in fact, you're using the next-to-last one that's reserved for OS use). You want a backup definition? Put a weak def at the end of the link line. >>> >>> It doesn't work for us since the backup definition is >>> always used even if there is a normal definition in >>> a shared library or an archive. >> >> Can you expand on that? How can you refer to the backup definition if >> there is a normal definition? >> > > We need a definition for symbol, foo. Since we don't know if there > is a definition of foo at the final link time. We provide the backup > definition for foo. The backup one is ignored if there is a normal one in > an archive or DSO at link time. That use case would be satisfied by Cary's suggestion of adding a weak definition of the symbol in an object included at the end of the link line. Ian
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 4:40 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Fri, Apr 20, 2012 at 3:59 PM, Ian Lance Taylor wrote: >>> "H.J. Lu" writes: >>> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote: >> We only have very few bits to in STB_XXX field. > > This is exactly why I'm not in favor of this extension. The feature > doesn't seem compelling enough to use up one of these precious > reserved values (in fact, you're using the next-to-last one that's > reserved for OS use). > > You want a backup definition? Put a weak def at the end of the link line. > It doesn't work for us since the backup definition is always used even if there is a normal definition in a shared library or an archive. >>> >>> Can you expand on that? How can you refer to the backup definition if >>> there is a normal definition? >>> >> >> We need a definition for symbol, foo. Since we don't know if there >> is a definition of foo at the final link time. We provide the backup >> definition for foo. The backup one is ignored if there is a normal one in >> an archive or DSO at link time. > > That use case would be satisfied by Cary's suggestion of adding a weak > definition of the symbol in an object included at the end of the link > line. In our usage, the backup definition may not be at the end of command line since it may reference library symbols. -- H.J.
Re: Duplicate Words In GCC 4.7.0 Changes Page
On 21 April 2012 00:37, Todd Edwards wrote: > In Section "New Languages and Language specific improvements" In subsection > "C Family" Objective-C is repeated twice. : > "A new experimental -ftrack-macro-expansion option was added for C, C++, > Objective-C, Objective-C and Fortran. It allows the compiler to emit > diagnostic about the current macro expansion stack when a compilation error > occurs in a macro expansion." > > Looking At The Above Bullet I Think That The Second One Should Be Changed To > Objective-C++. Thanks, fixed by this patch: Index: gcc-4.7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.107 diff -u -r1.107 changes.html --- gcc-4.7/changes.html30 Mar 2012 08:22:56 - 1.107 +++ gcc-4.7/changes.html20 Apr 2012 23:59:46 - @@ -245,7 +245,7 @@ A new experimental -ftrack-macro-expansion option was added for - C, C++, Objective-C, Objective-C and Fortran. It allows the + C, C++, Objective-C, Objective-C++ and Fortran. It allows the compiler to emit diagnostic about the current macro expansion stack when a compilation error occurs in a macro expansion.
Re: Duplicate Words In GCC 4.7.0 Changes Page
Oops, meant to CC gcc-patches ... On 21 April 2012 01:01, Jonathan Wakely wrote: > On 21 April 2012 00:37, Todd Edwards wrote: >> In Section "New Languages and Language specific improvements" In subsection >> "C Family" Objective-C is repeated twice. : >> "A new experimental -ftrack-macro-expansion option was added for C, C++, >> Objective-C, Objective-C and Fortran. It allows the compiler to emit >> diagnostic about the current macro expansion stack when a compilation error >> occurs in a macro expansion." >> >> Looking At The Above Bullet I Think That The Second One Should Be Changed To >> Objective-C++. > > Thanks, fixed by this patch: > > Index: gcc-4.7/changes.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v > retrieving revision 1.107 > diff -u -r1.107 changes.html > --- gcc-4.7/changes.html 30 Mar 2012 08:22:56 - 1.107 > +++ gcc-4.7/changes.html 20 Apr 2012 23:59:46 - > @@ -245,7 +245,7 @@ > > > A new experimental -ftrack-macro-expansion option was added for > - C, C++, Objective-C, Objective-C and Fortran. It allows the > + C, C++, Objective-C, Objective-C++ and Fortran. It allows the > compiler to emit diagnostic about the current macro expansion > stack when a compilation error occurs in a macro expansion. >
Re: RFC: Add STB_GNU_SECONDARY
"H.J. Lu" writes: > In our usage, the backup definition may not be at the end of > command line since it may reference library symbols. You could write out the backup function you need under a different name. Then have the backup symbol at the end of the link call the new name of the backup function. I agree that this kind of approach is less convenient, but this doesn't seem like a persuasive choice for one of the two remaining OS-dependent symbol binding numbers. Perhaps you should try to sell this idea to the ELF ABI, the generic space has seven available numbers. Ian
Re: RFC: Add STB_GNU_SECONDARY
On Fri, Apr 20, 2012 at 5:49 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> In our usage, the backup definition may not be at the end of >> command line since it may reference library symbols. > > You could write out the backup function you need under a different name. > Then have the backup symbol at the end of the link call the new name of > the backup function. isn't it replacing one backup with another backup? > I agree that this kind of approach is less convenient, but this doesn't > seem like a persuasive choice for one of the two remaining OS-dependent > symbol binding numbers. Perhaps you should try to sell this idea to the > ELF ABI, the generic space has seven available numbers. > We are looking for a solution to have the backup definition which can be overridden by a normal definition from an archive or shared object. Weak symbol doesn't work here. I will ask in the gABI group. Thanks. -- H.J.
Re: RFC: Add STB_GNU_SECONDARY
"H.J. Lu" writes:
> On Fri, Apr 20, 2012 at 5:49 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> In our usage, the backup definition may not be at the end of
>>> command line since it may reference library symbols.
>>
>> You could write out the backup function you need under a different name.
>> Then have the backup symbol at the end of the link call the new name of
>> the backup function.
>
> isn't it replacing one backup with another backup?
Let's say your symbol is f. I'm proposing that in the object file you
write out
void
f_implementation ()
{
/* Whatever you want. */
/* Call library functions, etc. */
}
Then in an object at the end of the link, put
void
f () __attribute__ ((weak))
{
f_implementation ();
}
Ian
Re: RFC: Add STB_GNU_SECONDARY
Quoting "H.J. Lu" : We only have very few bits to in STB_XXX field. Well, you could put the information somewhere else. E.g. a special relocation, or a special elf section. Or you could mangle the information into the section name in which the symbol is present. Even better, you could use symbolic tags, and have the linker script assign precedence values to these tags. It won't help us. Maybe it wouldn't buy you more than the secondary symbols right now, but it would give a lot of flexibility to rearrange and combine different peoples ideas of link priority. Another thought on symbols priorities: with pthread, using symbols of different priorities is really a crutch - and it doesn't really work that well for static linking. What is really wanted is that whenever one of a set of object files is linked in, a whole set of symbols should be satisfied from a different place. Maybe if, for a static pthread, we'd put the pthread-aware I/O etc. into a special .text.pthread section or somesuch, which would normally discarded, but had a mechanism to use them if a special symbol is set (or used?) from an object file that provides a pthread API function.
