Re: Code optimization with GCSE
Jean Christophe Beyler writes:
> As we can see, all three are using the symbol_ref data before adding
> their offset. But after cse, we get this:
>
> (insn 5 2 6 2 ex1b.c:8 (set (reg/f:DI 74)
> (const:DI (plus:DI (symbol_ref:DI ("data") )
> (const_int 8 [0x8] 71 {movdi_internal} (nil))
>
> (insn 6 5 7 2 ex1b.c:8 (set (reg/f:DI 75)
> (symbol_ref:DI ("data") )) 71
> {movdi_internal} (nil))
You will have to debug CSE. The actual replacment is done in this loop in
cse_insn:
/* Terminate loop when replacement made. This must terminate since
the current contents will be tested and will always be valid. */
while (1)
{
Adam
Re: Problem with static linking
Zachary Turner wrote: > Hello, I've been trying to write a program that links to static > libraries, and I've been having a lot of difficulties. Was wondering > if someone can help me identify what's going wrong. > > The codebase is large, but is new to linux. It was originally > developed on windows and then ported to linux. It makes heavy use of > C++, STL, and boost and we'd like to (if possible) link *everything* > statically. This means libc, libgcc, libstdc++, boost, libpthread, > etc. Ian Taylor has explained that the messages about libc are spurious, so you can either ignore those or install some kind of a Valgrind exception. However, I really implore you: by all means link statically to everything else, but leave libc dynamically linked. I'm not aware of any reason not to link libc dynamically, and not doing so leads to a ton of problems. Andrew.
Is GDE available for now?
Hi, I read the paper "The Visual Development of GCC Plug-ins with GDE" from gcc summit 2009. It's a powerful tool. So where can I get it to help me debug and study gcc? Thanks a lot. Eric
Re: Problem with static linking
On Wed, Jul 15, 2009 at 09:37:32PM -0500, Zachary Turner wrote: > So I guess I have three questions. 1) Is this actually a problem or > are these errors spurious? 2) Why do they disappear when I delete the They are likely spurious. You get tons of valgrind warnings with dynamically linked ld.so/libc.so as well, they are just suppressed through a default valgrind suppression file. Obviously it is not possible to do the same with statically linked programs. valgrind doesn't grok tricks used e.g. in SSE2 strlen and a bunch of other memory/string ops. > -static option? and 3) Is there a way to fix them? I've even gone so > far as to manually run collect2 specifying my own hand edited command > line, but nothing I've tried there has worked either. Don't link statically, there are many reasons not to and only very few reasons for it (primarily exception is some system recovery tools that are supposed to work even when shared libraries are hosed). See http://people.redhat.com/drepper/no_static_linking.html Jakub
Re: How could I get alias set information from data_reference_p
On Thu, Jul 16, 2009 at 1:15 AM, Tobias
Grosser wrote:
> On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
>> On Wed, Jul 15, 2009 at 10:46 PM, Richard
>> Guenther wrote:
>> > On Wed, Jul 15, 2009 at 9:15 PM, Tobias
>> > Grosser wrote:
>> >>> A note on Lis final graph algorithm. I don't understand why you want
>> >>> to allow data-references to be part of multiple alias-sets? (Of course
>> >>> I don't know how you are going to use the alias-sets ...)
>> >>
>> >> Just to pass more information to Graphite. The easiest example might be
>> >> something like
>> >>
>> >> A -- B -- C
>> >>
>> >> if we have
>> >>
>> >> AS1 = {A,B}
>> >> AS2 = {B,C}
>> >>
>> >> we know that A and C do not alias and therefore do not have any
>> >
>> > No, from the above you _don't_ know that. How would you arrive
>> > at that conclusion?
>>
>> What I want to say is that, if A -- B -- C is supposed to be the alias graph
>> resulting from querying the alias oracle for the pairs (A, B), (A, C), (B, C)
>> then this is a result that will never occur. Because if (A, B) is true
>> and (B, C) is true then (A, C) will be true as well.
>
> What for example for this case:
>
> void foo (*b) {
> int *a
> int *c
>
> if (bar())
> a = b;
> else
> c = b;
> }
>
> I thought this may give us the example above, but it seems I am wrong.
> If the alias oracle is transitive that would simplify the algorithm a
> lot. Can we rely on the transitivity?
Actually I was too fast (or rather it was too late), an example with
A -- B -- C would be
int a, c;
void foo(int *p)
with B == (*p). B may alias a and c but a may not alias c.
So, back to my first question then, which is still valid.
Just to pass more information to Graphite. The easiest example might be
something like
A -- B -- C
if we have
AS1 = {A,B}
AS2 = {B,C}
we know that A and C do not alias and therefore do not have any
dependencies.
How do you derive at 'A and C do not alias' from looking at
the alias set numbers for AS1 and AS2. How do you still
figure out that B aliases A and C just from looking at
the alias set numbers? Or rather, what single alias set number
does B get?
Richard.
> Tobi
>
>
>
>
Preserve registers across function call (Re: CALL_USED_REGISTERS)
My name is Makoto Fujiwara, I am working a particular port
for private CPU (at the time being). The porting itself is
getting very well, I believe, say having more than 30,000 PASS
with testsuite. Although no execution available for that make check,
I am preparing gdb/sim based execution verification with separate
make check.
My question is:
The (gccint) info says,
---
If a register has 0 in `CALL_USED_REGISTERS',
the compiler automatically saves it on function entry and
restores it on function exit, if the register is used within
the function.
---
in the context attatched. ( I believe this info is with gcc-4.2.1)
But unfortunately, my port does not seem to work as described
above (no preserve code found at *.s output). The port is
based on 4.2.1 for the moment. I know either cpu.h or cpu.md is
wrong, but to trace the problem,
Could anyone suggest me which part of the src is taking care
of above save/restore processing ?
calls.c
function.c -> expand_function_{start,end}()
caller-save.c -> save_call_clobbered_regs()
reload1.c
or others ?
I believe it should be in function.c, but I can not figure out
which lines (function) to take care those things.
(or the explanation in info is obsolete ?)
Thanks in advance,
---
Makoto Fujiwara,
Chiba, Japan, Narita Airport and Disneyland prefecture.
(attachment)
15.7.1 Basic Characteristics of Registers
-
Registers have various characteristics.
-- Macro: FIRST_PSEUDO_REGISTER
...
-- Macro: FIXED_REGISTERS
...
-- Macro: CALL_USED_REGISTERS
Like `FIXED_REGISTERS' but has 1 for each register that is
clobbered (in general) by function calls as well as for fixed
registers. This macro therefore identifies the registers that are
not available for general allocation of values that must live
across function calls.
If a register has 0 in `CALL_USED_REGISTERS', the compiler
automatically saves it on function entry and restores it on
function exit, if the register is used within the function.
Re: How could I get alias set information from data_reference_p
Hi Richard,
On 7/16/09, Richard Guenther wrote:
> On Thu, Jul 16, 2009 at 1:15 AM, Tobias
> Grosser wrote:
>> On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
>>> On Wed, Jul 15, 2009 at 10:46 PM, Richard
>>> Guenther wrote:
>>> > On Wed, Jul 15, 2009 at 9:15 PM, Tobias
>>> > Grosser wrote:
>>> >>> A note on Lis final graph algorithm. I don't understand why you
>>> >>> want
>>> >>> to allow data-references to be part of multiple alias-sets? (Of
>>> >>> course
>>> >>> I don't know how you are going to use the alias-sets ...)
>>> >>
>>> >> Just to pass more information to Graphite. The easiest example might
>>> >> be
>>> >> something like
>>> >>
>>> >> A -- B -- C
>>> >>
>>> >> if we have
>>> >>
>>> >> AS1 = {A,B}
>>> >> AS2 = {B,C}
>>> >>
>>> >> we know that A and C do not alias and therefore do not have any
>>> >
>>> > No, from the above you _don't_ know that. How would you arrive
>>> > at that conclusion?
>>>
>>> What I want to say is that, if A -- B -- C is supposed to be the alias
>>> graph
>>> resulting from querying the alias oracle for the pairs (A, B), (A, C),
>>> (B, C)
>>> then this is a result that will never occur. Because if (A, B) is true
>>> and (B, C) is true then (A, C) will be true as well.
>>
>> What for example for this case:
>>
>> void foo (*b) {
>> int *a
>> int *c
>>
>> if (bar())
>>a = b;
>> else
>>c = b;
>> }
>>
>> I thought this may give us the example above, but it seems I am wrong.
>> If the alias oracle is transitive that would simplify the algorithm a
>> lot. Can we rely on the transitivity?
>
> Actually I was too fast (or rather it was too late), an example with
> A -- B -- C would be
>
> int a, c;
> void foo(int *p)
>
> with B == (*p). B may alias a and c but a may not alias c.
>
> So, back to my first question then, which is still valid.
>
> Just to pass more information to Graphite. The easiest example might be
> something like
>
> A -- B -- C
>
> if we have
>
> AS1 = {A,B}
> AS2 = {B,C}
>
> we know that A and C do not alias and therefore do not have any
> dependencies.
>
> How do you derive at 'A and C do not alias' from looking at
> the alias set numbers for AS1 and AS2. How do you still
> figure out that B aliases A and C just from looking at
> the alias set numbers? Or rather, what single alias set number
> does B get?
AS1 = {A,B}
AS2 = {B,C}
B is not neccessary to have only a single alias set number,
for this situation, B will have alias number both 1 and 2 (it
is in both alias set),
A will be with alias number 1 and
C will be with alias number 2.
So A and C got different alias set number, we could conclude
that they are not alias.
While for A and B or B and C, as B got alias number both 1 and 2,
so they may alias.
Li
Re: How could I get alias set information from data_reference_p
On Thu, Jul 16, 2009 at 11:00 AM, Li Feng wrote:
> Hi Richard,
> On 7/16/09, Richard Guenther wrote:
>> On Thu, Jul 16, 2009 at 1:15 AM, Tobias
>> Grosser wrote:
>>> On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
On Wed, Jul 15, 2009 at 10:46 PM, Richard
Guenther wrote:
> On Wed, Jul 15, 2009 at 9:15 PM, Tobias
> Grosser wrote:
>>> A note on Lis final graph algorithm. I don't understand why you
>>> want
>>> to allow data-references to be part of multiple alias-sets? (Of
>>> course
>>> I don't know how you are going to use the alias-sets ...)
>>
>> Just to pass more information to Graphite. The easiest example might
>> be
>> something like
>>
>> A -- B -- C
>>
>> if we have
>>
>> AS1 = {A,B}
>> AS2 = {B,C}
>>
>> we know that A and C do not alias and therefore do not have any
>
> No, from the above you _don't_ know that. How would you arrive
> at that conclusion?
What I want to say is that, if A -- B -- C is supposed to be the alias
graph
resulting from querying the alias oracle for the pairs (A, B), (A, C),
(B, C)
then this is a result that will never occur. Because if (A, B) is true
and (B, C) is true then (A, C) will be true as well.
>>>
>>> What for example for this case:
>>>
>>> void foo (*b) {
>>> int *a
>>> int *c
>>>
>>> if (bar())
>>> a = b;
>>> else
>>> c = b;
>>> }
>>>
>>> I thought this may give us the example above, but it seems I am wrong.
>>> If the alias oracle is transitive that would simplify the algorithm a
>>> lot. Can we rely on the transitivity?
>>
>> Actually I was too fast (or rather it was too late), an example with
>> A -- B -- C would be
>>
>> int a, c;
>> void foo(int *p)
>>
>> with B == (*p). B may alias a and c but a may not alias c.
>>
>> So, back to my first question then, which is still valid.
>>
>> Just to pass more information to Graphite. The easiest example might be
>> something like
>>
>> A -- B -- C
>>
>> if we have
>>
>> AS1 = {A,B}
>> AS2 = {B,C}
>>
>> we know that A and C do not alias and therefore do not have any
>> dependencies.
>>
>> How do you derive at 'A and C do not alias' from looking at
>> the alias set numbers for AS1 and AS2. How do you still
>> figure out that B aliases A and C just from looking at
>> the alias set numbers? Or rather, what single alias set number
>> does B get?
> AS1 = {A,B}
> AS2 = {B,C}
>
> B is not neccessary to have only a single alias set number,
> for this situation, B will have alias number both 1 and 2 (it
> is in both alias set),
> A will be with alias number 1 and
> C will be with alias number 2.
> So A and C got different alias set number, we could conclude
> that they are not alias.
> While for A and B or B and C, as B got alias number both 1 and 2,
> so they may alias.
I see. That would work.
Richard.
> Li
>
Re: [plugin] Directory for plugins distributed with gcc
> In general I think spinning off modules/passes that are not used very > frequently (e.g. the tree browser) is a good idea since it reduces the > size of our code base. I would go a bit further. One nice properties of plugins is that they have a more restrictive API. That should help us to get the code a bit more maintainable. Olatunji's work is a very nice example. For example, to make mudflap a plugin he had to remove the occurrences of "if (flag_mudflap)" and make mudflap use the existing generic varpool. > > Diego. > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: Problem with static linking
However, I really implore you: by all means link statically to everything else, but leave libc dynamically linked. I'm not aware of any reason not to link libc dynamically, and not doing so leads to a ton of problems. Problems also arise if one uses functions that use NSS (eg. getXbyY functions like gethostbyname). In which case, the GNU C library will try to do a dlopen on several libraries to find the right one.
Re: Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function?
On 07/15/2009 05:27 PM, Douglas B Rupp wrote: LEB0 and LEB1 are duplicated in the attached ivms assembly file from libgcc2. Note the first occurrence of each is at the prologue end, which makes no sense to me. FYI: I'm emitting the LPE labels at NOTE_INSN_FUNCTION_BEG and the LEB labels at NOTE_INSN_EPILOGUE_BEG. I can send you the full patch if you like. I deleted the .debug* sections to reduce the size of the file. Hmm. It looks like sched-ebb is moving the epilogue note farther away from the epilogue than I expected. Since only ia64 uses this scheduler, I hadn't noticed. I wonder what's the easiest way to handle this. As for the fact that they're both labeled .LEB0... that's surely an ia64 backend bug. Certainly there's no such problem with the generic dwarf2 output; if there were such a problem it would be preventing x86 bootstrap. r~
Re: Multiple calls to case NOTE_INSN_EPILOGUE_BEG for same function?
Richard Henderson wrote: On 07/15/2009 05:27 PM, Douglas B Rupp wrote: LEB0 and LEB1 are duplicated in the attached ivms assembly file from libgcc2. Note the first occurrence of each is at the prologue end, which makes no sense to me. FYI: I'm emitting the LPE labels at NOTE_INSN_FUNCTION_BEG and the LEB labels at NOTE_INSN_EPILOGUE_BEG. I can send you the full patch if you like. I deleted the .debug* sections to reduce the size of the file. Hmm. It looks like sched-ebb is moving the epilogue note farther away from the epilogue than I expected. Since only ia64 uses this scheduler, I hadn't noticed. I wonder what's the easiest way to handle this. As for the fact that they're both labeled .LEB0... that's surely an ia64 backend bug. Certainly there's no such problem with the generic dwarf2 output; if there were such a problem it would be preventing x86 bootstrap. Your right, the labeling is purely contrived to illustrate the problem. I can fix that bug by implementing the multiple epilogue ABI for VMS.
Re: Preserve registers across function call (Re: CALL_USED_REGISTERS)
On 07/16/2009 01:47 AM, Makoto Fujiwara wrote:
Could anyone suggest me which part of the src is taking care
of above save/restore processing ?
calls.c
function.c -> expand_function_{start,end}()
caller-save.c -> save_call_clobbered_regs()
reload1.c
or others ?
I believe it should be in function.c, but I can not figure out
which lines (function) to take care those things.
(or the explanation in info is obsolete ?)
This saving and restoring is *not* handled in generic parts of the
compiler. It is handled by the prologue and epilogue patterns in your
cpu.md file -- or, normally, by a functions in your cpu.c file, which is
invoked by the md patterns.
Look at gcc/config/moxie/moxie.c, moxie_expand_prologue; that's probably
the simplest port within gcc at present.
r~
Re: How could I get alias set information from data_reference_p
On Thu, Jul 16, 2009 at 5:00 AM, Li Feng wrote:
> Hi Richard,
> On 7/16/09, Richard Guenther wrote:
>> On Thu, Jul 16, 2009 at 1:15 AM, Tobias
>> Grosser wrote:
>>> On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
On Wed, Jul 15, 2009 at 10:46 PM, Richard
Guenther wrote:
> On Wed, Jul 15, 2009 at 9:15 PM, Tobias
> Grosser wrote:
>>> A note on Lis final graph algorithm. I don't understand why you
>>> want
>>> to allow data-references to be part of multiple alias-sets? (Of
>>> course
>>> I don't know how you are going to use the alias-sets ...)
>>
>> Just to pass more information to Graphite. The easiest example might
>> be
>> something like
>>
>> A -- B -- C
>>
>> if we have
>>
>> AS1 = {A,B}
>> AS2 = {B,C}
>>
>> we know that A and C do not alias and therefore do not have any
>
> No, from the above you _don't_ know that. How would you arrive
> at that conclusion?
What I want to say is that, if A -- B -- C is supposed to be the alias
graph
resulting from querying the alias oracle for the pairs (A, B), (A, C),
(B, C)
then this is a result that will never occur. Because if (A, B) is true
and (B, C) is true then (A, C) will be true as well.
>>>
>>> What for example for this case:
>>>
>>> void foo (*b) {
>>> int *a
>>> int *c
>>>
>>> if (bar())
>>> a = b;
>>> else
>>> c = b;
>>> }
>>>
>>> I thought this may give us the example above, but it seems I am wrong.
>>> If the alias oracle is transitive that would simplify the algorithm a
>>> lot. Can we rely on the transitivity?
>>
>> Actually I was too fast (or rather it was too late), an example with
>> A -- B -- C would be
>>
>> int a, c;
>> void foo(int *p)
>>
>> with B == (*p). B may alias a and c but a may not alias c.
>>
>> So, back to my first question then, which is still valid.
>>
>> Just to pass more information to Graphite. The easiest example might be
>> something like
>>
>> A -- B -- C
>>
>> if we have
>>
>> AS1 = {A,B}
>> AS2 = {B,C}
>>
>> we know that A and C do not alias and therefore do not have any
>> dependencies.
>>
>> How do you derive at 'A and C do not alias' from looking at
>> the alias set numbers for AS1 and AS2. How do you still
>> figure out that B aliases A and C just from looking at
>> the alias set numbers? Or rather, what single alias set number
>> does B get?
> AS1 = {A,B}
> AS2 = {B,C}
>
> B is not neccessary to have only a single alias set number,
> for this situation, B will have alias number both 1 and 2 (it
> is in both alias set),
> A will be with alias number 1 and
> C will be with alias number 2.
> So A and C got different alias set number, we could conclude
> that they are not alias.
> While for A and B or B and C, as B got alias number both 1 and 2,
> so they may alias.
So if i understand you right, it seems all you've done is inverted the
existing alias/points-to sets.
IE instead of saying A has B, C, D in it's alias set, you are saying B
is in the alias set of A, C is in the alias set of A, D is in the
alias set of A.
Effectively,
A -> {B, C, D}
B -> {C, D, E}
becomes
B -> A
C -> A, B
D -> A ,B
E -> B
Then you are assigning numbers to the sets that appear on the RHS.
You still end up with bitmaps, and you still have to intersect them
(or describe containment some other way and do containment queries).
For a large program, this mapping is actually massive and quite
expensive to compute (In points-to, normally you use location
equivalence and BDD's to compress the sets. I never got around to
finishing location equivalence inside GCC, though it is in the LLVM
implementation i did if you want to look).
--Dan
Re: How could I get alias set information from data_reference_p
On Thu, Jul 16, 2009 at 10:45, Daniel Berlin wrote:
> So if i understand you right, it seems all you've done is inverted the
> existing alias/points-to sets.
> IE instead of saying A has B, C, D in it's alias set, you are saying B
> is in the alias set of A, C is in the alias set of A, D is in the
> alias set of A.
>
> Effectively,
>
> A -> {B, C, D}
> B -> {C, D, E}
> becomes
> B -> A
> C -> A, B
> D -> A ,B
> E -> B
>
Yes, this is correct.
> Then you are assigning numbers to the sets that appear on the RHS.
Correct.
> You still end up with bitmaps, and you still have to intersect them
> (or describe containment some other way and do containment queries).
>
> For a large program, this mapping is actually massive and quite
> expensive to compute
In the case of Graphite, the queries are limited to the data
references within a SCoP. Usually a SCoP does not necessarily contain
huge amount of data references. In the future, we may also set
restrictions on the number of data references that we allow in a SCoP.
Sebastian
Re: can_throw_internal affected by inlining?
On 07/11/2009 05:59 AM, Jan Hubicka wrote:
Re: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01404.html
Do you have test cases for this?
Changing can_throw_internal/external to depend on whether or not future
inlining is possible looks *very* wrong to me. Surely the only thing
that matters for new code that might appear "below" this position in the
tree is whether or not it might throw, and the only thing that changes
with inlining is increased knowledge of whether and how it throws.
The problem here is fact that MUST_NOT_THROW region reachable only via
runtime is handled completely via runtime, however MUST_NOT_THROW region
reachable via RESX is eventually going to be handled by direct
std::terminate call, since RESX will eventually get translated as direct
goto to the MIST_NOT_THROW reciever.
I'm committing the following test case that displays the bug. It does
in fact pass with mainline, and does in fact fail with gcc 4.4.0.
I spent two days trying to come up with some cleaner way to fix this bug
than the inlinable flag you pass around, but to no avail. The only
thing better I could think of is some global flag (or state variable)
that indicates whether or not inlining is complete. At least then we
would not have to pass around that flag. But I wouldn't want to
introduce yet another boolean state variable; I'd much prefer all of the
existing state variables we have be consolidated, and I can't justify
spending the time on that just now.
Well, we can either teach inlinable_call_p to handle your new indirect
calls as "for sure uninlinable"
This is the approach I'll take. I've already hacked on an extra bit in
the gimple call subcode to indicate whether an indirect call is nothrow;
I might as well add another bit to say an indirect call is noinline.
r~
--- testsuite/g++.dg/opt/eh4.C (revision 149703)
+++ testsuite/g++.dg/opt/eh4.C (local)
@@ -0,0 +1,59 @@
+// { dg-do run }
+// { dg-options "-O3" }
+
+// Make sure that the call to terminate within F2 is not eliminated
+// by incorrect MUST_NOT_THROW optimization. Note that we expect F1
+// to be inlined into F2 in order to expose this case.
+
+#include
+#include
+
+static volatile int zero = 0;
+
+// Note that we need F0 to not be marked nothrow, though we don't actually
+// want a throw to happen at runtime here. The noinline tag is merely to
+// make sure the assembly in F0 is not unnecessarily complex.
+static void __attribute__((noinline)) f0()
+{
+ if (zero != 0)
+throw 0;
+}
+
+struct S1
+{
+ S1() { }
+ ~S1() { f0(); }
+};
+
+static void f1()
+{
+ S1 s1;
+ throw 1;
+}
+
+struct S2
+{
+ S2() { }
+ ~S2() { f1(); }
+};
+
+static void __attribute__((noinline)) f2()
+{
+ S2 s2;
+ throw 2;
+}
+
+static void pass()
+{
+ exit (0);
+}
+
+int main()
+{
+ std::set_terminate (pass);
+ try {
+f2();
+ } catch (...) {
+ }
+ abort ();
+}
Re: Is GDE available for now?
Eric Fisher writes: > I read the paper "The Visual Development of GCC Plug-ins with GDE" > from gcc summit 2009. It's a powerful tool. So where can I get it to > help me debug and study gcc? I think the best way to start would be to contact the authors of the paper. Their e-mail addresses are there. Ian
Re: Problem with static linking
Jakub Jelinek writes: >> -static option? and 3) Is there a way to fix them? I've even gone so >> far as to manually run collect2 specifying my own hand edited command >> line, but nothing I've tried there has worked either. > > Don't link statically, there are many reasons not to and only very few > reasons for it (primarily exception is some system recovery tools that are > supposed to work even when shared libraries are hosed). > See http://people.redhat.com/drepper/no_static_linking.html The main reason to link statically is the inverse of Ulrich's first reason to link dynamically: if you link dynamically, your program is vulnerable to changes in the shared libraries. If your program is carefully tuned and tested, then changes to shared libraries can introduce unexpected performance changes, or even, in the worst case, unexpected bugs. Another way to say "by fixing a dynamic library you can fix a bug in every program in one place" is "by distributing a new dynamic library, you can break every program at once." I think the argument against static linking does not consider the world where one builds a carefully tuned executable and then runs it for many years. In that environment, each change to a dynamic library requires careful retesting of all the affected programs. But it does not follow that we never want to change the library, because not all programs are performance sensitive, and new programs require new features. Ian
Re: Problem with static linking
Andrew Haley writes: >> [...] It makes heavy use of >> C++, STL, and boost and we'd like to (if possible) link *everything* >> statically. This means libc, libgcc, libstdc++, boost, libpthread, >> etc. > [...] > However, I really implore you: by all means link statically to everything > else, but leave libc dynamically linked. I'm not aware of any reason not > to link libc dynamically, and not doing so leads to a ton of problems. If they actually encounter that ton of problems, then they will change their minds about libc, regardless of preemptive imploring. - FChE
Re: Problem with static linking
On Thu, Jul 16, 2009 at 12:57 PM, Ian Lance Taylor wrote: > > Jakub Jelinek writes: > > >> -static option? and 3) Is there a way to fix them? I've even gone so > >> far as to manually run collect2 specifying my own hand edited command > >> line, but nothing I've tried there has worked either. > > > > Don't link statically, there are many reasons not to and only very few > > reasons for it (primarily exception is some system recovery tools that are > > supposed to work even when shared libraries are hosed). > > See http://people.redhat.com/drepper/no_static_linking.html > > The main reason to link statically is the inverse of Ulrich's first > reason to link dynamically: if you link dynamically, your program is > vulnerable to changes in the shared libraries. If your program is > carefully tuned and tested, then changes to shared libraries can > introduce unexpected performance changes, or even, in the worst case, > unexpected bugs. Another way to say "by fixing a dynamic library you > can fix a bug in every program in one place" is "by distributing a new > dynamic library, you can break every program at once." > > I think the argument against static linking does not consider the world > where one builds a carefully tuned executable and then runs it for many > years. In that environment, each change to a dynamic library requires > careful retesting of all the affected programs. But it does not follow > that we never want to change the library, because not all programs are > performance sensitive, and new programs require new features. > > Ian There's also much less to deal with from a Q/A and tech support perspective if you use static linking with a closed source application, since you can produce 1 binary which works across multiple distributions and kernels without the user compiling it, which is what I'm dealing with. Not necessarily enough to mandate linking everything statically, I actually have been advocating for a while to link everything dynamically. But it is how it is for now, and I suspect it will take more nagging and more time for there to be a real switch
Incorrect line info in printf for powerpc-eabisim -mhard-foat
Hi -- I've tracked down a failure in gdb to hit a breakpoint set at printf to the the breakpoint being placed incorrectly. Here is the code generated for printf with -mhard-float: .loc 1 29 0 .cfi_startproc .LVL0: mflr 0 stwu 1,-112(1) .LCFI0: .cfi_def_cfa_offset 112 stw 5,24(1) stw 0,116(1) stw 6,28(1) stw 7,32(1) stw 8,36(1) stw 9,40(1) stw 10,44(1) bne- 1,.L2 <<< - 1 .cfi_offset 65, 4 .loc 1 29 0 <<< - 2 stfd 1,48(1)<<< - 3 stfd 2,56(1) stfd 3,64(1) stfd 4,72(1) stfd 5,80(1) stfd 6,88(1) stfd 7,96(1) stfd 8,104(1) .L2: .loc 1 34 0 Gdb places a breakpoint at printf() at the stfd instruction (3). This appears to be because of the .loc at (2). When the code is executed, the branch (1) is taken, jumping over the the breakpoint. I think that the .loc at (2) should not be generated, since it is in the middle of the prologue code. I'll file a bug report unless someone already has done so. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
The Linux binutils 2.19.51.0.12 is released
Hi,
I fixed 2 local IFUNC symbol bugs.
H.J.
---
This is the beta release of binutils 2.19.51.0.12 for Linux, which is
based on binutils 2009 0716 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.19.51.0.12 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.19.51.0.11:
1. Update from binutils 2009 0716.
2. Fix x86 assembler for jumping to local STT_GNU_IFUNC symbols.
3. Fix x86 linker for relocatable link with local STT_GNU_IFUNC symbols.
4. Implement ppc STT_GNU_IFUNC support.
5. Support x86 FMA4.
6. Fix linker regression with Linux kernel build.
7. Support unordered references in DWARF reader.
8. Improve arm support.
9. Improve m10300 support.
10. Improve ppc support.
11. Improve spu support.
12. Improve gold support.
Changes from binutils 2.19.51.0.10:
1. Update from binutils 2009 0627.
2. Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337.
3. Add STB_GNU_UNIQUE support.
4. Fix objcopy on empty file. PR 10321.
5. Fix debug section for PE-COFF.
6. Suport build with gcc 4.5.0.
7. Improve arm support.
8. Improve ppc support.
9. Improve m10300 support.
10. Improve mep support.
11. Improve MacOS support.
12. Improve gold support.
Changes from binutils 2.19.51.0.9:
1. Update from binutils 2009 0618.
2. Update STT_GNU_IFUNC symbol support. PR 10269/10270.
3. Fix an assembler CFI bug. PR 10255.
4. Improve objdump. PR 10263/10288
5. Improve readelf.
6. Improve arm support.
7. Improve moxie support.
8. Improve spu support.
9. Improve vax support.
10. Improve COFF/PE support.
11. Improve MacOS support.
Changes from binutils 2.19.51.0.8:
1. Update from binutils 2009 0606.
2. Update STT_GNU_IFUNC symbol support.
Changes from binutils 2.19.51.0.7:
1. Update from binutils 2009 0603.
2. Fix STT_GNU_IFUNC symbol with pointer equality.
Changes from binutils 2.19.51.0.6:
1. Update from binutils 2009 0601.
2. Update STT_GNU_IFUNC support. PR 10205.
3. Fix x86 asssembler Intel syntax regression with '$'. PR 10198.
Changes from binutils 2.19.51.0.5:
1. Update from binutils 2009 0529.
2. Rewrite STT_GNU_IFUNC, R_386_IRELATIVE and R_X86_64_IRELATIVE linker
support for STT_GNU_IFUNC symbols in shared library, dynamic executable
and static executable.
3. Add plugin support.
4. Improve spu support.
Changes from binutils 2.19.51.0.4:
1. Update from binutils 200
Re: how to use expand_builtin_alloca
> Janboe Ye writes:
>> normally gcc will use expand_builtin_alloca to handle variable array.
>> But mudflap will force this function to return immediately to invoke
>> alloca explicit.
>>
>> Is there some way to still use expand_builtin_alloca without changing
>> gcc source code?
I don't think so.
Ian Lance Taylor writes:
> mudflap can't check accesses to memory allocated using alloca unless
> it overrides __builtin_alloca.
It can't currently. But instead of redirecting the call to a
heap-based alloca() wannabe in libmudflap/mf-hooks1.c, perhaps
mudflap could instrument alloca() by generating code like this
instead:
__builtin_alloca(N) --> GIMPLE_TRY_FINALLY( try {
ptr = __builtin_alloca(N)
__mf_register(ptr ...)
ptr;
} finally (attached to the function scope) {
__mf_unregister(ptr ...)
}
Or perhaps not, if alloca() can be used in loops in way that
prevents clean nesting of the try/finally.
OTOH, I believe the original poster's case came from gcc-synthesized
alloca's, coming from variable-length array allocation. Those in turn
might be represented with almost the normal mf_xform_decls(), while
letting __builtin_alloca() remain.
Either of these requires gcc changes though.
> [...] Although, of course, you could simply not use mudflap for the
> code in question.
The original poster's purpose is specifically to build bits of the
linux kernel with mudflap instrumentation.
- FChE
gcc-4.5-20090716 is now available
Snapshot gcc-4.5-20090716 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090716/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 149722 You'll find: gcc-4.5-20090716.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090716.tar.bz2 C front end and core compiler gcc-ada-4.5-20090716.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090716.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090716.tar.bz2 C++ front end and runtime gcc-java-4.5-20090716.tar.bz2 Java front end and runtime gcc-objc-4.5-20090716.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090716.tar.bz2The GCC testsuite Diffs from 4.5-20090709 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.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: bitfields: types vs modes?
> At the risk of being naive: implement it. I'm not quite sure what > you're looking for here? Ok, time to ask for a hint. I started at get_best_mode(), adding a TREE argument for the type, and worked my way out, adding arguments to functions as needed to propogate the type information. It's getting out of hand. Is there some easier way to track the type that an rtx came from? Perhaps we could call get_best_mode() earlier in the whole process, and put that mode in the rtx instead of BLKmode ?
Re: How could I get alias set information from data_reference_p
Hi Daniel,
On Thu, Jul 16, 2009 at 11:45 PM, Daniel Berlin wrote:
> On Thu, Jul 16, 2009 at 5:00 AM, Li Feng wrote:
>> Hi Richard,
>> On 7/16/09, Richard Guenther wrote:
>>> On Thu, Jul 16, 2009 at 1:15 AM, Tobias
>>> Grosser wrote:
On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
> On Wed, Jul 15, 2009 at 10:46 PM, Richard
> Guenther wrote:
> > On Wed, Jul 15, 2009 at 9:15 PM, Tobias
> > Grosser wrote:
> >>> A note on Lis final graph algorithm. I don't understand why you
> >>> want
> >>> to allow data-references to be part of multiple alias-sets? (Of
> >>> course
> >>> I don't know how you are going to use the alias-sets ...)
> >>
> >> Just to pass more information to Graphite. The easiest example might
> >> be
> >> something like
> >>
> >> A -- B -- C
> >>
> >> if we have
> >>
> >> AS1 = {A,B}
> >> AS2 = {B,C}
> >>
> >> we know that A and C do not alias and therefore do not have any
> >
> > No, from the above you _don't_ know that. How would you arrive
> > at that conclusion?
>
> What I want to say is that, if A -- B -- C is supposed to be the alias
> graph
> resulting from querying the alias oracle for the pairs (A, B), (A, C),
> (B, C)
> then this is a result that will never occur. Because if (A, B) is true
> and (B, C) is true then (A, C) will be true as well.
What for example for this case:
void foo (*b) {
int *a
int *c
if (bar())
a = b;
else
c = b;
}
I thought this may give us the example above, but it seems I am wrong.
If the alias oracle is transitive that would simplify the algorithm a
lot. Can we rely on the transitivity?
>>>
>>> Actually I was too fast (or rather it was too late), an example with
>>> A -- B -- C would be
>>>
>>> int a, c;
>>> void foo(int *p)
>>>
>>> with B == (*p). B may alias a and c but a may not alias c.
>>>
>>> So, back to my first question then, which is still valid.
>>>
>>> Just to pass more information to Graphite. The easiest example might be
>>> something like
>>>
>>> A -- B -- C
>>>
>>> if we have
>>>
>>> AS1 = {A,B}
>>> AS2 = {B,C}
>>>
>>> we know that A and C do not alias and therefore do not have any
>>> dependencies.
>>>
>>> How do you derive at 'A and C do not alias' from looking at
>>> the alias set numbers for AS1 and AS2. How do you still
>>> figure out that B aliases A and C just from looking at
>>> the alias set numbers? Or rather, what single alias set number
>>> does B get?
>> AS1 = {A,B}
>> AS2 = {B,C}
>>
>> B is not neccessary to have only a single alias set number,
>> for this situation, B will have alias number both 1 and 2 (it
>> is in both alias set),
>> A will be with alias number 1 and
>> C will be with alias number 2.
>> So A and C got different alias set number, we could conclude
>> that they are not alias.
>> While for A and B or B and C, as B got alias number both 1 and 2,
>> so they may alias.
>
> So if i understand you right, it seems all you've done is inverted the
> existing alias/points-to sets.
> IE instead of saying A has B, C, D in it's alias set, you are saying B
> is in the alias set of A, C is in the alias set of A, D is in the
> alias set of A.
>
> Effectively,
>
> A -> {B, C, D}
> B -> {C, D, E}
> becomes
> B -> A
> C -> A, B
> D -> A ,B
> E -> B
>
I'm not sure about your meaning by B,C,D in A's alias set.
If that means BandCandD may alias to A, but without saying
B,C,D will alias to each other or not, then I think we may
misunderstand somewhere.
If I understand you correctly, in your example, you mean that
B,C,D is connected(may alias) to A, and C,D,E is connected
to B. And no other relation ship between these A,B...E.
If this is true, then I think there will be 4 alias set. (We could
consider this problem as finding all the maximum cliques in an
undirected graph.)
alias set 1{A,B,C}
alias set 2{B,E}
alias set 3{B,D}
alias set 4{A,D}
So in our definition:
some data reference will be said in one alias set if they
may alias each other.
e.g.
If we have the following alias set
{A,B,C}
Then we should get A alias B, B alias C and C alias A.
> Then you are assigning numbers to the sets that appear on the RHS.
> You still end up with bitmaps, and you still have to intersect them
> (or describe containment some other way and do containment queries).
>
Bitmap is not necessary, in Graphite, we would like to pass these
alias information through access polyhedron, which will need this alias set
number.
So in Graphite, a poly_dr(polyhedron representation with data reference)
will hold this access polyhedron( a polyhedron which will hold access function
inforamtion and alias information), where
we could got the information we need when we would like
to check dependency between 2 poly_drs.
> For a large program, this mapping is actually massive and quite
> expensive to compute (In points-to, nor
