gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc
Hello,
I've proposed a patch [1] for condition coverage profiling in gcc,
implemented in the middle-end alongside the branch coverage. I've
written most of the tests for C and a few for C++ and finally got around
to try it with a toy example for D and go and noticed something odd
about Go's CFG construction.
abc.c:
int fn (int a, int b, int c) {
if (a && (b || c))
return a;
else
return b * c;
}
abc.d:
int fn (int a, int b, int c) {
if (a && (b || c))
return a;
else
return b * c;
}
abc.go:
func fn (a int, b int, c int) int {
a_ := a != 0;
b_ := b != 0;
c_ := c != 0;
if a_ && (b_ || c_) {
return 1;
} else {
return 0;
}
}
All were built with gcc --coverage -fprofile-conditions (my patch, but
it does not affect this) and no optimization. The C and D programs
behaved as expected:
gcov --conditions abc.d:
3:3:int fn (int a, int b, int c) {
3*:4:if (a && (b || c))
conditions outcomes covered 3/6
condition 1 not covered (false)
condition 2 not covered (true)
condition 2 not covered (false)
1:5:return a;
-:6:else
2:7:return b * c;
gcov --conditions abc.go:
3:5:func fn (a int, b int, c int) int {
3:6:a_ := a != 0;
3:7:b_ := b != 0;
3:8:c_ := c != 0;
-:9:
3*: 10:if a_ && (b_ || c_) {
condition outcomes covered 2/2
condition outcomes covered 1/2
condition 0 not covered (true)
condition outcomes covered 2/2
1: 11:return 1;
-: 12:} else {
2: 13:return 0;
-: 14:}
-: 15:}
So I dumped the gimple gcc -fdump-tree-gimple abc.go:
int main.fn (int a, int b, int c)
{
int D.2725;
int $ret0;
$ret0 = 0;
{
bool a_;
bool b_;
bool c_;
a_ = a != 0;
b_ = b != 0;
c_ = c != 0;
{
{
GOTMP.0 = a_;
if (GOTMP.0 != 0) goto ; else goto ;
:
{
{
GOTMP.1 = b_;
_1 = ~GOTMP.1;
if (_1 != 0) goto ; else goto ;
:
{
GOTMP.1 = c_;
}
:
}
GOTMP.2 = GOTMP.1;
GOTMP.0 = GOTMP.2;
}
:
}
if (GOTMP.0 != 0) goto ; else goto ;
:
{
{
$ret0 = 1;
D.2725 = $ret0;
// predicted unlikely by early return (on trees) predictor.
return D.2725;
}
}
:
{
{
$ret0 = 0;
D.2725 = $ret0;
// predicted unlikely by early return (on trees) predictor.
return D.2725;
}
}
}
}
}
Where as D (and C) is more-or-less as you would expect:
int fn (int a, int b, int c)
{
int D.7895;
if (a != 0) goto ; else goto ;
:
if (b != 0) goto ; else goto ;
:
if (c != 0) goto ; else goto ;
:
D.7895 = a;
// predicted unlikely by early return (on trees) predictor.
return D.7895;
:
D.7895 = b * c;
// predicted unlikely by early return (on trees) predictor.
return D.7895;
}
Clearly the decision inference algorithm is unable to properly
instrument to Go program for condition coverage because of the use of
temporaries in the emitted GIMPLE. The question is: is this intentional
and/or required from Go's semantics or could it be considered a defect?
Is emitting the GIMPLE without the use of temporaries feasible at all?
Thanks,
Jørgen
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598165.html
memory checkers and gcc support
I would like to investigate the possibility of reviving Checker (checkergcc), or providing another facility with similar capabilities. I would like to have it be as portable as possible, as I wish to use it on a number of different platforms. I would also like to have the sort of stack checking that Purify provides, and that Checker used to be able to do. Valgrind is an excellent product as far as it goes, but is x86 only, and apparently lacks the sort of stack checking that Purify and Checker have. The old "Checker" facility provided much of the functionality I'd like to have through its use of the "-fcheck-memory-usage" facility. I gather from the mailling list archives that this facility was removed about four years ago. Are there currently any other facilities in gcc for this kind of support for memory checkers ? If not, are there any plans for such support ? Does any of this sound practical ? If not, why not ? Does anyone have any good suggestions as for what I might familiarize myself with for doing this ? Best Regards, J. Hart
A variation of constructor attribute
It's nice that GCC has included a constructor attribute, but it doesn't work in complex scenarios. I was considering tinkering with adding a 'initializer' and '?exiter' or maybe 'deinitializer'? (not sure what to name the other side) But on to the primary... __attribute((initializer(priority))) similar to constructor, but, and especially significant under windows, doesn't run until just before main() is dispatched. The initializers would be added to a list (or linked into a list) so they will all run in-order. It's not always proper to run lowest level initializers first (at dynamic library load time), and under windows the dll loader lock that blocks thread creation prevents creation of threads in constructor or DllMain level initializers. By waiting until all libraries have been loaded, and then dispatching their initializers the thread block is overcome. I implemented for my own library a method of doing this; but it requires additional code be added to each library/executable that uses this. Perhaps there is a way to overcome 2 of the source files I include, but the third (the scheduling part) would still have to be added, which makes adding new projects annoying. (I add a source at start with a known, unique name that indicates the first in a __attribute__((section( "deadstart_list" ))) and another that's the last in the section, the third source knows the section and can iterate through the objects defined there and schedule them. In the program I link a 4th source that has a __attribute__((constructor)) that calls all the registered startups.) So this new attribute would create a data structure similar to constructor, with a few extra fields to support adding it in-place into a list, and a flag for dispatched. it is possible that the list will change as the list is processed too, since a initializer could load another library which has it's own intializer attributed functions with various priorities (perhaps priorities that are lower than what has already been processed). I do assume that this is like most other projects I've run into that 'if I want something done, I'll have to do it myself'. Here's a rough flow of a process consisting of program lib1, plugin1 program loads, lib1 gets loaded; using constructor attributes, initializers in lib1 run (and cannot create threads in windows)... but if lib1 actually has a high priority constructor that loads plugin1 not all of the constructors have nessecarily run, but plugin1's constructors will all run at that time; It may rely on higher priority constructors from lib1 which run after the point it's dynamically loaded. after scheduling the routines, and returning to main initializers, intializer routines should start running, and new libraries loaded during initialization should get their initializers scheduled at that time (which may include initializers that are higher in priority than the current running initializer). But after all initializers have run, when a new library is loaded initializers should run immediately... hmm requires support in dlopen/LoadLibrary function too, because again, have to return to code outside of the loading process to create threads so maybe it's not practical to implement
C2X Proposal, merge '.' and '->' C operators
Here's the gist of what I would propose...
https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
In C, there are two operators . and -> used to access members of struct and
union types. These operators are specified such that they are always paired
in usage; for example, if the left hand expression is a pointer to a struct
or union, then the operator -> MUST be used. There is no occasion where .
and -> may be interchanged, given the existing specification.
It should be very evident to the compiler whether the token before '.' or
'->' is a pointer to a struct/union or a struct/union, and just build the
appropriate output.
The source modification for the compiler is very slight, even depending on
flag_c2x(that's not it's name). It ends up changing a lot of existing
lines, just to change their indentation; but that shouldn't really count
against 'changed lines'.
I'm sure, after 4 score and some years ('78-19) that it must surely have
come up before? Anyone able to point me to those existing proposals?
D
Re: C2X Proposal, merge '.' and '->' C operators
This is a view of the patch/diff... This is really just +6 lines... ` if(
!flag_iso2xc) `{` `}` `attribute fallthrough` `if(flag_iso2cx)` `return
ptr`
https://github.com/gcc-mirror/gcc/pull/41/commits/915bcffdea0aa4fead66c41830b66aa3db212307
While the compiler does compile itself, and a simple test case,
successfully
```
#include
struct s {
int a, b;
};
void f( void ){
struct s S;
struct s *P = &S;
P.a = 5; // 'wrong' operator
P.b = 13; // 'wrong' operator
printf( "Output: %d %d\n", S->a, S->b ); // 'wrong' operators...
}
int main( void ) {
f();
return 0;
}
```
I haven't built the testsuite...
On Mon, Dec 16, 2019 at 5:51 AM J Decker wrote:
> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>
> In C, there are two operators . and -> used to access members of struct
> and union types. These operators are specified such that they are always
> paired in usage; for example, if the left hand expression is a pointer to a
> struct or union, then the operator -> MUST be used. There is no occasion
> where . and -> may be interchanged, given the existing specification.
>
> It should be very evident to the compiler whether the token before '.' or
> '->' is a pointer to a struct/union or a struct/union, and just build the
> appropriate output.
>
> The source modification for the compiler is very slight, even depending on
> flag_c2x(that's not it's name). It ends up changing a lot of existing
> lines, just to change their indentation; but that shouldn't really count
> against 'changed lines'.
>
> I'm sure, after 4 score and some years ('78-19) that it must surely have
> come up before? Anyone able to point me to those existing proposals?
>
> D
>
Re: C2X Proposal, merge '.' and '->' C operators
On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote: > * J. Decker: > > > Here's the gist of what I would propose... > > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da > > > > In C, there are two operators . and -> used to access members of struct > and > > union types. These operators are specified such that they are always > paired > > in usage; for example, if the left hand expression is a pointer to a > struct > > or union, then the operator -> MUST be used. There is no occasion where . > > and -> may be interchanged, given the existing specification. > > This is incompatible with C++. I don't think it's worthwhile to change > C in this way. > ya, while I only just saw this, I thought shortly after posting that c++ compatibility might be an issue; and they have separate operators overrides for -> and . (which V8 uses such that `Local lo;` `lo.IsEmpty();` and `lo->Get()` are interchangeable. However, if not specifically overridden it could be possible to make a similar change there. (and conversely not having the operator support the C++ back port wouldn't be an issue). It's still an error in the native language context to use '.' on a pointer or '->' on a class/struct... and the modification is really a patch to that error to just do the other thing... > > Thanks, > Florian > >
Re: C2X Proposal, merge '.' and '->' C operators
On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote: > > > On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote: > >> * J. Decker: >> >> > Here's the gist of what I would propose... >> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da >> > >> > In C, there are two operators . and -> used to access members of struct >> and >> > union types. These operators are specified such that they are always >> paired >> > in usage; for example, if the left hand expression is a pointer to a >> struct >> > or union, then the operator -> MUST be used. There is no occasion where >> . >> > and -> may be interchanged, given the existing specification. >> >> This is incompatible with C++. I don't think it's worthwhile to change >> C in this way. >> > > ya, while I only just saw this, I thought shortly after posting that c++ > compatibility might be an issue; and they have separate operators overrides > for -> and . (which V8 uses such that `Local lo;` `lo.IsEmpty();` > and `lo->Get()` are interchangeable. > > However, if not specifically overridden it could be possible to make a > similar change there. (and conversely not having the operator support the > C++ back port wouldn't be an issue). It's still an error in the native > language context to use '.' on a pointer or '->' on a class/struct... and > the modification is really a patch to that error to just do the other > thing... > and add -> on references? > > > >> >> Thanks, >> Florian >> >>
Re: C2X Proposal, merge '.' and '->' C operators
On Fri, Dec 20, 2019 at 12:03 PM J Decker wrote: > > > On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote: > >> >> >> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer >> wrote: >> >>> * J. Decker: >>> >>> > Here's the gist of what I would propose... >>> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da >>> > >>> > In C, there are two operators . and -> used to access members of >>> struct and >>> > union types. These operators are specified such that they are always >>> paired >>> > in usage; for example, if the left hand expression is a pointer to a >>> struct >>> > or union, then the operator -> MUST be used. There is no occasion >>> where . >>> > and -> may be interchanged, given the existing specification. >>> >>> This is incompatible with C++. I don't think it's worthwhile to change >>> C in this way. >>> >> >> ya, while I only just saw this, I thought shortly after posting that c++ >> compatibility might be an issue; and they have separate operators overrides >> for -> and . (which V8 uses such that `Local lo;` `lo.IsEmpty();` >> and `lo->Get()` are interchangeable. >> >> However, if not specifically overridden it could be possible to make a >> similar change there. (and conversely not having the operator support the >> C++ back port wouldn't be an issue). It's still an error in the native >> language context to use '.' on a pointer or '->' on a class/struct... and >> the modification is really a patch to that error to just do the other >> thing... >> > and add -> on references? > My first patch was to make the . and -> interchangeable; it could be more specifically to promote '.' to be either; with the intent to deprecate -> (in like 2119). This might simplify the scope of modification to C++; to just augment the default '.' to behave as -> on a native pointer to a struct/class/union ( I'm not sure how the new safe_ptr templated things end up reacting, I'd imagine they provide operator overloads, which would take precedence... ) > > >> >> >> >>> >>> Thanks, >>> Florian >>> >>>
Re: C2X Proposal, merge '.' and '->' C operators
On Sat, Dec 21, 2019 at 11:11 AM Allan Sandfeld Jensen
wrote:
> On Monday, 16 December 2019 14:51:38 CET J Decker wrote:
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access members of struct
> and
> > union types. These operators are specified such that they are always
> paired
> > in usage; for example, if the left hand expression is a pointer to a
> struct
> > or union, then the operator -> MUST be used. There is no occasion where .
> > and -> may be interchanged, given the existing specification.
> >
> > It should be very evident to the compiler whether the token before '.' or
> > '->' is a pointer to a struct/union or a struct/union, and just build the
> > appropriate output.
> >
> > The source modification for the compiler is very slight, even depending
> on
> > flag_c2x(that's not it's name). It ends up changing a lot of existing
> > lines, just to change their indentation; but that shouldn't really count
> > against 'changed lines'.
> >
> > I'm sure, after 4 score and some years ('78-19) that it must surely have
> > come up before? Anyone able to point me to those existing proposals?
> >
> What if you operate on a pointer to a pointer to a struct? Should the same
> operator just magically dereference everything until it is a struct?
>
> how does pointer to a pointer to a struct work now? Does it somehow
involve ppStruct->->a ?
> I disagree with this proposal because separate a thing and a pointer to a
> thing is fundamental to C/C++, and providing short-cuts that confuse the
> two
> is doing a disservice to anyone that needs to learn it.
>
> It's not to the assembly though.
To me, it's not a matter of it being a shorthand, but to make JS code more
portable back to C (and C++ compiled C).
> Besides isn't this the wrong mailing list for this?
>
> Probably? I thought it a better starting point than the bug list? Where
would you suggest I go? It doesn't look like C standards, unlike
es-discuss for ecma script, I couldn't find a open forum to discuss such
things... or even a github group like... https://github.com/tc39/proposals
J
> 'Allan
>
>
>
Re: would you review the srcy programming language?
Somewhat like assembly meets c99 /javascript with maybe an extended
preprocessor macro system (#declr? )
pointers rarely contain a single value, they either reference an array, or
a group of values. In the case of the latter, the pointerVarName.FieldName
pair specifies to get the value, and then any manipulation of
pointerVarName is always updating the pointer... so there isn't really a
need to have two operators to do that
I'm not neutral; I have VESL on my mind. VESL is like
blockly/scratch/snap/... except also able to create objects (structures
with elements).
I've recently come to re-learn javascript from a 2017 perspective, and have
come to learn that really the type of data in a variable is always
determined by the value that's put into the variable. Have it be any other
type than that type would catch developer errors; but with proper habits I
don't have the tendency to put a integer value in a field that should be
holding a string.
Even before learning JS I knew JSON for websocket communication. JSON
defines 3 types ( okay there's actually like 7 but...).
{ "stringValue": "String",
"numValue" : 1234,
"object" : {
},
"realNumValue" : 1234.0e-3,
"nothing" : null
"yesNo" : true/false (keywords)
}
For specific microoptimizaitons of space (like you need a whole bunch of
values that are only 0-255, specifying a byte type can be useful).
int(float), void*, bool. and struct userTypes *, and [] are the only
types I've been using for the last 15 years developing in C.
That and decoding network protocols made up of bytes, shorts, etc, type
information can be useful.
Javascript (since ES5/6) has had TypedArray, which gives you optimal
uint8Array so you can have a string of packed bytes in memory, and the JIT
gets to generate fast code to access it without boxing it into integer
types always; This is required for things like Three.jS (Really WebGL ) to
work... sending vertex information from javascript in packed float arrays
to C++ Code to openGL driver eventually...
Not that everything can entirely be done in JS. I have a C++ addon that
provides many system abstractions that Node doesn't; but making an API for
javascript to utilize is almost eaiser than making an API for C/C++ to use,
because in JS you can just make one of the objects, and dump it to see what
fields/methods it has (right then and there).
so with JSON I get named variables and values, so I don't need 'var', and
there are no parenthesis in JSON (outside of quotes). So there are no
functions/expressions.
so simply saying { myFunction : (args... ) { ... } } means I don't need
the function keyword, and the definition of a function is always
a name (paren) (args) (closeparen) followed by a code block. If there is
no code block after it (it's a close statemtn like , or ; ... or it's an
operator, then it is a call, and the arguments are expressions instead of
name definitions for the function code block.
What I lose then... is without var or function, I can't really use let or
const.
https://github.com/d3x0r/VESL/blob/master/vesl.md
But then, as a VPL (visual programming language) I really want to use text
as little as possible. Typing in names to create lables for blocks then
allows me to have a visual representaiton of that for later use, so I only
need to type each name for each class once and then I don't have to
represent 'function' 'profcedure' 'this returns a value' 'this doesn't' ...
On Mon, Mar 19, 2018 at 8:36 PM, wce teky wrote:
> hi!
>
> i'm the dotre, and i am designing a programming language,
> you may be interested at, it is general purpose, structured,
> imperative, data-driven and autonomous; i have already its
> syntax and very brief introduction as documentation. it is
> documented with google docs, but it can be downloaded
> with a browser as plain text.
>
> see you!
>
> https://drive.google.com/drive/folders/1jf_iP9F_Iz_dGSYUzx9Xz-Od24qkchMH
>
nested switch optimization
Hello
i have code:
void a(int i)
{
switch(i)
{
default:
switch(i) // exactly that same i
{
case 0:
f0();
break;
case 1:
f1();
break;
case 2:
f2();
break;
case 3:
f3a();
break;
}
break;
case 3:
f3();
break;
case 4:
f4();
break;
}
}
will be possible to add optimization that merge this two (or more) switch in
one big one (even if inner one is from inline function?) and then use one jump
table for both switches?
goal is to made that previous switch work exactly like this switch:
void a(int i)
{
switch(i)
{
case 0:
f0();
break;
case 1:
f1();
break;
case 2:
f2();
break;
//case 3: ignored because you cant get here
//f3a();
//break;
case 3:
f3();
break;
case 4:
f4();
break;
}
}
propose of this is to made switch work better with c++ templates (especially
variadic one).
with that change you could easily modify number of cases in switch only editing
one value in template argument (or adding new argument).
GCC 4.5.0 Reports invalid warning
This is the code.
--
#define PointerA struct a *
void f( PointerA );
typedef struct a * PA;
struct a { int x; };
void f( PA a )
{
}
-
This is the output
warning: 'struct a' declared inside parameter list
warning: its scope is only this definition or declaration, which is
probably not what you want
error: conflicting types for 'f'
note: previous declaration of 'f' was here
This is valid C code by every other compiler.
If there is already a thread about this, or a bug about it, I didn't
find it searching this lsit or the bugs database.
If I move even the 'typedef struct a *PA' above the first function,
then 'struct a' is apparently defined, even if it is not.
Re: GCC 4.5.0 Reports invalid warning
On Thu, Jul 15, 2010 at 5:32 PM, Dave Korn wrote:
> On 16/07/2010 00:59, J Decker wrote:
>
>> --
>>
>> #define PointerA struct a *
>>
>> void f( PointerA );
>>
>> typedef struct a * PA;
>> struct a { int x; };
>>
>> void f( PA a )
>> {
>> }
>>
>> -
>>
>> This is the output
>>
>> warning: 'struct a' declared inside parameter list
>> warning: its scope is only this definition or declaration, which is
>> probably not what you want
>> error: conflicting types for 'f'
>> note: previous declaration of 'f' was here
>>
>>
>>
>>
>> This is valid C code by every other compiler.
>
> Not so, as far as I can tell. Comeau online says:
>
>> Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
>> Copyright 1988-2008 Comeau Computing. All rights reserved.
>> MODE:strict errors C99
>>
>> "ComeauTest.c", line 3: warning: declaration is not visible outside of
>> function
>> void f( PointerA );
>> ^
>>
>> "ComeauTest.c", line 8: error: declaration is incompatible with "void
>> f(struct a *)"
>> (declared at line 3)
>> void f( PA a )
>> ^
>>
>> 1 error detected in the compilation of "ComeauTest.c".
>
> As long as "struct a" hasn't been (forward-)declared at the time the
> declaration of f() is found, it is a different one from the "struct a" in the
> global namespace that the formal parameter on the definition of f() then
> subsequently refers to.
>
Okay so if I just move the typedef up... (which isn't exactly feasible
in the actual project)
>>
>> #define PointerA struct a *
>>
>> typedef struct a * PA;
>> void f( PointerA );
>>
>> struct a { int x; };
>>
>> void f( PA a )
>> {
>> }
Now it's happy, why can't it just define 'struct a' as an appropriate
name as it used to, the strucutre still isn't defined.
(okay every other compiler I mention is MSVC, OpenWatcom, lcc, and gcc
before now)
> cheers,
> DaveK
>
>
Re: GCC 4.5.0 Reports invalid warning
Oh not so bad then, I can just add at the beginning...
typedef struct a *NeverUsedDefinition;
and now it's happy? And that makes good coding how? If I never
actually use 'NeverUsedDefinition'? Actually this 'feature' now
causes useless and unused declartions to be created.
On Thu, Jul 15, 2010 at 5:21 PM, J Decker wrote:
> On Thu, Jul 15, 2010 at 5:32 PM, Dave Korn wrote:
>> On 16/07/2010 00:59, J Decker wrote:
>>
>>> --
>>>
>>> #define PointerA struct a *
>>>
>>> void f( PointerA );
>>>
>>> typedef struct a * PA;
>>> struct a { int x; };
>>>
>>> void f( PA a )
>>> {
>>> }
>>>
>>> -
>>>
>>> This is the output
>>>
>>> warning: 'struct a' declared inside parameter list
>>> warning: its scope is only this definition or declaration, which is
>>> probably not what you want
>>> error: conflicting types for 'f'
>>> note: previous declaration of 'f' was here
>>>
>>>
>>>
>>>
>>> This is valid C code by every other compiler.
>>
>> Not so, as far as I can tell. Comeau online says:
>>
>>> Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
>>> Copyright 1988-2008 Comeau Computing. All rights reserved.
>>> MODE:strict errors C99
>>>
>>> "ComeauTest.c", line 3: warning: declaration is not visible outside of
>>> function
>>> void f( PointerA );
>>> ^
>>>
>>> "ComeauTest.c", line 8: error: declaration is incompatible with "void
>>> f(struct a *)"
>>> (declared at line 3)
>>> void f( PA a )
>>> ^
>>>
>>> 1 error detected in the compilation of "ComeauTest.c".
>>
>> As long as "struct a" hasn't been (forward-)declared at the time the
>> declaration of f() is found, it is a different one from the "struct a" in the
>> global namespace that the formal parameter on the definition of f() then
>> subsequently refers to.
>>
>
> Okay so if I just move the typedef up... (which isn't exactly feasible
> in the actual project)
>
>
>>>
>>> #define PointerA struct a *
>>>
>>> typedef struct a * PA;
>>> void f( PointerA );
>>>
>>> struct a { int x; };
>>>
>>> void f( PA a )
>>> {
>>> }
>
> Now it's happy, why can't it just define 'struct a' as an appropriate
> name as it used to, the strucutre still isn't defined.
>
> (okay every other compiler I mention is MSVC, OpenWatcom, lcc, and gcc
> before now)
>
>> cheers,
>> DaveK
>>
>>
>
Re: GCC 4.5.0 Reports invalid warning
On Thu, Jul 15, 2010 at 6:08 PM, Dave Korn wrote: > On 16/07/2010 01:31, J Decker wrote: >> Oh not so bad then, I can just add at the beginning... >> >> typedef struct a *NeverUsedDefinition; >> >> and now it's happy? And that makes good coding how? > > No, that would be bad coding. Just forward-declare the tag: > > struct a; > > before you try and use it in a function's formal parameter list. > > The declarations in a function's formal parameter list are in a more inner > scope than file scope, so if there isn't a tag declaration at file scope yet, > you're talking about a new tag declaration limited only to the scope in which > it is declared - the function declaration (argument list and body, if present; > just argument list in the case of a prototype). > > When you later do declare a "struct a" tag at file scope, the later > definition of f() "inherits" that one from the more global scope, just like it > would "inherit" the name of a global variable from the enclosing scope. In > the C language spec: > > 6.7.2.3#4: "All declarations of structure, union, or enumerated types that > have the same scope and use the same tag declare the same type." > Then how does this result in the warnings even that type 'struct a' does not match target 'struct a'? (or some paraphrase of that, this sample code did not generate exactly the same warnings as the full project. How could two definitions of struct a be defined? > 6.7.2.3#5: "Two declarations of structure, union, or enumerated types which > are in different scopes or use different tags declare distinct types." > Okay, and how is this out of scope? it's a global prototype, and the struct must without question also be defined in said global scope. When would it ever be something other than this? Although I did go back and read the error more appropriately. Okay I'm leaving this list. > > cheers, > DaveK > >
�yJ-REIT.NET�z�s���Y���������p�����f�[�^�x�[�X����
J-REIT.NETãâââââââââââââââââââââââââââ ãâªâªãä¸åç£å£²è²·äºä¾æ¤ç´¢ç¨ã®ç¡æãã¼ã¿ãã¼ã¹ã®ãæ¡å ãâ«â« âââââââââââââââââââââââââââââââââ J-REIT.NETã¯ãJ-REITã®å£²è²·äºä¾ãéç´ãããå¼·åãªåææ©è½ãæãã ä¸åç£å£²è²·ãã¼ã¿ãã¼ã¹ã§ãã ãã ãã¾ãJ-REIT.NETã¯ãã¼ã¿çã§ã®éå¶ãè¡ã£ã¦ããã¾ãããã·ã¹ãã æ¹è¯ã®ããã®ç¡æä¼å¡ãåéãã¦ããããé£çµ¡ããã¦é ãã¾ããã http://www.j-reit.net/ J-REIT.NETã§ã¯ãä¸åç£å£²è²·ãã¼ã¿ãã¼ã¹ãã以ä¸ã®ãããªå種ã¹ã³ã¢ã åæãã ä¸åç£å£²è²·ãè¡ãä¸åç£ãã¡ã³ãã®åèæ å ±ã¨ãã¦ãéè¡çã® ã¬ã³ãã¼ã®æ ä¿ç©ä»¶ã®åææ å ±ã¨ãã¦ã ä¸åç£éå®æ¥è ã®åèæ å ±ã¨ã㦠ã®æ å ±ãæä¾ãã¾ãã ãªããå ¨ã¦ã®ç©ä»¶æ å ±ã¯å°å·ç»é¢ãç¨æãã¦ãã¾ãã®ã§ããã®ã¾ã¾ããªã³ã ã¢ã¦ããã¦é ãã äºä¾ã¨ãã¦å©ç¨ãã§ãã¾ãã â ãJ-REIT売買æ å ± ã»J-REITã®ç©ä»¶å£²è²·æ å ±ã®ä¸è¦§è¡¨ç¤º ã»å£²è²·ç©ä»¶ãã¨ã®åå¼å©åãï¼ãã£ããã¬ã¼ãï¼CAP RATEï¼ ã»ç©ä»¶åçåï¼NOIã»NCFï¼ ã»ç©ä»¶æçï¼è³è²¸åçã»è³è²¸è²»ç¨ã»æ¸ä¾¡åå´è²»ã»CAPEXï¼ ã»æå¹åªå価 ã»ç©ä»¶ç¨®å¥ã»å°åã»åå¼ææã«ããåå¼äºä¾ã®æ¤ç´¢ ã»å°åãã¨å©åãæ¯è¼ãªã©å種ã©ã³ãã³ã° ã»J-REITã®é©æé示ï¼IRæ å ±ï¼ã¸ã®ãªã³ã¯ ã»ãGoogle ããããã«ããç©ä»¶å°å³ã表示 â ãä¸å ´ä¼æ¥å£²è²·æ å ± ã»ä¸å ´ä¼æ¥ã®ç©ä»¶å£²è²·æ å ±ã®ä¸è¦§è¡¨ç¤º ã»åå°åªå価 ã»å»¶åºå価 ã»é©æé示ï¼IRæ å ±ï¼ã¸ã®ãªã³ã¯ â ããå©ç¨æ¹æ³ ç¾å¨ãã¼ã¿çã§ã®éç¨ãè¡ã£ã¦ãã¾ããããã¼ã¿çã®å©ç¨ã«ã¯äºåç»é²ã å¿ è¦ã§ãï¼ç»é²ã¯ç¡æã§ãï¼ã ãå©ç¨ãããæ¹ã¯ä¸è¨ãã©ã¼ã ããE-MAILã®ç»é²ããé¡ãè´ãã¾ãã http://www.j-reit.net/trd/trd_login_menu.php â¡ãæ°çJ-REIT売買äºä¾ ææ°ã®å£²è²·äºä¾ããå±ããã¾ãã ã»20100804: ãã»ã©ã¤ãæè³æ³äºº(ãã¥ã¼ã·ãã£ã¬ã¸ãã³ã¹æ¹åï¼å£²å´ï¼) http://www.j-reit.net/trd/trd_des.php?t=2103 ã»20100729: ãªãªãã¯ã¹ä¸åç£æè³æ³äºº(ãªãªãã¯ã¹ç®é»ãã«) http://www.j-reit.net/trd/trd_des.php?t=2102 ã»20100726: æ¥æ¬è³è²¸ä½å® æè³æ³äºº(ãã«ãããæ¨ªæ¿±æ ¹å²¸ï¼å£²å´ï¼) http://www.j-reit.net/trd/trd_des.php?t=2101 ã»20100713: æ¥æ¬ãã©ã¤ã ãªã¢ã«ãã£æè³æ³äºº(ããã¯ã¹æ°å®¿ãã«ï¼è¿½å åå¾åï¼) http://www.j-reit.net/trd/trd_des.php?t=2100 ã»20100708: éæä¸åç£ã¬ã¸ãã³ã·ã£ã«æè³æ³äºº(ã¢ã¼ãã³ã¹ãã¼ã¸æ¿æ©åºå½¹æå) http://www.j-reit.net/trd/trd_des.php?t=2098 ã»20100708: ãªãªãã¯ã¹ä¸åç£æè³æ³äºº(ã©ã¦ã³ãã¯ãã¹èµ¤åè¦éï¼å£²å´ï¼) http://www.j-reit.net/trd/trd_des.php?t=2099 ã»20100630: ã¤ã³ã´ã£ã³ã·ãã«æè³æ³äºº(ã¬ãã·ã³ãã³ã»ãã©ã¶åºå³¶å¤§æçºï¼å£²å´ï¼) http://www.j-reit.net/trd/trd_des.php?t=2096 ã»20100630: ã¤ã³ã´ã£ã³ã·ãã«æè³æ³äºº(ããã°ã¿ã¯ã¼å 3 æ¡ï¼å£²å´ï¼) http://www.j-reit.net/trd/trd_des.php?t=2095 ã»20100630: ã¤ã³ã´ã£ã³ã·ãã«æè³æ³äºº(ã¬ãã·ã³ãã³ã»ã¹ã¯ã¨ã¢ä¼è¦ï¼å£²å´ï¼) http://www.j-reit.net/trd/trd_des.php?t=2094 ã»20100629: ãã»ã©ã¤ãæè³æ³äºº(ã¤ãã»å¸ã¶è°·) http://www.j-reit.net/trd/trd_des.php?t=2092 ã»20100629: ãã»ã©ã¤ãæè³æ³äºº(ã©ã¤ãªã³ãºãã³ã·ã§ã³æ±éæ¢ ç¬¬ä¸ï¼å£²å´ï¼) http://www.j-reit.net/trd/trd_des.php?t=2091 â¡ãCRE(ä¼æ¥ä¸åç£)æ å ±ï¼ææ°å£²è²·äºä¾ J-REIT.NETã§ã¯ãä¼æ¥ã®ä¸åç£ã®å£²è²·äºä¾ã«ã¤ãã¦ãé示ãã¦ãã¾ãã http://www.j-reit.net/ ææ°ã®å£²è²·äºä¾ããå±ããã¾ãã ã»20100729: ãªã¾ã¼ããã©ã¹ã(æ ª)(ç¥æ¸å¸çåºå ç²å±±çºåå°) http://www.j-reit.net/trd/trd_com_des.php?t=94 ã»20100727: æ±äº¬ã¤ã³ã(æ ª)(å¼ççæ¯ä¼é¡é éã»ã³ã¿ã¼) http://www.j-reit.net/trd/trd_com_des.php?t=93 ã»20100726: ãã¼ã»ã¤(æ ª)(ãã«ãããæ¨ªæ¿±æ ¹å²¸) http://www.j-reit.net/trd/trd_com_des.php?t=92 ã»20100630: (æ ª)ã¨ãã»ãã¼ã»ã·ã¼(æåªçæ¾å±±å¸å»ºç©) http://www.j-reit.net/trd/trd_com_des.php?t=91 ã»20100629: ãã¯ãã«ã«é»å(æ ª)(大ç°åºå¤§æ£®è¥¿åå°) http://www.j-reit.net/trd/trd_com_des.php?t=89 ã»20100629: ã¯ã©ãã¦(æ§åæ·ãããªå ¬åè·¡å°ã®ä¸é¨ï¼å£²å´ï¼) http://www.j-reit.net/trd/trd_com_des.php?t=90 ã»20100618: ãã¼ã«ã(æ ª)(å®®åçé»å·é¡æ´å°) http://www.j-reit.net/trd/trd_com_des.php?t=88 ã»20100615: ã¿ã¤ã¨ã¼ã¨ã¬ãã¯(æ ª)(ç¬æ¸å·¥å ´ï¼æç¥çç¬æ¸å¸ï¼) http://www.j-reit.net/trd/trd_com_des.php?t=87 ã»20100615: (æ ª)ã¨ãã»ãã¼ã»ã·ã¼(æåªçæ¾å±±å¸è¥¿å£ççº åå°) http://www.j
Re: Guidance needed: hi-level steps to track an object until its destruction
Just out of curiosity - isn't this what C# does with objects? would it perhaps be something like that in how mcs (mono) builds objects and tracks their lifespan? On Sun, Aug 29, 2010 at 4:43 AM, Uday P. Khedker wrote: > >> I am not sure that is easily feasible. I would believe it is impossible. >> >> Within the compiler (or inside a GCC plugin, or inside a GCC extension >> coded in MELT), you probably are able change/inspect C++ classes& every >> other declaration any compiler is tracking. You are also able to find >> every occurrence of variables containing a pointer to such classes. > >> >> However, you are apparently willing to track a single *instance* of such >> a class, and this instance is in the execution of the compiled program >> [not inside the compiler]. This means that you are able to deal with all > > > To put it in other words: Here the issue is seeking runtime information at > compile time. An object is a run time entity. At compile time, we only see > the class. However, we also see the statements that create an object and > manipulate it. Although it is not possible to track each object distinctly, > a compile time approximation is certainly possible. And that is where > creativity > in compiler research lies. The better the approximations, the better the > gains. > For example, all objects that get created by a given statement can be > treated > alike. There is no way of distinguishing between them at compile time, but > perhaps > there is no need to do so because all of them are likely to be treated alike > at run time. if an object O1 and O2 are created by the same statement, > asking > the question whether a method m1 is invoked for O1 does not need us to > distinguish > between O1 and O2. > > To summarize, a good approximation is indeed possible at compile time. > > >> the aliasing& pointer equivalence issues (a task known to be >> impossible). How can the compiler surely know that pointer p in [a >> particular instruction of] method YourClass::foo() is never (or >> sometimes, or always) pointing to the same instance -in the running >> process of the compiled program- as pointer q in method yourclass::bar() > > Basile, you keep mentioning that English is not your first language and I > appreciate your politeness for reminding the reader for that (English is not > the first language for me too). It is in that light that I would like to > point > out that your use of word "impossible" is a little too strong. Perhaps you > mean > difficult. It is impossible if you want exact information. However, if > imprecisions can be tolerated for some gains, excellent approximations are > possible _within_ a procedure body which is what Jeff asked for, to begin > with. > > We have been working on this problem (pointer analysis) for a while but > are quite far from production implementation. Our ideas now seem to mature > a bit and whenever we have a conference paper, I will be happy to share it > with the gcc folks. > >> Or maybe you want to instrument your compiler so that for every code >> emitted for method yourclass::gee() you add a first block which checks >> that the this reciever is not a given pointer. >> >> In other words& C++ parlance, you could (this is doable, but not >> trivial) hack the compiler so that at the start of every method (i.e. >> member function in C++) the equivalent of the following C++ code has >> been magically added >> >> extern "C" YourClass* hunted_yourclass_pointer; >> extern "C" void some_error_routine(void); >> >> if (this == hunted_yourclass_pointer) >> some_error_routine(); > > This is a very good way of paraphrasing the "ideal" requirement. > > Regards, > > Uday. >
Re: array of pointer to function support in GNU C
On Wed, Sep 15, 2010 at 11:15 PM, ir_idjit wrote:
>
> i've been writing bits of codes where it requires to have an array or
> "pointers to functions", so the decision of which function to execute is
> indexed... (i know, a lot of you will say "well, that's a VERY specific of a
> solution, there's always the problem of binary compatibility when passing
> arguments for different argument-taking functions, blah, blah, blah... just
> rely on good old fashioned function calls with conditional statements..."
> but, pls, forget about that sort of incompatibility...)
>
> even if i hadn't tried it in C++, i know it should work as i've seen some
> examples posted on the net. but i'm trying to write my code in GNU C, so it
> could be compiled by GCC -- god knows i would never try to compile it in GNU
> C++; that gargantuan thing
>
> but whatever i do it i just can't get it to work
> code:
>
> some_header.h:
> static void *(*oper_table)(void **);
>
>
>
> main.c:
> int main(void)
> {
> oper_table[0]; /* just a test. data is not used or modified*/
oper_table[0](NULL); // you decoared it to receive a parameter... and
even if it didn't you'd need ().
> return 1;
> }
>
> error: subscripted value is pointer to function
>
>
>
>
> whereas:
> int main(void)
> {
> void *(*func)(void **);
> func;
strange that this does anything... since it also requires a pointer to
a pointer...
> return 1;
> }
>
> compiles just fine
>
> i do realize that i'm depending on dialect-specific features, so i don't
> even know if this is supported on my gcc as of version 4.3.3. if it's not a
> dialect problem, then this stumps me even more.
> --
> View this message in context:
> http://old.nabble.com/array-of-pointer-to-function-support-in-GNU-C-tp29725303p29725303.html
> Sent from the gcc - Dev mailing list archive at Nabble.com.
>
>
signed/unsigned comparison warning level
Can the severity of signed/unsigned comparisons be raised, since GCC
does not properly handle the comparisons.
Every example below is false compiled with gcc 4.5.0
int main()
{
int s = -2;
unsigned int u = 0xFFFDU;
if( s < u )
printf( "okay\n" );
else
printf( "incorrect handling\n" ); // gets here
{
int i = -2;
unsigned u = 2;
if (i < u) {
// Does GCC get here? no, it doesn't
printf( "Ya, of course\n" );
}
else
printf( "gcc puked\n" ); // gets here
}
{
unsigned int i = -3;
if( i < 0 )
printf( "this can't happen, it's unsigned.\n" );
else
printf( "this is actually a correct result here\n" ); // does
get this
}
{
int i = -3;
// visual studio does not warn on this one either... just the first
two comparisons
if( i < (unsigned)0 )
printf( "-3 is < 0 \n" );
else
printf( "-3 is more than 0?\n" ); // gets here
}
return 0;
}
---
I said a lot of words on
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/d0ec33f0-2534-48f8-9673-538d68d8ef86
to describe how this might be handled and even if 5% of the cases
were fixed, it would be 250% better overall.
I don't know why standards left this open, other than there isn't a
single-instruction translation from code to CPU for the comparison;
But if it's not fixed, this warning should definatly be issued at
default warning level. This should be more like 'if this comparison
can be wrong, it will be wrong'.
Re: signed/unsigned comparison warning level
> The standards did not leave this open. They define precisely what is > supposed to happen. > Really? I'll have to drop this whole lobbying effort then. That makes me sad that they didn't define it to be comparing of the numbers where there are overlaps in signed and unsigned instead of causing all negative signed values to be wrong. > >> But if it's not fixed, this warning should definatly be issued at >> default warning level. This should be more like 'if this comparison >> can be wrong, it will be wrong'. > > There is no problem comparing values of signed type with values of > unsigned type if the signed values are known to be nonnegative. Of > course it is sometimes hard to know that; hence the warning. But > enabling the warning by default does not make sense. > It's exactly the fact that 'of course it is sometimes' that makes the warning make more sense to be on by default. I don't always know that I've added an unsigned value to an expression, causing one side of a comparison to become unsigned, resulting in 100% failure on negative signed result comparison. > Ian >
Re: signed/unsigned comparison warning level
unless x is an integer larger than 1/2 UINT_MAX... then it's still a bad test. it's safer to test if the signed is less than 0 otherwise cast that to unsigned. On Sun, Sep 26, 2010 at 10:06 PM, foxmuldrs...@yahoo.com wrote: > Use the explicit override if you need signed comparison. > > unsigned int x; > int y; > if ((int)x < y) > > -Rick > > -Original message- > > From: J Decker > To: Ian Lance Taylor > Cc: gcc@gcc.gnu.org > Sent: Mon, Sep 27, 2010 05:51:56 GMT+00:00 > Subject: Re: signed/unsigned comparison warning level > >> The standards did not leave this open. They define precisely what is >> supposed to happen. >> > Really? I'll have to drop this whole lobbying effort then. That > makes me sad that they didn't define it to be comparing of the numbers > where there are overlaps in signed and unsigned instead of causing all > negative signed values to be wrong. > >> >>> But if it's not fixed, this warning should definatly be issued at >>> default warning level. This should be more like 'if this comparison >>> can be wrong, it will be wrong'. >> >> There is no problem comparing values of signed type with values of >> unsigned type if the signed values are known to be nonnegative. Of >> course it is sometimes hard to know that; hence the warning. But >> enabling the warning by default does not make sense. >> > > It's exactly the fact that 'of course it is sometimes' that makes > the warning make more sense to be on by default. I don't always know > that I've added an unsigned value to an expression, causing one side > of a comparison to become unsigned, resulting in 100% failure on > negative signed result comparison. > > >> Ian >> >
Differences in GCC and ICC compiled objects, GCC relocations broken?
Posted in the Intel forums but this may be more of a GCC issue. Please advise if I should post elsewhere. Compiling a C module in with a large app (>2GB data) and getting relocatable errors with GCC and not ICC. ./classification_dpr_BB.o: In function `BB_detection_dpr': /homedata/johnk/dpr/src_ 20120126/DD2_V2.20120126/src/./ classification_dpr_BB.c:118: relocation truncated to fit: R_X86_64_PC32 against `.bss' Can anyone familiar with the output of readelf see why the GCC object is not relocatable and the ICC one is? Would another tool be more suitable? icc -I../include -g -v -sox -fPIC -mcmodel=medium -DDEBUG -c ./classification_dpr_BB.c cc -I../include -g -v -fPIC -mcmodel=medium -DDEBUG -c ./classification_dpr_BB.c This module does not use more than 2GB data itself, I just need it to be linked with code that does, so -fPIC. I left off the medium memory model switch on both with no impact. Everything is static except for the -shared-intel -mcmodel=medium on the main link (ifort is used). Could it have something to do with the relocation types? Are there switches to GCC to force relocations like ICC? GCC Relocation section '.rela.text' at offset 0xd040 contains 449 entries: Offset Info Type Sym. Value Sym. Name + Addend 004e 00170002 R_X86_64_PC32 .rodata + fffc 008e 00040002 R_X86_64_PC32 .bss + 1e5c 00bc 00040002 R_X86_64_PC32 .bss + 105c ICC Relocation section '.rela.text' at offset 0xf222 contains 732 entries: Offset Info Type Sym. Value Sym. Name + Addend 0030 0078001a R_X86_64_GOTPC32 _GLOBAL_OFFSET_TABLE_ + fffc 0036 00060019 R_X86_64_GOTOFF64 _2il0floatpacket.15 + 0 0057 00070019 R_X86_64_GOTOFF64 0008 _2il0floatpacket.16 + 0 009f 0078001a R_X86_64_GOTPC32 _GLOBAL_OFFSET_TABLE_ + fffc gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51) icc (ICC) 11.1 20100806 The full output of readelf -all are at these links. ICC http://www.box.com/s/2iqnqydmi0mdz52xs9ac GCC http://www.box.com/s/jjcgq1x2s5ybpg7s9b6g Thanks for any help.
Fwd: Differences in GCC and ICC compiled objects, GCC relocations broken?
Yes, I replicated this on an Ubuntu 11 distro with GCC 4.6.x On Thu, Feb 23, 2012 at 5:34 PM, Iyer, Balaji V wrote: > Hello J. K., > Have you tried with a newer version of GCC? GCC 4.1 is pretty old > > Thanks, > > Balaji V. Iyer. > > -Original Message- > From: J K [mailto:jkwi...@gmail.com] > Sent: Thursday, February 23, 2012 10:31 AM > To: gcc@gcc.gnu.org > Subject: Differences in GCC and ICC compiled objects, GCC relocations broken? > > Posted in the Intel forums but this may be more of a GCC issue. > Please advise if I should post elsewhere. > > Compiling a C module in with a large app (>2GB data) and getting relocatable > errors with GCC and not ICC. > > ./classification_dpr_BB.o: In function `BB_detection_dpr': > /homedata/johnk/dpr/src_ > 20120126/DD2_V2.20120126/src/./ > classification_dpr_BB.c:118: relocation truncated to fit: > R_X86_64_PC32 against `.bss' > > Can anyone familiar with the output of readelf see why the GCC > object is not relocatable and the ICC one is? Would another tool > be more suitable? > > icc -I../include -g -v -sox -fPIC -mcmodel=medium -DDEBUG -c > ./classification_dpr_BB.c cc -I../include -g -v -fPIC -mcmodel=medium -DDEBUG > -c ./classification_dpr_BB.c > > This module does not use more than 2GB data itself, I just need it to be > linked with > code that does, so -fPIC. I left off the medium memory model switch on > both with no impact. > Everything is static except for the -shared-intel -mcmodel=medium on the > main link (ifort is used). > > Could it have something to do with the relocation types? Are there switches > to GCC to force relocations > like ICC? > > GCC > Relocation section '.rela.text' at offset 0xd040 contains 449 entries: > Offset Info Type Sym. Value Sym. > Name + Addend > 004e 00170002 R_X86_64_PC32 .rodata > + fffc > 008e 00040002 R_X86_64_PC32 .bss + 1e5c > 00bc 00040002 R_X86_64_PC32 .bss + 105c > > > ICC > Relocation section '.rela.text' at offset 0xf222 contains 732 entries: > Offset Info Type Sym. Value Sym. > Name + Addend > 0030 0078001a R_X86_64_GOTPC32 > _GLOBAL_OFFSET_TABLE_ + fffc > 0036 00060019 R_X86_64_GOTOFF64 > _2il0floatpacket.15 + 0 > 0057 00070019 R_X86_64_GOTOFF64 0008 > _2il0floatpacket.16 + 0 > 009f 0078001a R_X86_64_GOTPC32 > _GLOBAL_OFFSET_TABLE_ + fffc > > gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51) icc (ICC) 11.1 20100806 > > The full output of readelf -all are at these links. > > ICC > http://www.box.com/s/2iqnqydmi0mdz52xs9ac > > GCC > http://www.box.com/s/jjcgq1x2s5ybpg7s9b6g > > Thanks for any help.
DRIVER
I NEED A DRIVER FOR MY WIFE
RE: internal compiler error: Segmentation fault
> > This looks fine. What is the call stack looks like? And how does the > function calling ntdll looks like? > I think, you should step on an "int 3". Because you simply debug the > exception handling routine itself. > Hi, Kai: I attach the stack in the following: C:\temp\fortran>cdb gfortran -O1 c.f90 Microsoft (R) Windows Debugger Version 6.8.0004.0 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: gfortran -O1 c.f90 Symbol search path is: *** Invalid *** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * Executable search path is: ModLoad: `0040 `0043c000 image`0040 ModLoad: `77ec `77ff9000 ntdll.dll ModLoad: `77d4 `77eb3000 C:\WINDOWS\system32\kernel32.dll ModLoad: 07ff`7fc0 07ff`7fc86000 C:\WINDOWS\system32\msvcrt.dll ModLoad: `77c2 `77d2c000 C:\WINDOWS\system32\USER32.dll ModLoad: 07ff`7fc9 07ff`7fd2c000 C:\WINDOWS\system32\GDI32.dll (a20.a24): Break instruction exception - code 8003 (first chance) *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - ntdll!DbgBreakPoint: `77ef2aa0 cc int 3 0:000> g ModLoad: 07ff`7d50 07ff`7d539000 C:\WINDOWS\system32\IMM32.DLL ModLoad: 07ff`7fee 07ff`7ffe5000 C:\WINDOWS\system32\ADVAPI32.dll ModLoad: 07ff`7fd3 07ff`7fec9000 C:\WINDOWS\system32\RPCRT4.dll ModLoad: 07ff`7e9c 07ff`7e9e2000 C:\WINDOWS\system32\Secur32.dll ModLoad: 07ff`6930 07ff`6930d000 C:\WINDOWS\system32\LPK.DLL ModLoad: 07ff`78e8 07ff`78f0e000 C:\WINDOWS\system32\USP10.dll c.f90: In function 'MAIN__': c.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ntdll!ZwTerminateProcess+0xa: `77ef0caa c3 ret 0:000> kb *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll - RetAddr : Args to Child : Call Site `77d5a329 : `0001 `0001 `0001 ` : ntdll!ZwTerminateProcess+0xa *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\msvcrt.dll - 07ff`7fc4069b : ` `00428030 ` `4060 : kernel32!ExitProcess+0x59 07ff`7fc40863 : ` ` ` ` : msvcrt!strerror+0x3beb *** ERROR: Module load completed but symbols could not be loaded for image`0040 `0040141d : `0003 `003d3590 ` `00419a10 : msvcrt!initterm+0x193 `0003 : `003d3590 ` `00419a10 ` : image_0040+0x141d `003d3590 : ` `00419a10 ` ` : 0x3 ` : `00419a10 ` ` ` : 0x3d3590 `00419a10 : ` ` ` ` : 0x0 ` : ` ` ` ` : image_0040+0x19a10 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 0:000> _ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_
RE: internal compiler error: Segmentation fault
Hi, stack before and after segmentation fault is as: .. .. ntdll!KiUserApcDispatcher+0x15: `77ef30a5 488bcc mov rcx,rsp 0:000> p ntdll!KiUserApcDispatcher+0x18: `77ef30a8 b201mov dl,1 0:000> k Child-SP RetAddr Call Site `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x18 `0022ffa8 ` kernel32!BaseProcessStart 0:000> p ntdll!KiUserApcDispatcher+0x1a: `77ef30aa e861dd callntdll!NtContinue (`77ef0e10) 0:000> k Child-SP RetAddr Call Site `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x1a `0022ffa8 ` kernel32!BaseProcessStart 0:000> p c.f90: In function 'MAIN__': c.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ntdll!ZwTerminateProcess+0xa: `77ef0caa c3 ret 0:000> k Child-SP RetAddr Call Site `0022fd08 `77d5a329 ntdll!ZwTerminateProcess+0xa *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\msvcrt.dll - `0022fd10 07ff`7fc4069b kernel32!ExitProcess+0x59 `0022fe60 07ff`7fc40863 msvcrt!strerror+0x3beb *** ERROR: Module load completed but symbols could not be loaded for image`0040 `0022fe90 `0040141d msvcrt!initterm+0x193 `0022fed0 `0003 image_0040+0x141d `0022fed8 `003d3590 0x3 `0022fee0 ` 0x3d3590 `0022fee8 `00419a10 0x0 `0022fef0 ` image_0040+0x19a10 `0022fef8 ` 0x0 `0022ff00 ` 0x0 `0022ff08 ` 0x0 `0022ff10 ` 0x0 `0022ff18 ` 0x0 `0022ff20 ` 0x0 `0022ff28 ` 0x0 `0022ff30 ` 0x0 `0022ff38 ` 0x0 `0022ff40 ` 0x0 `0022ff48 ` 0x0 0:000> _ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008
RE: internal compiler error: Segmentation fault
Hi, Kai,
This is what you want, with -dH. If you need further information, please let me
know. Finch.
.
.
(8b8.8bc): Break instruction exception - code 8003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntdll.dll -
ntdll!DbgBreakPoint:
`77ef2aa0 cc int 3
0:000> p
ntdll!DbgBreakPoint+0x1:
`77ef2aa1 c3 ret
0:000> p
ntdll!LdrInitShimEngineDynamic+0xcbc:
`77f1bbcc 8b95bc00mov edx,dword ptr [rbp+0BCh]
ss:07ff`fffde0bc=0070
0:000> p
ntdll!LdrInitShimEngineDynamic+0xcc2:
`77f1bbd2 d1eashr edx,1
0:000> p
ntdll!LdrInitShimEngineDynamic+0xcc4:
`77f1bbd4 80e201 and dl,1
0:000> p
ntdll!LdrInitShimEngineDynamic+0xcc7:
`77f1bbd7 8815bdb30800mov byte ptr
[ntdll!NlsMbOemCodePageTag+0x882 (`77fa6f9a)],dl ds:`77fa6f9a=00
0:000> p
ntdll!LdrInitShimEngineDynamic+0xccd:
`77f1bbdd e9939bfbff jmp ntdll!CsrCaptureMessageBuffer+0x3b5
(`77ed5775)
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3b5:
`77ed5775 488bb4241001 mov rsi,qword ptr [rsp+110h]
ss:`0022f7e0=
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3bd:
`77ed577d 4885f6 testrsi,rsi
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3c0:
`77ed5780 0f855c640400jne ntdll!LdrInitShimEngineDynamic+0xcd2
(`77f1bbe2) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3c6:
`77ed5786 498bcd mov rcx,r13
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3c9:
`77ed5789 e852e2 callntdll!CsrClientConnectToServer+0x2f0
(`77ed39e0)
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3ce:
`77ed578e 4533e4 xor r12d,r12d
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3d1:
`77ed5791 498bcf mov rcx,r15
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3d4:
`77ed5794 e8d78f callntdll!RtlDeregisterWait+0x640
(`77ede770)
0:000> p
ModLoad: 07ff`7d50 07ff`7d539000 C:\WINDOWS\system32\IMM32.DLL
ModLoad: 07ff`7fee 07ff`7ffe5000 C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 07ff`7fd3 07ff`7fec9000 C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 07ff`7e9c 07ff`7e9e2000 C:\WINDOWS\system32\Secur32.dll
ModLoad: 07ff`6930 07ff`6930d000 C:\WINDOWS\system32\LPK.DLL
ModLoad: 07ff`78e8 07ff`78f0e000 C:\WINDOWS\system32\USP10.dll
ntdll!CsrCaptureMessageBuffer+0x3d9:
`77ed5799 85c0testeax,eax
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3db:
`77ed579b 8bd8mov ebx,eax
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3dd:
`77ed579d 0f8861640400js ntdll!LdrInitShimEngineDynamic+0xcf4
(`77f1bc04) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3e3:
`77ed57a3 833d86ea0c cmp dword ptr [ntdll!pow+0x2230
(`77fa4230)],0 ds:`77fa4230=
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3ea:
`77ed57aa 0f858e640400jne ntdll!LdrInitShimEngineDynamic+0xd2e
(`77f1bc3e) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3f0:
`77ed57b0 488b853002 mov rax,qword ptr [rbp+230h]
ss:07ff`fffde230=
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3f7:
`77ed57b7 4885c0 testrax,rax
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3fa:
`77ed57ba 0f85c7640400jne ntdll!LdrInitShimEngineDynamic+0xd77
(`77f1bc87) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x400:
`77ed57c0 4d85ed testr13,r13
0:000> p
ntdll!CsrCaptureMessageBuffer+0x403:
`77ed57c3 0f85c6640400jne ntdll!LdrInitShimEngineDynamic+0xd7f
(`77f1bc8f) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x409:
`77ed57c9 33c0xor eax,eax
0:000> p
ntdll!CsrCaptureMessageBuffer+0x40b:
`77ed57cb e92ee6 jmp ntdll!RtlSetThreadPoolStartFunc+0x10e
(`77ed3dfe)
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x10e:
`77ed3dfe 660f6fb424b002 movdqa xmm6,xmmword ptr [rsp+2B0h]
ss:`0022f980=
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x117:
`77ed3e07 eb4ajmp
ntdll!RtlSetThreadPoolStartFunc+0x163(`77ed3e53)
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x163:
`77ed3e53 488bb424f002 mov rsi,qword ptr [rsp+2F0h]
ss:`0022f9c0=
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x16b:
`77ed3e5b eb2ajmp
ntdll!RtlSetThreadPoolStartFunc+0x197(`77ed3e87)
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x197:
`77ed3e87 4c8bbc24c802 mov r15,qword ptr [rsp+2C8h]
ss:`0022f998={ntdll (`77ec)}
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x19f:
`77ed3e8f 4c8bb424d002 mov r14,qword ptr [rsp+2D0h]
s
The Linux binutils 2.17.50.0.6 is released
This is the beta release of binutils 2.17.50.0.6 for Linux, which is
based on binutils 2006 1020 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.6 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.17.50.0.6 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
If you don't use
# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2
to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.
Changes from binutils 2.17.50.0.5:
1. Update from binutils 2006 1020.
2. Don't make debug symbol dynamic. PR 3290.
3. Don't page align empty SHF_ALLOC sections, which leads to very large
executables. PR 3314.
4. Use a different section index for section relative symbols against
removed empty sections.
5. Fix a few ELF EH frame handling bugs.
6. Don't ignore relocation overflow on branches to undefweaks for
x86-64. PR 3283.
7. Rename MNI to SSSE3.
8. Properly append symbol list for --dynamic-list.
lists.
9. Various ARM ELF fixes.
10. Correct 64bit library search path for Linux/x86 linker with 64bit
support.
11. Fix ELF linker to copy OS/PROC specific flags from input section to
output section.
12. Fix DW_FORM_ref_addr handling in linker dwarf reader. PR 3191.
13. Fix ELF indirect symbol handling. PR 3351.
14. Fix PT_GNU_RELRO segment handling for SHF_TLS sections. Don't add
PT_GNU_RELRO segment when there are no relro sections. PR 3281.
15. Various MIPS ELF fixes.
16. Various Sparc ELF fixes.
17. Various Xtensa ELF fixes.
Changes from binutils 2.17.50.0.4:
1. Update from binutils 2006 0927.
2. Fix linker regressions of section address and section relative symbol
with empty output section. PR 3223/3267.
3. Fix "strings -T". PR 3257.
4. Fix "objcopy --only-keep-debug". PR 3262.
5. Add Intell iwmmxt2 support.
6. Fix an x86 disassembler bug. PR 3100.
Changes from binutils 2.17.50.0.3:
1. Update from binutils 2006 0924.
2. Speed up linker on .o files with debug info on linkonce sections.
PR 3111.
3. Added x86-64 PE support.
4. Fix objcopy/strip on .o files with section groups. PR 3181.
5. Fix "ld --hash-style=gnu" crash with gcc 3.4.6. PR 3197.
6. Fix "strip --strip-debug" on .o files generated with
"gcc -feliminate-dwarf2-dups". PR 3186.
7. Fix "ld -r" on .o files generated with "gcc -feliminate-dwarf2-dups".
PR 3249.
8. Add --dynamic-list to linker to make global symbols dynamic.
9. Fix magic number for EFI ia64. PR 3171.
10. Remove PT_NULL segment for "ld -z relro". PR 3015.
11. Make objcopy to perserve the file formats in archive elements.
PR 3110.
12. Optimize x86-64 assembler and fix disassembler for
"add32 mov xx,$eax". PR 3235.
13. Improve linker diagnostics. PR 3107.
14. Fix "ld --sort-section name". PR 3009.
15. Updated an x86 disassembler bug. PR 3000.
16. Various updates for PPC
A public discussion group for IA32 psABI
On Tue, Oct 10, 2006 at 11:21:41AM -0500, Menezes, Evandro wrote: > > H.J., do you have the i386 psABI in source form somewhere I could get > > it, to make the corresponding changes? > > Actually, it's about an extension to the i386 psABI and it's an idea still in > its infancy: http://sourceware.org/ml/binutils/2006-09/msg00342.html. > Some people told that FSG might not be the best place to start the public IA32 psABI discussion group. I created one at http://groups-beta.google.com/group/ia32-abi We can reconsider if it should be moved to FSG later. Alexandre, could you please upload your IA32 psABI extension proposal to it? Thanks. H.J.
Re: Bootstrap failure on trunk on linux? (libgmp.so.3 exists, but not found)
On Sat, Nov 04, 2006 at 04:58:42PM -0800, Brooks Moses wrote: > Daniel Jacobowitz wrote: > >On Sat, Nov 04, 2006 at 10:57:14AM -0800, Brooks Moses wrote: > >>I've been setting up a Debian box to do builds on, and make bootstrap on > >>mainline is failing somewhere in the middle of Stage 1. The problem > >>appears to be that it's not looking in the right places for libgmp.so.3 > >>when it calls ./gcc/xgcc at the end of the stage. > > > >It's doing exactly what it ought to, though unintuitive. If you tell a > >-compiler to use L/usr/local/lib, you're responsible for also setting > >up either an rpath or LD_LIBRARY_PATH to point at /usr/local/lib; doing > >it by default causes all kinds of problems. > > Ah, okay. Thanks for the quick reply! > > I guess I was assuming that since GMP is supposedly only a prerequisite > for building the compiler and not for using it, that it was being linked > in statically rather than dynamically. But I guess that wouldn't apply > to xgcc, since it's only used in the build (right?). > I have been using this patch to make sure that GMPLIBS is linked statically so that I can install gcc binaries on machines without updated GMPLIBS. H.J. --- gcc/Makefile.in.gmp 2006-05-19 06:23:09.0 -0700 +++ gcc/Makefile.in 2006-05-19 13:20:17.0 -0700 @@ -295,7 +295,7 @@ ZLIB = @zlibdir@ -lz ZLIBINC = @zlibinc@ # How to find GMP -GMPLIBS = @GMPLIBS@ +GMPLIBS = -Wl,-Bstatic @GMPLIBS@ -Wl,-Bdynamic GMPINC = @GMPINC@ CPPLIB = ../libcpp/libcpp.a
PATCH: wwwdocs: Update Intel64 and IA32 SDM website
Intel has published Core 2 Duo Optimization Reference Manual. I will check in this patch to update wwwdocs. H.J. 2006-11-10 H.J. Lu <[EMAIL PROTECTED]> * readings.html: Update Intel64 and IA32 SDM website. Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.160 diff -u -p -r1.160 readings.html --- readings.html 23 Oct 2006 16:17:21 - 1.160 +++ readings.html 10 Nov 2006 17:32:21 - @@ -133,8 +133,8 @@ names. i386 (i486, i586, i686, i786) Manufacturer: Intel - http://developer.intel.com/design/pentium4/manuals/index_new.htm";> - IA-32 Intel Architecture Software Developer's Manuals + http://developer.intel.com/products/processor/manuals/index.htm";> +Intel®64 and IA-32 Architectures Software Developer's Manuals Some information about optimizing for x86 processors, links to x86 manuals and documentation:
Core 2 Duo Optimization Reference Manual is available
On Fri, Nov 10, 2006 at 09:36:59AM -0800, H. J. Lu wrote: > Intel has published Core 2 Duo Optimization Reference Manual. I will > check in this patch to update wwwdocs. > I checked it in. You can find Core 2 Duo Optimization Reference Manual at http://developer.intel.com/products/processor/manuals/index.htm H.J.
Re: Threading the compiler
On Fri, Nov 10, 2006 at 12:38:07PM -0800, Mike Stump wrote: > How many hunks do we need, well, today I want 8 for 4.2 and 16 for > mainline, each release, just 2x more. I'm assuming nice, equal sized > hunks. For larger variations in hunk size, I'd need even more hunks. > > Or, so that is just an off the cuff proposal to get the discussion > started. > > Thoughts? Will use C++ help or hurt compiler parallelism? Does it really matter? H.J.
Re: bootstrap failure on HEAD
On Sun, Nov 12, 2006 at 02:44:36PM -, Dave Korn wrote: > > I see this on linux but not on cygwin: > > make[3]: Leaving directory `/home/dk/gnu/obj' > Comparing stages 2 and 3 > warning: ./cc1-checksum.o differs > warning: ./cc1plus-checksum.o differs > warning: ./cc1obj-checksum.o differs > Bootstrap comparison failure! > ./cfg.o differs > ./cfgloopanal.o differs > ./loop-iv.o differs > ./predict.o differs > ./profile.o differs > ./value-prof.o differs > ./ipa-inline.o differs > make[2]: *** [compare] Error 1 > make[2]: Leaving directory `/home/dk/gnu/obj' > make[1]: *** [stage3-bubble] Error 2 > make[1]: Leaving directory `/home/dk/gnu/obj' > make: *** [all] Error 2 > [EMAIL PROTECTED] obj]$ ../gcc/config.guess > i686-pc-linux-gnu > [EMAIL PROTECTED] obj]$ uname -a > Linux pepper.cam.artimi.com 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 > i386 GNU/Linux > [EMAIL PROTECTED] obj]$ Gcc mainline may miscompile gcc when -O2 is used. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680 I have no problems on x86, x86-64 and ia64 with revision 118723 today after reverting revision 117986. Can you try http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574 H.J.
Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
Gcc 4.3 revision 118764 failed galgel in SPEC CPU 2000 with -O2 -ffast-math on Linux/x86-64. I got galgel_base.o2[30363]: segfault at 000b rip 000b rsp 007fb008 error 14 Gcc 4.3 revision 118723 passes SPEC CPU 2006 with -O2 -ffast-math on Linux/x86-64. But it fails wrf in SPEC CPU 2006 with -O2 on Linux/x86. The odd thing is the test input works fine and the ref input causes segfaults at the very end of the several hour run. Has anyone else seen it? H.J.
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote: > > Steve Kargl writes: > > Steve> I have not seen this failure, but that may be expected > Steve> since SPEC CPU 2000 isn't freely available. > > No failure should be expected. It is a bug and a regression and > should be fixed, with help of users who have access to SPEC CPU2000. > It was a pilot error for SPEC CPU2000 on Linux/x86-64. I am looking into SPEC CPU 2006 failure on Linux/x86. H.J.
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote: > On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote: > > >>>>> Steve Kargl writes: > > > > Steve> I have not seen this failure, but that may be expected > > Steve> since SPEC CPU 2000 isn't freely available. > > > > No failure should be expected. It is a bug and a regression and > > should be fixed, with help of users who have access to SPEC CPU2000. > > > > It was a pilot error for SPEC CPU2000 on Linux/x86-64. I am looking > into SPEC CPU 2006 failure on Linux/x86. > revision 118764 seems with SPEC CPU 2K/2006 on both Linux/x86-64 and Linux/x86. H.J.
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote: > H. J. Lu wrote: > >On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote: > >>On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote: > >>> No failure should be expected. It is a bug and a regression and > >>>should be fixed, with help of users who have access to SPEC CPU2000. > >>> > >>It was a pilot error for SPEC CPU2000 on Linux/x86-64. I am looking > >>into SPEC CPU 2006 failure on Linux/x86. > > > >revision 118764 seems with SPEC CPU 2K/2006 on both Linux/x86-64 and > >Linux/x86. > > Was there an "okay" missing from that sentence, or is there still a problem? > Ooops, revision 118764 seems OK. I am verifying it now. H.J.
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
On Tue, Nov 14, 2006 at 12:03:39PM -0800, H. J. Lu wrote: > On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote: > > H. J. Lu wrote: > > >On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote: > > >>On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote: > > >>> No failure should be expected. It is a bug and a regression and > > >>>should be fixed, with help of users who have access to SPEC CPU2000. > > >>> > > >>It was a pilot error for SPEC CPU2000 on Linux/x86-64. I am looking > > >>into SPEC CPU 2006 failure on Linux/x86. > > > > > >revision 118764 seems with SPEC CPU 2K/2006 on both Linux/x86-64 and > > >Linux/x86. > > > > Was there an "okay" missing from that sentence, or is there still a problem? > > > > Ooops, revision 118764 seems OK. I am verifying it now. I was wrong. revision 118764 with -O2 still leads to segfault in wrf in SPEC CPU 2006 on Linux/x86. revision 118353 is OK. Linux/x86-64 is OK. I am looking into it now. H.J.
The Linux binutils 2.17.50.0.7 is released
This is the beta release of binutils 2.17.50.0.7 for Linux, which is
based on binutils 2006 1020 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.7 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.17.50.0.7 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
If you don't use
# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2
to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.
Changes from binutils 2.17.50.0.6:
1. Update from binutils 2006 1127.
2. Properly set ELF output segment address when the first section in
input segment is removed.
3. Better merging of CIEs in linker .eh_frame optimizations.
4. Support .cfi_personality and .cfi_lsda assembler directives.
5. Fix an ARM linker crash. PR 3532.
6. Fix various PPC64 ELF bugs.
7. Mark discarded debug info more thoroughly in linker output.
8. Fix various MIPS ELF bugs.
9. Fix readelf to display program interpreter path > 64 chars. PR 3384.
10. Add support for PowerPC SPU.
11. Properly handle cloned symbols used in relocations in assembler. PR
3469.
12. Update opcode for POPCNT in amdfam10 architecture.
Changes from binutils 2.17.50.0.5:
1. Update from binutils 2006 1020.
2. Don't make debug symbol dynamic. PR 3290.
3. Don't page align empty SHF_ALLOC sections, which leads to very large
executables. PR 3314.
4. Use a different section index for section relative symbols against
removed empty sections.
5. Fix a few ELF EH frame handling bugs.
6. Don't ignore relocation overflow on branches to undefweaks for
x86-64. PR 3283.
7. Rename MNI to SSSE3.
8. Properly append symbol list for --dynamic-list.
lists.
9. Various ARM ELF fixes.
10. Correct 64bit library search path for Linux/x86 linker with 64bit
support.
11. Fix ELF linker to copy OS/PROC specific flags from input section to
output section.
12. Fix DW_FORM_ref_addr handling in linker dwarf reader. PR 3191.
13. Fix ELF indirect symbol handling. PR 3351.
14. Fix PT_GNU_RELRO segment handling for SHF_TLS sections. Don't add
PT_GNU_RELRO segment when there are no relro sections. PR 3281.
15. Various MIPS ELF fixes.
16. Various Sparc ELF fixes.
17. Various Xtensa ELF fixes.
Changes from binutils 2.17.50.0.4:
1. Update from binutils 2006 0927.
2. Fix linker regressions of section address and section relative symbol
with empty output section. PR 3223/3267.
3. Fix "strings -T". PR 3257.
4. Fix "objcopy --only-keep-debug". PR 3262.
5. Add Intell iwmmxt2 support.
6. Fix an x86 disassembler bug. PR 3100.
Changes from binutils 2.17.50.0.3:
1. Update from binutils 2006 0924.
2. Speed up linker on .o files with debug info on linkonce sections.
PR 3111.
3. Added x86-64 PE support.
4. Fix objcopy/strip on .o files with section groups. PR 3181.
5. Fix "ld --hash-style=gnu" c
Re: -m{arch,tune}=native and Core Duo
On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> Currently, the way the native CPU detection code in driver-i386.c
> is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
> the correct setting for this chip? There seems to be a lot of confusion
> across the net as to whether a Core Duo (aka Yonah, aka Centrino Duo)
> should be using -march=prescott or -march=pentium-m. Some argue
> that because Core chips share a lot more in common with with the P6
> microarchitecture than with Netburst, -march=pentium-m should be the
> correct choice. Others (myself included) point out that just because
> the design is based on the Pentium M doesn't make it a Pentium M. One
> major argument supporting -march=prescott is that using
> -march=pentium-m will greatly prefer using x87 over SSE scalar code,
> since the Pentium M sucked at SSE (~30% slower than x87 according to
> Intel's Optimization Manual). Since then, things like improved
> decoding and micro-op fusion have made SSE a definite win on Netburst
> and Core CPUs. Some have come to the conclusion that
> -march=pentium-m -mfpmath=sse -msse3 is the best solution.
>
> So anyways, should -m{arch,tune}=native be setting pentium-m for Core
> CPU's, or is prescott really the better choice in the end?
It should be -march=prescott -mtune=generic. I will look into it.
H.J.
Re: -m{arch,tune}=native and Core Duo
On Fri, Dec 01, 2006 at 06:43:46AM -0800, H. J. Lu wrote:
> On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> > Currently, the way the native CPU detection code in driver-i386.c
> > is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> > Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
> > the correct setting for this chip? There seems to be a lot of confusion
> > across the net as to whether a Core Duo (aka Yonah, aka Centrino Duo)
> > should be using -march=prescott or -march=pentium-m. Some argue
> > that because Core chips share a lot more in common with with the P6
> > microarchitecture than with Netburst, -march=pentium-m should be the
> > correct choice. Others (myself included) point out that just because
> > the design is based on the Pentium M doesn't make it a Pentium M. One
> > major argument supporting -march=prescott is that using
> > -march=pentium-m will greatly prefer using x87 over SSE scalar code,
> > since the Pentium M sucked at SSE (~30% slower than x87 according to
> > Intel's Optimization Manual). Since then, things like improved
> > decoding and micro-op fusion have made SSE a definite win on Netburst
> > and Core CPUs. Some have come to the conclusion that
> > -march=pentium-m -mfpmath=sse -msse3 is the best solution.
> >
> > So anyways, should -m{arch,tune}=native be setting pentium-m for Core
> > CPU's, or is prescott really the better choice in the end?
>
> It should be -march=prescott -mtune=generic. I will look into it.
I opened
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30040
H.J.
IA64 psABI discussion group created
FYI, I created an IA64 psABI discussion group: http://groups-beta.google.com/group/ia64-abi H.J.
The Linux binutils 2.17.50.0.8 is released
This is the beta release of binutils 2.17.50.0.8 for Linux, which is
based on binutils 2006 1201 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.8 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.17.50.0.8 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
If you don't use
# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2
to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.
Changes from binutils 2.17.50.0.7:
1. Update from binutils 2006 1201.
2. Fix "objcopy --only-keep-debug" crash. PR 3609.
3. Fix various ARM ELF bugs.
4. Fix various xtensa bugs.
5. Update x86 disassembler.
Changes from binutils 2.17.50.0.6:
1. Update from binutils 2006 1127.
2. Properly set ELF output segment address when the first section in
input segment is removed.
3. Better merging of CIEs in linker .eh_frame optimizations.
4. Support .cfi_personality and .cfi_lsda assembler directives.
5. Fix an ARM linker crash. PR 3532.
6. Fix various PPC64 ELF bugs.
7. Mark discarded debug info more thoroughly in linker output.
8. Fix various MIPS ELF bugs.
9. Fix readelf to display program interpreter path > 64 chars. PR 3384.
10. Add support for PowerPC SPU.
11. Properly handle cloned symbols used in relocations in assembler. PR
3469.
12. Update opcode for POPCNT in amdfam10 architecture.
Changes from binutils 2.17.50.0.5:
1. Update from binutils 2006 1020.
2. Don't make debug symbol dynamic. PR 3290.
3. Don't page align empty SHF_ALLOC sections, which leads to very large
executables. PR 3314.
4. Use a different section index for section relative symbols against
removed empty sections.
5. Fix a few ELF EH frame handling bugs.
6. Don't ignore relocation overflow on branches to undefweaks for
x86-64. PR 3283.
7. Rename MNI to SSSE3.
8. Properly append symbol list for --dynamic-list.
lists.
9. Various ARM ELF fixes.
10. Correct 64bit library search path for Linux/x86 linker with 64bit
support.
11. Fix ELF linker to copy OS/PROC specific flags from input section to
output section.
12. Fix DW_FORM_ref_addr handling in linker dwarf reader. PR 3191.
13. Fix ELF indirect symbol handling. PR 3351.
14. Fix PT_GNU_RELRO segment handling for SHF_TLS sections. Don't add
PT_GNU_RELRO segment when there are no relro sections. PR 3281.
15. Various MIPS ELF fixes.
16. Various Sparc ELF fixes.
17. Various Xtensa ELF fixes.
Changes from binutils 2.17.50.0.4:
1. Update from binutils 2006 0927.
2. Fix linker regressions of section address and section relative symbol
with empty output section. PR 3223/3267.
3. Fix "strings -T". PR 3257.
4. Fix "objcopy --only-keep-debug". PR 3262.
5. Add Intell iwmmxt2 support.
6. Fix an x86 disassembler bug. PR 3100.
Changes from binutils 2.17.50.0.3:
1. Update from binutils 200
Re: mainline slowdown
On Fri, Dec 01, 2006 at 03:37:22PM -0500, Andrew MacLeod wrote: > On Fri, 2006-12-01 at 14:59 -0500, Daniel Berlin wrote: > > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote: > > > > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > > > > My bootstrap/make check cycle took about 10 hours with yesterdays > > > > > checkout (way longer than expected). A quick investigation shows C++ > > > > > compilation timed are through the roof. > > > > > > > > 10 hours? > > > > > > read carefully. "bootstrap/make check" > > > > Yes, so, i've never seen a bootstrap make check take 10 hours. > > :) > > me either!! Hence the question if anyone else was seeing it. Diego says > PPC runs are faster than they use to be. Anyone with x86 seeing > slowdowns? Maybe my computer just hates me this week. These are what I have for Nov. on a dual-cpu P4 3.2GHz with HT: nohup.20061103:7129.07user 1279.83system 42:27.00elapsed 330%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061103:8203.19user 2691.67system 57:45.37elapsed 314%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061108:7082.96user 1306.05system 42:25.73elapsed 329%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061108:8796.31user 2801.81system 53:57.75elapsed 358%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061110:7315.57user 1292.64system 45:59.12elapsed 311%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061110:8326.86user 2727.21system 58:12.37elapsed 316%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061113:7158.86user 1288.96system 45:19.70elapsed 310%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061113:8161.41user 2746.78system 58:02.40elapsed 313%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061115:8554.33user 1277.61system 54:21.33elapsed 301%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061115:8592.50user 2801.66system 53:12.89elapsed 356%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061116:8553.23user 1286.27system 54:27.57elapsed 301%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061116:8816.32user 2784.34system 54:07.30elapsed 357%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061118:7201.91user 1278.13system 45:30.10elapsed 310%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061118:8615.97user 2816.65system 53:31.23elapsed 356%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061120:7251.84user 1297.72system 45:52.32elapsed 310%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061120:8240.75user 2786.54system 58:16.48elapsed 315%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061122:7108.80user 1319.07system 45:23.87elapsed 309%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061122:8135.23user 2772.20system 57:52.77elapsed 314%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061123:7118.26user 1295.97system 45:18.50elapsed 309%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061123:8555.19user 2828.30system 53:29.78elapsed 354%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061125:7075.41user 1278.07system 45:08.26elapsed 308%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061125:8192.55user 2751.37system 56:20.08elapsed 323%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061127:7177.19user 1295.59system 45:34.88elapsed 309%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061127:8173.81user 2752.39system 57:50.67elapsed 314%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061201:6880.76user 1284.99system 41:35.44elapsed 327%CPU (0avgtext+0avgdata 0maxresident)k nohup.20061201:7942.93user 2742.14system 57:23.53elapsed 310%CPU (0avgtext+0avgdata 0maxresident)k The first number is bootstrap and the second one is check. I used --enable-checking=assert. H.J.
Change x86 prefix order
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and LOCKREP_PREFIX isn't fixed. Currently, gas generates LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX I will check in a patch: http://sourceware.org/ml/binutils/2006-12/msg00054.html tomorrow and change gas to generate SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX H.J.
Re: Change x86 prefix order
On Wed, Dec 06, 2006 at 08:43:17AM -0800, Randy Dunlap wrote: > On Tue, 5 Dec 2006 23:00:14 -0800 H. J. Lu wrote: > > > On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and > > LOCKREP_PREFIX isn't fixed. Currently, gas generates > > > > LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX > > > > I will check in a patch: > > > > http://sourceware.org/ml/binutils/2006-12/msg00054.html > > > > tomorrow and change gas to generate > > > > SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX > > Hi, > Could you provide a "why" for this in addition to the > "what", please? LOCKREP_PREFIX is also used as SIMD prefix. DATA_PREFIX can be used as either SIMD prefix or data size prefix for SIMD instructions. The new order SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX will make SIMD prefixes close to SIMD opcode. H.J.
Re: Change x86 prefix order
On Wed, Dec 06, 2006 at 06:52:39PM +0100, Mikael Pettersson wrote: > > If hardware x86 decoders (i.e., Intel or AMD processors) > get measurably faster with the new order, that would be > a good reason to change it. I was told that AMD processors had no preferences and Intel processors preferred the proposed order. H.J.
Serious SPEC CPU 2006 FP performance regressions on IA32
Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance regressions on P4, Pentium M and Core Duo, comparing aganst gcc 4.2 20060910. With -O2, the typical regressions look like Gcc 4.2 Gcc 4.3 410.bwaves 9.899.14-7.58342% 416.gamess 7.177.16-0.13947% 433.milc 7.687.65-0.390625% 434.zeusmp 5.575.55-0.359066% 435.gromacs 3.994.020.75188% 436.cactusADM4.594.50-1.96078% 437.leslie3d 5.783.98-31.1419% 444.namd 6.256.18-1.12% 447.dealII 11.311.30% 450.soplex 8.618.59-0.232288% 453.povray 6.706.720.298507% 454.calculix 2.812.74-2.4911% 459.GemsFDTD 6.074.95-18.4514% 465.tonto4.444.450.225225% 470.lbm 10.610.70.943396% 481.wrf 4.564.50-1.31579% 482.sphinx3 11.211.1-0.892857% Est. SPECfp_base2006 6.426.15-4.20561% Evandro, what do you get on AMD? Is that related to recent i386 backend FP changes? H.J.
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
On Fri, Dec 08, 2006 at 07:39:45PM +0100, Uros Bizjak wrote: > H. J. Lu wrote: > > >Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance > >regressions on P4, Pentium M and Core Duo, comparing aganst > >gcc 4.2 20060910. With -O2, the typical regressions look like > > > > > > > I think that you are looking at the same problem as > http://gcc.gnu.org/ml/gcc/2006-12/msg00017.html. > I am not sure. I don't have SPEC CPU 2000 FP performance regressions on x86-64 with -O2 -ffast-math. Again, my regressions are at -O2. H.J.
Re: "Fix alias slowdown" patch miscompiles 464.h264ref in SPEC CPU
On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote:
> Hey, by chance does the attached fix it?
>
Yes, it fixes 464.h264ref with the test input. I am running the real
input now.
Thanks.
H.J.
---
>
> On 12/10/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> >On 12/10/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >> 2006
> >> Reply-To:
> >>
> >> Hi Daniel,
> >>
> >> Do you have access to SPEC CPU 2006?
> >
> >No, i don't, only SPEC CPU 2000.
> >
> >> Your patch
> >>
> >> http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00225.html
> >>
> >> causes gcc 4.3 to miscompile 464.h264ref in SPEC CPU 2006 with
> >> -O2 -ffast-math on Linux/x86-64. 464.h264ref compiled with gcc 4.3
> >> generates incorrect output. We are working on a small testcase.
> >
> >There was a typo fix to this patch in a later revision that was
> >necessary for correctness. I have no idea what rev "gcc 4.3" refers
> >to, so i can't tell you if what you are testing is new enough or not
> >:)
> >
> >If you can get me a testcase, i can fix it.
> >
> --- gcc/tree-ssa-structalias.c(/mirror/gcc-trunk) (revision 639)
> +++ gcc/tree-ssa-structalias.c(/local/gcc-clean) (revision 639)
> @@ -2885,6 +2885,8 @@ handle_ptr_arith (VEC (ce_s, heap) *lhsc
> {
>rhsoffset = TREE_INT_CST_LOW (op1) * BITS_PER_UNIT;
> }
> + else
> +return false;
>
>
>for (i = 0; VEC_iterate (ce_s, lhsc, i, c); i++)
>
> Property changes on:
> ___
> Name: svk:merge
> +138bc75d-0d04-0410-961f-82ee72b054a4:/trunk:119713
> +23c3ee16-a423-49b3-8738-b114dc1aabb6:/local/gcc-pta-dev:259
> +23c3ee16-a423-49b3-8738-b114dc1aabb6:/local/gcc-trunk:531
> +7dca8dba-45c1-47dc-8958-1a7301c5ed47:/local-gcc/md-constraint:113709
> +f367781f-d768-471e-ba66-e306e17dff77:/local/gen-rework-20060122:110130
>
Re: "Fix alias slowdown" patch miscompiles 464.h264ref in SPEC CPU
On Sun, Dec 10, 2006 at 09:42:35PM -0800, H. J. Lu wrote: > On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote: > > Hey, by chance does the attached fix it? > > > > Yes, it fixes 464.h264ref with the test input. I am running the real > input now. > Do you need a testcase for your fix? We can try to extract one from 464.h264ref. Thanks. H.J.
Re: "Fix alias slowdown" patch miscompiles 464.h264ref in SPEC CPU
On Sun, Dec 10, 2006 at 09:42:35PM -0800, H. J. Lu wrote: > On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote: > > Hey, by chance does the attached fix it? > > > > Yes, it fixes 464.h264ref with the test input. I am running the real > input now. > It works for 464.h264ref with the real input. I will run SPEC CPU 2006 with gcc 4.3 revision 119728 plus your fix. It will take more than 24 hours. H.J.
Re: Serious SPEC CPU 2006 FP performance regressions on IA32 and x86-64
On Fri, Dec 08, 2006 at 01:02:27PM -0600, Menezes, Evandro wrote: > HJ, > > I'll run the three worst offenders below and get back to y'all. > > The full results will take longer. Hi Evandro, I also saw similar issues on x86-64 with -O2 -ffast-math: gcc-4.2 rev 116820 gcc 4.3 rev 119497 410.bwaves 10.910.6-2.75229% 416.gamess 15.015.64% 433.milc 13.012.9-0.769231% 434.zeusmp 13.913.90% 435.gromacs 8.418.40-0.118906% 436.cactusADM10.310.2-0.970874% 437.leslie3d 10.67.55-28.7736% 444.namd 13.613.60% 447.dealII 23.723.80.421941% 450.soplex 15.515.4-0.645161% 453.povray 17.718.75.64972% 454.calculix 6.967.041.14943% 459.GemsFDTD 12.39.87-19.7561% 465.tonto12.612.4-1.5873% 470.lbm 15.916.00.628931% 481.wrf 10.39.97-3.20388% 482.sphinx3 18.518.4-0.540541% Est. SPECfp_base2006 12.912.5-3.10078% Did you see it on AMD? H.J.
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
On Mon, Dec 11, 2006 at 11:35:27AM -0600, Menezes, Evandro wrote: > HJ, > > > > Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance > > > regressions on P4, Pentium M and Core Duo, comparing aganst > > > gcc 4.2 20060910. With -O2, the typical regressions look like > > > > > > Gcc 4.2 Gcc 4.3 > > > 410.bwaves 9.899.14-7.58342% > > > 416.gamess 7.177.16-0.13947% > > > 433.milc 7.687.65-0.390625% > > > 434.zeusmp 5.575.55-0.359066% > > > 435.gromacs 3.994.020.75188% > > > 436.cactusADM4.594.50-1.96078% > > > 437.leslie3d 5.783.98-31.1419% > > > 444.namd 6.256.18-1.12% > > > 447.dealII 11.311.30% > > > 450.soplex 8.618.59-0.232288% > > > 453.povray 6.706.720.298507% > > > 454.calculix 2.812.74-2.4911% > > > 459.GemsFDTD 6.074.95-18.4514% > > > 465.tonto4.444.450.225225% > > > 470.lbm 10.610.70.943396% > > > 481.wrf 4.564.50-1.31579% > > > 482.sphinx3 11.211.1-0.892857% > > > Est. SPECfp_base2006 6.426.15-4.20561% > > > > > > Evandro, what do you get on AMD? > > > > > > Is that related to recent i386 backend FP changes? > > Here's what we got: > > ?% > CPU2006 > 410.bwaves -6% > 416.gamess > 433.milc > 434.zeusmp > 435.gromacs > 436.cactusADM > 437.leslie3d -26% > 444.namd > 447.dealII > 450.soplex > 453.povray > 454.calculix > 459.GemsFDTD -12% > 465.tonto > 470.lbm > 481.wrf > 482.sphinx3 > > Though not as pronounced, definitely significant. > It is close to what we see on both x86 and x86-64. Are you going to track it down? H.J.
Succesfsull install
i686-pc-linux-gnu Using built-in specs. Target: i686-pc-linux-gnu Configured with: /disk2/Downloads/gcc/gcc-4.1.1/configure Thread model: posix gcc version 4.1.1 Fedora Core release 5 (Bordeaux) Kernel \r on an \m Linux 2.6.15-1.2054_FC5 #1 Tue Mar 14 15:48:33 EST 2006 i686 i686 i386 GNU/Linux
Re: gcc, mplayer and profile (mcount)
On Wed, Jan 03, 2007 at 10:18:36AM -0800, Seongbae Park wrote:
> >In fact, by default, gcc for the i386 targets will call _mcount. gcc
> >for i386 GNU/Linux targets was changed to call mcount instead of
> >_mcount with this patch:
> >
> >Thu Mar 30 06:20:36 1995 H.J. Lu ([EMAIL PROTECTED])
> >
> >* configure (i[345]86-*-linux*): Set xmake_file=x-linux,
> >tm_file=i386/linux.h, and don't set extra_parts.
> >(i[345]86-*-linux*aout*): New configuration.
> >(i[345]86-*-linuxelf): Deleted.
> >* config/linux{,-aout}.h, config/x-linux, config/xm-linux.h: New
> >files.
> >* config/i386/linux-aout.h: New file.
> >* config/i386/linux.h: Extensive modifications to use ELF format
> >as default.
> >(LIB_SPEC): Don't use libc_p.a for -p. don't use libg.a
> >unless for -ggdb.
> >(LINUX_DEFAULT_ELF): Defined.
> >* config/i386/linuxelf.h,config/i386/x-linux: Files deleted.
> >* config/i386/xm-linux.h: Just include xm-i386.h and xm-linux.h.
> >
> >I believe that was during the time H.J. was maintaining a separate
> >branch of glibc for GNU/Linux systems. Presumably his version
> >provided mcount but not _mcount. I haven't tried to investigate
> >further.
> >
> >In any case clearly gcc for i386 GNU/Linux systems today should call
> >_mcount rather than mcount. I will make that change.
>
> I remember someone wanting to provide his own mcount().
> Presumably, mcount() is weak in libc to cover such a use case ?
It was a mistake. I don't remember why I did that way when I switched
Linux from a.out to ELF. It should be fixed.
H.J.
The Linux binutils 2.17.50.0.9 is released
This is the beta release of binutils 2.17.50.0.9 for Linux, which is
based on binutils 2007 0103 in CVS on sourceware.org plus various
changes. It is purely for Linux.
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.17.50.0.9 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
If you don't use
# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2
to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.
Changes from binutils 2.17.50.0.8:
1. Update from binutils 2007 0103.
2. Fix --wrap linker bug.
3. Improve handling ELF binaries generated by foreign ELF linkers.
4. Various ELF M68K bug fixes.
5. Score bug fixes.
6. Don't read past end of archive elements. PR 3704.
7. Improve .eh_frame_hdr section handling.
8. Fix symbol visibility with comdat/linkonce sections in ELF linker.
PR 3666.
9. Fix 4 operand instruction handling in x86 assembler.
10. Properly check the 4th operand in x86 assembler. PR 3712.
11. Fix .cfi_endproc handling in assembler. PR 3607.
12. Various ARM bug fixes.
13. Various PE linker fixes.
14. Improve x86 dissassembler for cmpxchg8b.
Changes from binutils 2.17.50.0.7:
1. Update from binutils 2006 1201.
2. Fix "objcopy --only-keep-debug" crash. PR 3609.
3. Fix various ARM ELF bugs.
4. Fix various xtensa bugs.
5. Update x86 disassembler.
Changes from binutils 2.17.50.0.6:
1. Update from binutils 2006 1127.
2. Properly set ELF output segment address when the first section in
input segment is removed.
3. Better merging of CIEs in linker .eh_frame optimizations.
4. Support .cfi_personality and .cfi_lsda assembler directives.
5. Fix an ARM linker crash. PR 3532.
6. Fix various PPC64 ELF bugs.
7. Mark discarded debug info more thoroughly in linker output.
8. Fix various MIPS ELF bugs.
9. Fix readelf to display program interpreter path > 64 chars. PR 3384.
10. Add support for PowerPC SPU.
11. Properly handle cloned symbols used in relocations in assembler. PR
3469.
12. Update opcode for POPCNT in amdfam10 architecture.
Changes from binutils 2.17.50.0.5:
1. Update from binutils 2006 1020.
2. Don't make debug symbol dynamic. PR 3290.
3. Don't page align empty SHF_ALLOC sections, which leads to very large
executables. PR 3314.
4. Use a different section index for section relative symbols against
removed empty sections.
5. Fix a few ELF EH frame handling bugs.
6. Don't ignore relocation overflow on branches to undefweaks for
x86-64. PR 3283.
7. Rename MNI to SSSE3.
8. Properly append symbol list for --dynamic-list.
lists.
9. Various ARM ELF fixes.
10. Correct 64bit library search path for Linux/x86 linker with 64bit
support.
11. Fix ELF linker to copy OS/PROC specific flags from input section to
output section.
12. Fix DW_FORM_ref_addr handling in linker dwarf reader. PR 3191.
13
RFC: Implementation of ELF sharable sections
Here is one implementation of ELF sharable section proposal:
http://groups-beta.google.com/group/generic-abi/browse_thread/thread/bca08f6560f61b0d
Several people have expressed interests. I post it here for comments.
I used OS specific values. If we get consensus, I can change those
values to generic range.
H.J.
bfd/
2007-01-04 H.J. Lu <[EMAIL PROTECTED]>
* elf-bfd.h (_bfd_elf_sharable_com_section): New.
(_bfd_elf_add_sharable_symbol): Likewise.
(_bfd_elf_sharable_section_from_bfd_section): Likewise.
(_bfd_elf_sharable_symbol_processing): Likewise.
(_bfd_elf_sharable_common_definition): Likewise.
(_bfd_elf_sharable_common_section_index): Likewise.
(_bfd_elf_sharable_common_section): Likewise.
(_bfd_elf_sharable_merge_symbol): Likewise.
* elf.c (special_sections_g): Add ".gnu.linkonce.shrb" and
".gnu.linkonce.shrd".
(special_sections_s): Add ".sharable_bss" and ".sharable_data".
(get_program_header_size): Handle PT_GNU_SHR segment.
(_bfd_elf_map_sections_to_segments): Likewise.
(assign_file_positions_for_load_sections): Likewise.
* elf32-i386.c (elf_i386_link_hash_table): Add sdynsharablebss
and srelsharablebss fields.
(elf_i386_link_hash_table_create): Initialize sdynsharablebss
and srelsharablebss.
(elf_i386_create_dynamic_sections): Handle sdynsharablebss and
srelsharablebss.
(elf_i386_adjust_dynamic_symbol): Likewise.
(elf_i386_size_dynamic_sections): Likewise.
(elf_i386_finish_dynamic_symbol): Likewise.
(elf_backend_add_symbol_hook): Defined.
(elf_backend_section_from_bfd_section): Likewise.
(elf_backend_symbol_processing): Likewise.
(elf_backend_common_section_index): Likewise.
(elf_backend_common_section): Likewise.
(elf_backend_common_definition): Likewise.
(elf_backend_merge_symbol): Likewise.
* elf64-x86-64.c (elf64_x86_64_link_hash_table): Add
sdynsharablebss and srelsharablebss fields.
(elf64_x86_64_link_hash_table_create): Initialize sdynsharablebss
and srelsharablebss.
(elf64_x86_64_create_dynamic_sections): Handle sdynsharablebss
and srelsharablebss.
(elf64_x86_64_adjust_dynamic_symbol): Likewise.
(elf64_x86_64_size_dynamic_sections): Likewise.
(elf64_x86_64_finish_dynamic_symbol): Likewise.
(elf64_x86_64_add_symbol_hook): Handle sharable symbols.
(elf64_x86_64_elf_section_from_bfd_section): Likewise.
(elf64_x86_64_symbol_processing): Likewise.
(elf64_x86_64_merge_symbol): Likewise.
(elf64_x86_64_common_definition): Handle sharable sections.
(elf64_x86_64_common_section_index): Likewise.
(elf64_x86_64_common_section): Likewise.
* elflink.c (_bfd_elf_create_dynamic_sections): Handle
.dynsharablebss section.
(_bfd_elf_sharable_com_section): New.
(get_sharable_common_section): Likewise.
(_bfd_elf_add_sharable_symbol): Likewise.
(_bfd_elf_sharable_section_from_bfd_section): Likewise.
(_bfd_elf_sharable_symbol_processing): Likewise.
(_bfd_elf_sharable_common_definition): Likewise.
(_bfd_elf_sharable_common_section_index): Likewise.
(_bfd_elf_sharable_common_section): Likewise.
(_bfd_elf_sharable_merge_symbol): Likewise.
* elfxx-ia64.c (elfNN_ia64_add_symbol_hook): Handle sharable
symbols.
(elf_backend_add_symbol_hook): Defined.
(elf_backend_section_from_bfd_section): Likewise.
(elf_backend_symbol_processing): Likewise.
(elf_backend_common_section_index): Likewise.
(elf_backend_common_section): Likewise.
(elf_backend_common_definition): Likewise.
(elf_backend_merge_symbol): Likewise.
binutils/
2007-01-04 H.J. Lu <[EMAIL PROTECTED]>
* readelf.c (dump_relocations): Handle sharable sections.
(get_segment_type): Handle sharable segment.
(get_symbol_index_type): Handle sharable sections.
gas/
2007-01-04 H.J. Lu <[EMAIL PROTECTED]>
* config/obj-elf.c (obj_elf_sharable_common): New.
(elf_pseudo_table): Add "sharable_common".
(obj_elf_change_section): Handle sharable sections.
include/elf/
2007-01-04 H.J. Lu <[EMAIL PROTECTED]>
* common.h (PT_GNU_SHR): New.
(SHF_GNU_SHARABLE): Likewise.
(SHN_GNU_SHARABLE_COMMON): Likewise.
ld/
2007-01-04 H.J. Lu <[EMAIL PROTECTED]>
* emulparams/elf64_ia64.sh (SHARABLE_SECTIONS): Set to yes.
* emulparams/elf_i386.sh (SHARABLE_SECTIONS): Likewise.
* emulparams/elf_x86_64.sh (SHARABLE_SECTIONS): Likewise.
* emultempl/elf32.em: Include "elf-bfd.h".
(gld${EMULATION_NAME}_place_orphan): Don't allow orphaned
sharable sections.
* scripttempl/elf.sc: Support sharable sections.
--- binutils/bfd/elf-bfd.h
Re: RFC: Implementation of ELF sharable sections
On Fri, Jan 05, 2007 at 08:53:07AM +, Christoph Hellwig wrote: > On Thu, Jan 04, 2007 at 03:31:46PM -0800, H. J. Lu wrote: > > Here is one implementation of ELF sharable section proposal: > > > > http://groups-beta.google.com/group/generic-abi/browse_thread/thread/bca08f6560f61b0d > > > > Several people have expressed interests. I post it here for comments. > > I used OS specific values. If we get consensus, I can change those > > values to generic range. > > For Linux pleases don't put this into the ABI until the OS actually > supports this type of memory. Which I doubt it will anytime soon as > the concept is rather oddly defined and no one posted a kernel-level > design and implementation yet. Kernel support may be useful, but not strictly required. Consider shared libraries with sharable segment, they are loaded by dynamic linker, not kernel. Another thing, a sharabale segment isn't a PT_LOAD segment. Dynamic linker doesn't have to know it for applications to run correctly. So it is backward compatible. H.J.
Re: __sync_bool_compare_and_swap
On Fri, Jan 05, 2007 at 09:27:35PM +0100, Magnus Fromreide wrote: > On fre, 2007-01-05 at 17:05 +, Andrew Haley wrote: > > Magnus Fromreide writes: > > > > But it can't unless you use an architecture that has cmpxchgl. > > cmpxchgl is a 486 instruction; if you compile for 386, we have to > > generate the call because there is no such instruction. > > Sigh - I failed to tell how I built my compiler: > > I used the following configure line: > > ../trunk/configure -v --enable-languages=c,c++ --prefix=/usr/local/gcc-head > --enable-shared --with-system-zlib --without-included-gettext > --enable-threads=posix --disable-nls --enable-__cxa_atexit > --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 > --enable-checking=release i686-linux-gnu --enable-concept-checks > --enable-bootstrap > Can you try adding --with-arch=i686? H.J.
Re: We have no active maintainer for the i386 port
On Sat, Jan 06, 2007 at 04:42:27PM +0100, Steven Bosscher wrote: > Hi, > > We currently do not have an active maintainer for the i386 port. The > only listed maintainer for the port is rth, and he hasn't been around > to approve patches in a while. This situation is a bit strange for > a port that IMHO is one of the most important ports GCC has... > > In the mean time, patches don't get approved (see e.g. [1]), or they > get approved by middle-end maintainers who, strictly speaking, should > not be approving backend patches, as I understand it. > > So, can the SC please appoint a new/extra i386 port maintainer? > I think it is overdue. H.J.
RFC: Speeding up libstdc++.so with --dynamic-list-data
I am enclosing a patch to implement a new linker swicth,
--dynamic-list-data. It is -Bsymbolic for function symbols only.
I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64
and Linux/ia64. There are only a few regressions. The function calls
within the new resulting DSOs will bind locally. It speeds up
the enclosed C++ testcase by
1. 23% on ia64.
2. 6% on ia32.
3. 3% on x86-64.
Should we consider such optimization?
H.J.
bfd/
2007-01-05 H.J. Lu <[EMAIL PROTECTED]>
PR ld/3831
* elf-bfd.h (bfd_elf_link_mark_dynamic_symbol): Add an
argument, Elf_Internal_Sym *.
* elflink.c (bfd_elf_link_mark_dynamic_symbol): Mark a data
symbol dynamic if info->dynamic_data is TRUE.
(bfd_elf_record_link_assignment): Updated call to
bfd_elf_record_link_assignment.
(_bfd_elf_merge_symbol): Likewise. Always call
bfd_elf_link_mark_dynamic_symbol.
include/
2007-01-05 H.J. Lu <[EMAIL PROTECTED]>
PR ld/3831
* bfdlink.h (bfd_link_info): Rename dynamic to dynamic_list.
Add dynamic and dynamic_data.
ld/
2007-01-05 H.J. Lu <[EMAIL PROTECTED]>
PR ld/3831
* ldlang.c (lang_process): Change link_info.dynamic to
link_info.dynamic_list.
(lang_append_dynamic_list): Likewise.
* ldmain.c (main): Likewise. Initialize link_info.dynamic and
link_info.dynamic_data to FALSE.
* lexsup.c (option_values): Add OPTION_DYNAMIC_LIST_DATA.
(ld_options): --dynamic-list-data.
(parse_args): Change link_info.dynamic to
link_info.dynamic_list. Set link_info.dynamic_data to TRUE for
--dynamic-list-data. Set link_info.dynamic to TRUE for
--dynamuc-list*.
--- binutils/bfd/elf-bfd.h.data 2007-01-08 10:05:49.0 -0800
+++ binutils/bfd/elf-bfd.h 2007-01-08 10:05:49.0 -0800
@@ -1858,7 +1858,8 @@ extern int bfd_elf_link_record_local_dyn
(struct bfd_link_info *, bfd *, long);
extern void bfd_elf_link_mark_dynamic_symbol
- (struct bfd_link_info *, struct elf_link_hash_entry *);
+ (struct bfd_link_info *, struct elf_link_hash_entry *,
+ Elf_Internal_Sym *);
extern bfd_boolean _bfd_elf_close_and_cleanup
(bfd *);
--- binutils/bfd/elflink.c.data 2007-01-08 10:05:49.0 -0800
+++ binutils/bfd/elflink.c 2007-01-08 17:42:35.0 -0800
@@ -454,14 +454,22 @@ bfd_elf_link_record_dynamic_symbol (stru
void
bfd_elf_link_mark_dynamic_symbol (struct bfd_link_info *info,
- struct elf_link_hash_entry *h)
+ struct elf_link_hash_entry *h,
+ Elf_Internal_Sym *sym)
{
- struct bfd_elf_dynamic_list *d = info->dynamic;
+ struct bfd_elf_dynamic_list *d = info->dynamic_list;
- if (d == NULL || info->relocatable)
+ /* It may be called more than once on the same H. */
+ if(h->dynamic || info->relocatable)
return;
- if ((*d->match) (&d->head, NULL, h->root.root.string))
+ if ((info->dynamic_data
+ && (h->type == STT_OBJECT
+ || (sym != NULL
+ && ELF_ST_TYPE (sym->st_info) == STT_OBJECT)))
+ || (d != NULL
+ && h->root.type == bfd_link_hash_new
+ && (*d->match) (&d->head, NULL, h->root.root.string)))
h->dynamic = 1;
}
@@ -499,7 +507,7 @@ bfd_elf_record_link_assignment (bfd *out
if (h->root.type == bfd_link_hash_new)
{
- bfd_elf_link_mark_dynamic_symbol (info, h);
+ bfd_elf_link_mark_dynamic_symbol (info, h, NULL);
h->non_elf = 0;
}
@@ -906,13 +914,17 @@ _bfd_elf_merge_symbol (bfd *abfd,
|| h->root.type == bfd_link_hash_warning)
h = (struct elf_link_hash_entry *) h->root.u.i.link;
+ /* We have to check it for every instance since the first few may be
+ refereences and not all compilers emit symbol type for undefined
+ symbols. */
+ bfd_elf_link_mark_dynamic_symbol (info, h, sym);
+
/* If we just created the symbol, mark it as being an ELF symbol.
Other than that, there is nothing to do--there is no merge issue
with a newly defined symbol--so we just return. */
if (h->root.type == bfd_link_hash_new)
{
- bfd_elf_link_mark_dynamic_symbol (info, h);
h->non_elf = 0;
return TRUE;
}
--- binutils/include/bfdlink.h.data 2006-10-30 15:25:51.0 -0800
+++ binutils/include/bfdlink.h 2007-01-08 10:05:49.0 -0800
@@ -340,6 +340,13 @@ struct bfd_link_info
caching ELF symbol buffer. */
unsigned int reduce_memory_overheads: 1;
+ /* TRUE if all data symbols should be dynamic. */
+ unsigned int dynamic_data: 1;
+
+ /* TRUE if some symbols have to be dynamic, controlled by
+ --dynamic-list command line options. */
+ unsigned int dynamic: 1;
+
/* What to do with unresolved symbols in an object file.
When producing executables the default is GENERATE_ERROR.
When producing shared libraries the default is IGNORE. T
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Mon, Jan 08, 2007 at 08:09:59PM -0800, Andrew Pinski wrote: > On Mon, 2007-01-08 at 18:25 -0800, H. J. Lu wrote: > > I am enclosing a patch to implement a new linker swicth, > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > > and Linux/ia64. There are only a few regressions. The function calls > > within the new resulting DSOs will bind locally. It speeds up > > the enclosed C++ testcase by > > > > 1. 23% on ia64. > > 2. 6% on ia32. > > 3. 3% on x86-64. > > > > Should we consider such optimization? > > The real question is, does this work with operator new? > > In that if I a C++ developer provides a seperate operator new (and > delete), does libstdc++ use that one as required by the C++ standard? These are the regressions I was talking about. I can support them with a new linker switch. So far, we have --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list --dynamic-list FILE Read dynamic list My current proposal adds --dynamic-list-data Add data symbols to dynamic list I can add a new one --dynamic-list-cpp-new Add C++ new/delete to dynamic list Then we can build libstdc++ with --dynamic-list-data --dynamic-list-cpp-new H.J.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > H. J. Lu writes: > > I am enclosing a patch to implement a new linker swicth, > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > > and Linux/ia64. There are only a few regressions. The function calls > > within the new resulting DSOs will bind locally. It speeds up > > the enclosed C++ testcase by > > > > 1. 23% on ia64. > > 2. 6% on ia32. > > 3. 3% on x86-64. > > > > Should we consider such optimization? > > That's a terrible name for the option. What does it mean? It is an extension of the current command line options: --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list --dynamic-list FILE Read dynamic list H.J.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote: > H. J. Lu writes: > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > > H. J. Lu writes: > > > > I am enclosing a patch to implement a new linker swicth, > > > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > > > > and Linux/ia64. There are only a few regressions. The function calls > > > > within the new resulting DSOs will bind locally. It speeds up > > > > the enclosed C++ testcase by > > > > > > > > 1. 23% on ia64. > > > > 2. 6% on ia32. > > > > 3. 3% on x86-64. > > > > > > > > Should we consider such optimization? > > > > > > That's a terrible name for the option. What does it mean? > > > > It is an extension of the current command line options: > > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > > --dynamic-list FILE Read dynamic list > > But you said it was like -Bsymbolic for function symbols only. What > is the connection between C++ typeinfo and that? (Hint: Java doesn't > use C++ typeinfo, but -Bsymbolic for function symbols only would be > very useful.) --dynamic-list is a generic linker feature. Users have to provide a list of symbols, which will be bound dynamically and everything else is bound locally. --dynamic-list-cpp-typeinfo includes a prefined list for C++ typeinfo. --dynamic-list-data puts data symbols on the dynamic list. H.J.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote: > H. J. Lu writes: > > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote: > > > H. J. Lu writes: > > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > > > > H. J. Lu writes: > > > > > > I am enclosing a patch to implement a new linker swicth, > > > > > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > > > > > I tried it with C, C++, Java and Fortran on Linux/ia32, > Linux/x86-64 > > > > > > and Linux/ia64. There are only a few regressions. The function > calls > > > > > > within the new resulting DSOs will bind locally. It speeds up > > > > > > the enclosed C++ testcase by > > > > > > > > > > > > 1. 23% on ia64. > > > > > > 2. 6% on ia32. > > > > > > 3. 3% on x86-64. > > > > > > > > > > > > Should we consider such optimization? > > > > > > > > > > That's a terrible name for the option. What does it mean? > > > > > > > > It is an extension of the current command line options: > > > > > > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > > > > --dynamic-list FILE Read dynamic list > > > > > > But you said it was like -Bsymbolic for function symbols only. What > > > is the connection between C++ typeinfo and that? (Hint: Java doesn't > > > use C++ typeinfo, but -Bsymbolic for function symbols only would be > > > very useful.) > > > > --dynamic-list is a generic linker feature. Users have to provide a > > list of symbols, which will be bound dynamically and everything else > > is bound locally. --dynamic-list-cpp-typeinfo includes a prefined > > list for C++ typeinfo. --dynamic-list-data puts data symbols on > > the dynamic list. > > OK, so in the case of --dynamic-list-data, there is no user-supplied > list. Instead, there's (conceptually) an automatically-generated > list, which contains every symbol that doesn't point to a function. > Can't you just call the new option -Bsymbolic-functions? At least > then people like me might have an outside chance of remembering it. Here is the updated patch to use -Bsymbolic-functions instead. H.J. --- bfd/ 2007-01-05 H.J. Lu <[EMAIL PROTECTED]> PR ld/3831 * elf-bfd.h (bfd_elf_link_mark_dynamic_symbol): Add an argument, Elf_Internal_Sym *. * elflink.c (bfd_elf_link_mark_dynamic_symbol): Mark a data symbol dynamic if info->symbolic_functions is TRUE. (bfd_elf_record_link_assignment): Updated call to bfd_elf_record_link_assignment. (_bfd_elf_merge_symbol): Likewise. Always call bfd_elf_link_mark_dynamic_symbol. include/ 2007-01-05 H.J. Lu <[EMAIL PROTECTED]> PR ld/3831 * bfdlink.h (bfd_link_info): Rename dynamic to dynamic_list. Add dynamic and symbolic_functions. ld/ 2007-01-05 H.J. Lu <[EMAIL PROTECTED]> PR ld/3831 * ldlang.c (lang_process): Change link_info.dynamic to link_info.dynamic_list. (lang_append_dynamic_list): Likewise. * ldmain.c (main): Likewise. Initialize link_info.dynamic and link_info.symbolic_functions to FALSE. * lexsup.c (option_values): Add OPTION_SYMBOLIC_FUNCTIONS. (ld_options): Add -Bsymbolic-functions. (parse_args): Change link_info.dynamic to link_info.dynamic_list. Set link_info.symbolic_functions to TRUE for -Bsymbolic-functions. Set link_info.dynamic to TRUE for --dynamic-list and --dynamic-list-cpp-typeinfo. --- binutils/bfd/elf-bfd.h.data 2007-01-09 05:49:14.0 -0800 +++ binutils/bfd/elf-bfd.h 2007-01-09 06:15:11.0 -0800 @@ -1858,7 +1858,8 @@ extern int bfd_elf_link_record_local_dyn (struct bfd_link_info *, bfd *, long); extern void bfd_elf_link_mark_dynamic_symbol - (struct bfd_link_info *, struct elf_link_hash_entry *); + (struct bfd_link_info *, struct elf_link_hash_entry *, + Elf_Internal_Sym *); extern bfd_boolean _bfd_elf_close_and_cleanup (bfd *); --- binutils/bfd/elflink.c.data 2007-01-09 05:49:14.0 -0800 +++ binutils/bfd/elflink.c 2007-01-09 06:15:11.0 -0800 @@ -454,14 +454,22 @@ bfd_elf_link_record_dynamic_symbol (stru void bfd_elf_link_mark_dynamic_symbol (struct bfd_link_info *info, - struct elf_link_hash_entry *h) + struct elf_link_hash_entry *h, +
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Mon, Jan 08, 2007 at 08:23:39PM -0800, H. J. Lu wrote:
> On Mon, Jan 08, 2007 at 08:09:59PM -0800, Andrew Pinski wrote:
> > On Mon, 2007-01-08 at 18:25 -0800, H. J. Lu wrote:
> > > I am enclosing a patch to implement a new linker swicth,
> > > --dynamic-list-data. It is -Bsymbolic for function symbols only.
> > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64
> > > and Linux/ia64. There are only a few regressions. The function calls
> > > within the new resulting DSOs will bind locally. It speeds up
> > > the enclosed C++ testcase by
> > >
> > > 1. 23% on ia64.
> > > 2. 6% on ia32.
> > > 3. 3% on x86-64.
> > >
> > > Should we consider such optimization?
> >
> > The real question is, does this work with operator new?
> >
> > In that if I a C++ developer provides a seperate operator new (and
> > delete), does libstdc++ use that one as required by the C++ standard?
>
> These are the regressions I was talking about. I can support them with
> a new linker switch. So far, we have
>
> --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list
> --dynamic-list FILE Read dynamic list
>
> My current proposal adds
>
> --dynamic-list-data Add data symbols to dynamic list
>
> I can add a new one
>
> --dynamic-list-cpp-new Add C++ new/delete to dynamic list
>
> Then we can build libstdc++ with
>
> --dynamic-list-data --dynamic-list-cpp-new
>
I am testing this patch now. It should fix the regresions when
libstdc++ is built with
-Bsymbolic-functions --dynamic-list-cpp-new
H.J.
2007-01-09 H.J. Lu <[EMAIL PROTECTED]>
* ldlang.c (lang_append_dynamic_list_cpp_new): New.
* ldlang.h (lang_append_dynamic_list_cpp_new): Likewise.
* lexsup.c (option_values): Add OPTION_DYNAMIC_LIST_CPP_NEW.
(ld_options): Add entries for OPTION_DYNAMIC_LIST_CPP_NEW.
(parse_args): Handle OPTION_DYNAMIC_LIST_CPP_NEW.
--- ld/ldlang.c.new 2007-01-09 06:15:11.0 -0800
+++ ld/ldlang.c 2007-01-09 06:20:41.0 -0800
@@ -7086,3 +7086,24 @@ lang_append_dynamic_list_cpp_typeinfo (v
lang_append_dynamic_list (dynamic);
}
+
+/* Append the list of C++ operator new and delete dynamic symbols to the
+ existing one. */
+
+void
+lang_append_dynamic_list_cpp_new (void)
+{
+ const char * symbols [] =
+{
+ "operator new*",
+ "operator delete*"
+};
+ struct bfd_elf_version_expr *dynamic = NULL;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE (symbols); i++)
+dynamic = lang_new_vers_pattern (dynamic, symbols [i], "C++",
+FALSE);
+
+ lang_append_dynamic_list (dynamic);
+}
--- ld/ldlang.h.new 2006-10-25 07:31:37.0 -0700
+++ ld/ldlang.h 2007-01-09 06:21:08.0 -0800
@@ -607,6 +607,7 @@ extern void lang_register_vers_node
(const char *, struct bfd_elf_version_tree *, struct bfd_elf_version_deps *);
extern void lang_append_dynamic_list (struct bfd_elf_version_expr *);
extern void lang_append_dynamic_list_cpp_typeinfo (void);
+extern void lang_append_dynamic_list_cpp_new (void);
bfd_boolean unique_section_p
(const asection *);
extern void lang_add_unique
--- ld/lexsup.c.new 2007-01-09 06:15:11.0 -0800
+++ ld/lexsup.c 2007-01-09 06:22:30.0 -0800
@@ -109,6 +109,7 @@ enum option_values
OPTION_VERSION_SCRIPT,
OPTION_VERSION_EXPORTS_SECTION,
OPTION_DYNAMIC_LIST,
+ OPTION_DYNAMIC_LIST_CPP_NEW,
OPTION_DYNAMIC_LIST_CPP_TYPEINFO,
OPTION_WARN_COMMON,
OPTION_WARN_CONSTRUCTORS,
@@ -506,6 +507,8 @@ static const struct ld_option ld_options
OPTION_VERSION_EXPORTS_SECTION },
'\0', N_("SYMBOL"), N_("Take export symbols list from .exports, using\n"
"\t\t\t\tSYMBOL as the version."), TWO_DASHES },
+ { {"dynamic-list-cpp-new", no_argument, NULL, OPTION_DYNAMIC_LIST_CPP_NEW},
+'\0', NULL, N_("Use C++ operator new/delete dynamic list"), TWO_DASHES },
{ {"dynamic-list-cpp-typeinfo", no_argument, NULL,
OPTION_DYNAMIC_LIST_CPP_TYPEINFO},
'\0', NULL, N_("Use C++ typeinfo dynamic list"), TWO_DASHES },
{ {"dynamic-list", required_argument, NULL, OPTION_DYNAMIC_LIST},
@@ -1255,6 +1258,10 @@ parse_args (unsigned argc, char **argv)
lang_append_dynamic_list_cpp_typeinfo ();
link_info.dynamic = TRUE;
break;
+ case OPTION_DYNAMIC_LIST_CPP_NEW:
+ lang_append_dynamic_list_cpp_new ();
+ link_info.dynamic = TRUE;
+ break;
case OPTION_DYNAMIC_LIST:
/* This option indicates a small script that only specifies
a dynamic list. Read it, but don't assume that we've
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 04:42:41PM +0100, Paolo Bonzini wrote: > > >I am testing this patch now. It should fix the regresions when > >libstdc++ is built with > > > >-Bsymbolic-functions --dynamic-list-cpp-new I tested it on gcc 4.2 with C, C++, Java and Fortran on Linux/x86-64. There is no regression. > > What about just --dynamic-list-cpp that enables the new behavior and > implies --dynamic-list-cpp-typeinfo (I know that it is useless in this > particular case, since C++ typeinfo is data, but in general such an > option sounds more useful than only --dynamic-list-cpp-new). I think you only need --dynamic-list-cpp-new for building libstdc++.so. -Bsymbolic-functions should be sufficient for other C++ shared libraries. H.J.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 06:18:19AM -0800, H. J. Lu wrote: > On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote: > > H. J. Lu writes: > > > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote: > > > > H. J. Lu writes: > > > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > > > > > H. J. Lu writes: > > > > > > > I am enclosing a patch to implement a new linker swicth, > > > > > > > --dynamic-list-data. It is -Bsymbolic for function symbols > > only. > > > > > > > I tried it with C, C++, Java and Fortran on Linux/ia32, > > Linux/x86-64 > > > > > > > and Linux/ia64. There are only a few regressions. The function > > calls > > > > > > > within the new resulting DSOs will bind locally. It speeds up > > > > > > > the enclosed C++ testcase by > > > > > > > > > > > > > > 1. 23% on ia64. > > > > > > > 2. 6% on ia32. > > > > > > > 3. 3% on x86-64. > > > > > > > > > > > > > > Should we consider such optimization? > > > > > > > > > > > > That's a terrible name for the option. What does it mean? > > > > > > > > > > It is an extension of the current command line options: > > > > > > > > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > > > > > --dynamic-list FILE Read dynamic list > > > > > > > > But you said it was like -Bsymbolic for function symbols only. What > > > > is the connection between C++ typeinfo and that? (Hint: Java doesn't > > > > use C++ typeinfo, but -Bsymbolic for function symbols only would be > > > > very useful.) > > > > > > --dynamic-list is a generic linker feature. Users have to provide a > > > list of symbols, which will be bound dynamically and everything else > > > is bound locally. --dynamic-list-cpp-typeinfo includes a prefined > > > list for C++ typeinfo. --dynamic-list-data puts data symbols on > > > the dynamic list. > > > > OK, so in the case of --dynamic-list-data, there is no user-supplied > > list. Instead, there's (conceptually) an automatically-generated > > list, which contains every symbol that doesn't point to a function. > > Can't you just call the new option -Bsymbolic-functions? At least > > then people like me might have an outside chance of remembering it. > > Here is the updated patch to use -Bsymbolic-functions instead. > I just realized that --dynamic-list-data is -Bsymbolic for function symbols only when you build shared libraries. We can use --dynamic-list-data on executables to make global data symbols dynamic so that dlopened shared libraries can reference them. We can make -Bsymbolic-functions an alias of --dynamic-list-data. But we still need --dynamic-list-data since -Bsymbolic doesn't apply to executables. H.J.
RFC: Mark a section to be discarded for DSO and executable
With LTO, an object file may contain sections with IL, which can be discarded when building DSO and executable. Currently we can't mark such sections with gABI. With GNU linker, we can use a linker script to discard such sections. But it will be more generic to make a section to be discarded for DSO and executable in gABI. In that case, we don't need a special linker script to discard such sections. Something like #define SHF_DISCARD 0x800 would work. H.J.
Re: RFC: Mark a section to be discarded for DSO and executable
On Tue, Jan 09, 2007 at 10:09:35AM -0800, Ian Lance Taylor wrote: > > That is not strictly required for LTO as I see it. With LTO, the lto > program is going to read the .o files with the IL information. It > will then generate a new .s file to pass to the assembler. The IL > information will never go through the linker. > > Of course, it is also possible that LTO .o files with IL information > will be passed directly to the linker, for whatever reason. In that > case, we may want the linker to remove the IL information. This is > not substantially different from the linker's current ability to strip > debugging information on request. It is different since stripping debugging information is controlled by a linker switch. The new section attribute will make section to be discarded regardless any linker switch. > > So if you want to propose a solution for that, I think you should > consider how it can be used for debugging information as well. And I > don't think SHF_DISCARD is a good name. We don't want to arbitrarily > discard the data, we want to discard it in certain specific scenarios. It is just a way to make a section to be discarded for executable and DSO. I am not sure if you want to mark debugging information to be discarded unless you mean a switch which will ignore the new attribute so that such debugging information won't be discarded. You should mark a section with SHF_DISCARD only if such a section will be removed during final link in all scenarios. H.J.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 09:42:40AM -0800, H. J. Lu wrote: > On Tue, Jan 09, 2007 at 06:18:19AM -0800, H. J. Lu wrote: > > On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote: > > > H. J. Lu writes: > > > > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote: > > > > > H. J. Lu writes: > > > > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote: > > > > > > > H. J. Lu writes: > > > > > > > > I am enclosing a patch to implement a new linker swicth, > > > > > > > > --dynamic-list-data. It is -Bsymbolic for function symbols > > > only. > > > > > > > > I tried it with C, C++, Java and Fortran on Linux/ia32, > > > Linux/x86-64 > > > > > > > > and Linux/ia64. There are only a few regressions. The > > > function calls > > > > > > > > within the new resulting DSOs will bind locally. It speeds up > > > > > > > > the enclosed C++ testcase by > > > > > > > > > > > > > > > > 1. 23% on ia64. > > > > > > > > 2. 6% on ia32. > > > > > > > > 3. 3% on x86-64. > > > > > > > > > > > > > > > > Should we consider such optimization? > > > > > > > > > > > > > > That's a terrible name for the option. What does it mean? > > > > > > > > > > > > It is an extension of the current command line options: > > > > > > > > > > > > --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list > > > > > > --dynamic-list FILE Read dynamic list > > > > > > > > > > But you said it was like -Bsymbolic for function symbols only. What > > > > > is the connection between C++ typeinfo and that? (Hint: Java doesn't > > > > > use C++ typeinfo, but -Bsymbolic for function symbols only would be > > > > > very useful.) > > > > > > > > --dynamic-list is a generic linker feature. Users have to provide a > > > > list of symbols, which will be bound dynamically and everything else > > > > is bound locally. --dynamic-list-cpp-typeinfo includes a prefined > > > > list for C++ typeinfo. --dynamic-list-data puts data symbols on > > > > the dynamic list. > > > > > > OK, so in the case of --dynamic-list-data, there is no user-supplied > > > list. Instead, there's (conceptually) an automatically-generated > > > list, which contains every symbol that doesn't point to a function. > > > Can't you just call the new option -Bsymbolic-functions? At least > > > then people like me might have an outside chance of remembering it. > > > > Here is the updated patch to use -Bsymbolic-functions instead. > > > > I just realized that --dynamic-list-data is -Bsymbolic for function > symbols only when you build shared libraries. We can use > --dynamic-list-data on executables to make global data symbols > dynamic so that dlopened shared libraries can reference them. We can > make -Bsymbolic-functions an alias of --dynamic-list-data. But > we still need --dynamic-list-data since -Bsymbolic doesn't apply to > executables. Here is the updated patch with testcases and document change. H.J. bfd/ 2007-01-09 H.J. Lu <[EMAIL PROTECTED]> PR ld/3831 * elf-bfd.h (bfd_elf_link_mark_dynamic_symbol): Add an argument, Elf_Internal_Sym *. * elflink.c (bfd_elf_link_mark_dynamic_symbol): Mark a data symbol dynamic if info->dynamic_data is TRUE. (bfd_elf_record_link_assignment): Updated call to bfd_elf_record_link_assignment. (_bfd_elf_merge_symbol): Likewise. Always call bfd_elf_link_mark_dynamic_symbol. include/ 2007-01-09 H.J. Lu <[EMAIL PROTECTED]> PR ld/3831 * bfdlink.h (bfd_link_info): Rename dynamic to dynamic_list. Add dynamic and dynamic_data. ld/ 2007-01-05 H.J. Lu <[EMAIL PROTECTED]> PR ld/3831 * NEWS: Mention -Bsymbolic-functions and --dynamic-list-data. * ld.texinfo: Document -Bsymbolic-functions and --dynamic-list-data. * ldlang.c (lang_process): Change link_info.dynamic to link_info.dynamic_list. (lang_append_dynamic_list): Likewise. * ldmain.c (main): Likewise. Initialize link_info.dynamic and link_info.dynamic_data to FALSE. * lexsup.c (opti
Is delete (nothrow) supported?
Does gcc support "delete (nothrow)"? I ran into 2 problems: 1. I had to call destructor directly since A *p = new (std::nothrow) A; delete (std::nothrow) p; won't cpmpile. I had to use A *p = new (std::nothrow) A; ... operator delete (bb, std::nothrow); 2. A *bb = new (std::nothrow) A [10]; ... operator delete [] (bb, std::nothrow); causes memory corruption since compiler doesn't support delete (std::nothrow) [] p; What is the proper way to use "delete (nothrow)"? H.J.
Re: Is delete (nothrow) supported?
On Tue, Jan 09, 2007 at 01:55:44PM -0800, H. J. Lu wrote: > Does gcc support "delete (nothrow)"? I ran into 2 problems: > > 1. I had to call destructor directly since > > A *p = new (std::nothrow) A; > delete (std::nothrow) p; > > won't cpmpile. I had to use > > A *p = new (std::nothrow) A; > ... > operator delete (bb, std::nothrow); > > 2. > > A *bb = new (std::nothrow) A [10]; > ... > operator delete [] (bb, std::nothrow); > > causes memory corruption since compiler doesn't support > > delete (std::nothrow) [] p; > > What is the proper way to use "delete (nothrow)"? I figured out that "delete (nothrow)" is mainly for compiler uses. H.J.
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Tue, Jan 09, 2007 at 07:52:42AM -0800, H. J. Lu wrote:
> >
> > What about just --dynamic-list-cpp that enables the new behavior and
> > implies --dynamic-list-cpp-typeinfo (I know that it is useless in this
> > particular case, since C++ typeinfo is data, but in general such an
> > option sounds more useful than only --dynamic-list-cpp-new).
>
> I think you only need --dynamic-list-cpp-new for building libstdc++.so.
> -Bsymbolic-functions should be sufficient for other C++ shared
> libraries.
>
Here is a patch for --dynamic-list-cpp-new with a testcase.
H.J.
---
ld/
2007-01-09 H.J. Lu <[EMAIL PROTECTED]>
* NEWS: Mention --dynamic-list-cpp-new.
* ld.texinfo: Document --dynamic-list-cpp-new.
* ldlang.c (lang_append_dynamic_list_cpp_new): New.
* ldlang.h (lang_append_dynamic_list_cpp_new): Likewise.
* lexsup.c (option_values): Add OPTION_DYNAMIC_LIST_CPP_NEW.
(ld_options): Add entry for --dynamic-list-cpp-new.
(parse_args): Handle OPTION_DYNAMIC_LIST_CPP_NEW.
ld/testsuite/
2007-01-09 H.J. Lu <[EMAIL PROTECTED]>
* ld-elf/del.cc: New.
* ld-elf/dl5.cc: Likewise.
* ld-elf/dl5.out: Likewise.
* ld-elf/new.cc: Likewise.
* ld-elf/shared.exp: Add --dynamic-list-cpp-new testcase.
--- ld/NEWS.new 2007-01-09 11:34:46.0 -0800
+++ ld/NEWS 2007-01-09 11:34:53.0 -0800
@@ -1,4 +1,7 @@
-*- text -*-
+* ELF: Add --dynamic-list-cpp-new, which puts C++ operator new and
+ delete on the dynamic list.
+
* ELF: Add -Bsymbolic-functions and --dynamic-list-data, builtin list
for --dynamic-list, which puts global data symbols on the dynamic list.
--- ld/ld.texinfo.new 2007-01-09 11:22:59.0 -0800
+++ ld/ld.texinfo 2007-01-09 11:31:50.0 -0800
@@ -1155,6 +1155,11 @@ scope and node name. See @ref{VERSION}
@item --dynamic-list-data
Include all global data symbols to the dynamic list.
[EMAIL PROTECTED] --dynamic-list-cpp-new
[EMAIL PROTECTED] --dynamic-list-cpp-new
+Provide the builtin dynamic list for C++ operator new and delete. It
+is mainly useful for building shared libstdc++.
+
@kindex --dynamic-list-cpp-typeinfo
@item --dynamic-list-cpp-typeinfo
Provide the builtin dynamic list for C++ runtime type identification.
--- ld/ldlang.c.new 2007-01-09 11:22:59.0 -0800
+++ ld/ldlang.c 2007-01-09 11:22:59.0 -0800
@@ -7086,3 +7086,24 @@ lang_append_dynamic_list_cpp_typeinfo (v
lang_append_dynamic_list (dynamic);
}
+
+/* Append the list of C++ operator new and delete dynamic symbols to the
+ existing one. */
+
+void
+lang_append_dynamic_list_cpp_new (void)
+{
+ const char * symbols [] =
+{
+ "operator new*",
+ "operator delete*"
+};
+ struct bfd_elf_version_expr *dynamic = NULL;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE (symbols); i++)
+dynamic = lang_new_vers_pattern (dynamic, symbols [i], "C++",
+FALSE);
+
+ lang_append_dynamic_list (dynamic);
+}
--- ld/ldlang.h.new 2006-10-24 23:49:21.0 -0700
+++ ld/ldlang.h 2007-01-09 11:22:59.0 -0800
@@ -607,6 +607,7 @@ extern void lang_register_vers_node
(const char *, struct bfd_elf_version_tree *, struct bfd_elf_version_deps *);
extern void lang_append_dynamic_list (struct bfd_elf_version_expr *);
extern void lang_append_dynamic_list_cpp_typeinfo (void);
+extern void lang_append_dynamic_list_cpp_new (void);
bfd_boolean unique_section_p
(const asection *);
extern void lang_add_unique
--- ld/lexsup.c.new 2007-01-09 11:22:59.0 -0800
+++ ld/lexsup.c 2007-01-09 11:24:13.0 -0800
@@ -108,6 +108,7 @@ enum option_values
OPTION_VERSION_SCRIPT,
OPTION_VERSION_EXPORTS_SECTION,
OPTION_DYNAMIC_LIST,
+ OPTION_DYNAMIC_LIST_CPP_NEW,
OPTION_DYNAMIC_LIST_CPP_TYPEINFO,
OPTION_DYNAMIC_LIST_DATA,
OPTION_WARN_COMMON,
@@ -508,6 +509,8 @@ static const struct ld_option ld_options
'\0', NULL, N_("Bind global function references locally"), ONE_DASH },
{ {"dynamic-list-data", no_argument, NULL, OPTION_DYNAMIC_LIST_DATA},
'\0', NULL, N_("Add data symbols to dynamic list"), TWO_DASHES },
+ { {"dynamic-list-cpp-new", no_argument, NULL, OPTION_DYNAMIC_LIST_CPP_NEW},
+'\0', NULL, N_("Use C++ operator new/delete dynamic list"), TWO_DASHES },
{ {"dynamic-list-cpp-typeinfo", no_argument, NULL,
OPTION_DYNAMIC_LIST_CPP_TYPEINFO},
'\0', NULL, N_("Use C++ typeinfo dynamic list"), TWO_DASHES },
{ {"dynamic-list", required_argument, NULL, OPTION_DYNAMIC_LIST},
@@ -1257,6 +1260,10 @@ parse_args (unsigned argc, char **argv)
lang_append_dynamic_list_cpp_typeinfo ();
link_info.dynamic = TRUE;
break;
+ case OPTION_DYNAMIC_LIST_CP
Build shared libraries with -Bsymbolic-functions
With the new linker switches, -Bsymbolic-functions and --dynamic-list-cpp-new, we can improve shared library performance in gcc. This change will build libstdc++.so with -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it to other libraries. H.J. -- --- gcc/libstdc++-v3/acinclude.m4.symbolic 2007-01-09 16:43:09.0 -0800 +++ gcc/libstdc++-v3/acinclude.m4 2007-01-09 17:10:30.0 -0800 @@ -299,6 +299,22 @@ AC_DEFUN([GLIBCXX_CHECK_LINKER_FEATURES] AC_MSG_RESULT($ac_ld_relro) fi + # Set --dynamic-list-cpp-new and -Bsymbolic-functions + # Note this is only for shared objects. + ac_ld_symbolic_functions=no + if test x"$with_gnu_ld" = x"yes"; then +AC_MSG_CHECKING([for ld that supports --dynamic-list-cpp-new and -Bsymbolic-functions]) +cxx_symbolic_functions=`$LD -v --help 2>/dev/null | grep "dynamic-list-cpp-new"` +if test -n "$cxx_symbolic_functions"; then + cxx_symbolic_functions=`$LD -v --help 2>/dev/null | grep "Bsymbolic-functions"` +fi +if test -n "$cxx_symbolic_functions"; then + OPT_LDFLAGS="$OPT_LDFLAGS -Wl,--dynamic-list-cpp-new,-Bsymbolic-functions" + ac_ld_symbolic_functions=yes +fi +AC_MSG_RESULT($ac_ld_symbolic_functions) + fi + # Set linker optimization flags. if test x"$with_gnu_ld" = x"yes"; then OPT_LDFLAGS="-Wl,-O1 $OPT_LDFLAGS"
Re: Build shared libraries with -Bsymbolic-functions
On Wed, Jan 10, 2007 at 07:19:17AM -0800, Ian Lance Taylor wrote: > "H. J. Lu" <[EMAIL PROTECTED]> writes: > > > With the new linker switches, -Bsymbolic-functions and > > --dynamic-list-cpp-new, we can improve shared library > > performance in gcc. This change will build libstdc++.so with > > -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it > > to other libraries. > > To be clear, this will prevent programs from overriding functions > defined in libstdc++.so which are called by other functions in > libstdc++.so. Are we sure this is desirable? Note in particular that > libstdc++.so includes several functions defined as extern "C", the > __cxa functions. What does C++ standard say? If standard doesn't say we have to support it, I don't see there is a problem. > > In particular I've seen programs which override __cxa_pure_virtual in > order to give a more informative error message. Can user override those symbols on all platforms? H.J.
PATCH: Build shared libraries with -Bsymbolic-functions
On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote: > >>>>> "H.J." == H J Lu <[EMAIL PROTECTED]> writes: > > H.J.> With the new linker switches, -Bsymbolic-functions and > H.J.> --dynamic-list-cpp-new, we can improve shared library > H.J.> performance in gcc. This change will build libstdc++.so with > H.J.> -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it > H.J.> to other libraries. > > I prefer to see semi-generic helper code like this in a new .m4 file > in config. That makes it somewhat simpler for other target libraries > to reuse it. > Here it is. If it is OK, I will extend it to Java and Fortran. H.J. --- config/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * lib-ld.m4 (AC_LIB_PROG_LD_GNU_SYMBOLIC): New. (AC_LIB_PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW): Likewise. libstdc++-v3/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * aclocal.m4: Include ../config/lib-ld.m4. * configure.ac: Use AC_LIB_PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW. * configure: Regenerated. * Makefile.in: Likewise. * src/Makefile.am (CXXLINK): Add $(DYNAMIC_LIST_CPP_NEW_LDFLAGS). * src/Makefile.in: Regenerated. --- gcc/config/lib-ld.m4.symbolic 2005-11-01 13:56:29.0 -0800 +++ gcc/config/lib-ld.m42007-01-10 10:49:49.0 -0800 @@ -108,3 +108,43 @@ fi test -z "$LD" && AC_MSG_ERROR([no acceptable ld found in \$PATH]) AC_LIB_PROG_LD_GNU ]) + +dnl Substitute SYMBOLIC_LDFLAGS with -Bsymbolic-functions for GNU linker +dnl if it is supported. +AC_DEFUN([AC_LIB_PROG_LD_GNU_SYMBOLIC], +[AC_CACHE_CHECK([if the GNU linker ($LD) supports -Bsymbolic-functions], +acl_cv_prog_gnu_ld_symbolic, [ +acl_cv_prog_gnu_ld_symbolic=no +if test x"$with_gnu_ld" = x"yes"; then + if $LD --help 2>&1 &5; then +acl_cv_prog_gnu_ld_symbolic=yes + fi +fi]) +if test x"$acl_cv_prog_gnu_ld_symbolic" = x"yes"; then + SYMBOLIC_LDFLAGS="-Wl,-Bsymbolic-functions" +else + SYMBOLIC_LDFLAGS='' +fi +AC_SUBST(SYMBOLIC_LDFLAGS) +]) + +dnl Substitute DYNAMIC_LIST_CPP_NEW_LDFLAGS with --dynamic-list-cpp-new +dnl for GNU linker if it is supported. +AC_DEFUN([AC_LIB_PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW], +[AC_CACHE_CHECK([if the GNU linker ($LD) supports --dynamic-list-cpp-new], +acl_cv_prog_gnu_ld_dynamic_list_cpp_new, [ +acl_cv_prog_gnu_ld_dynamic_list_cpp_new=no +if test x"$with_gnu_ld" = x"yes"; then + if $LD --help 2>&1 &5; then +acl_cv_prog_gnu_ld_dynamic_list_cpp_new=yes + fi +fi]) +AC_LIB_PROG_LD_GNU_SYMBOLIC +if test x"$acl_cv_prog_gnu_ld_symbolic" = x"yes" -a \ + x"$acl_cv_prog_gnu_ld_dynamic_list_cpp_new" = x"yes"; then + DYNAMIC_LIST_CPP_NEW_LDFLAGS="$SYMBOLIC_LDFLAGS -Wl,--dynamic-list-cpp-new" +else + DYNAMIC_LIST_CPP_NEW_LDFLAGS='' +fi +AC_SUBST(DYNAMIC_LIST_CPP_NEW_LDFLAGS) +]) --- gcc/libstdc++-v3/Makefile.in.symbolic 2006-10-17 07:33:04.0 -0700 +++ gcc/libstdc++-v3/Makefile.in2007-01-10 10:33:04.0 -0800 @@ -50,9 +50,10 @@ am__aclocal_m4_deps = $(top_srcdir)/../c $(top_srcdir)/../config/multi.m4 \ $(top_srcdir)/../config/no-executables.m4 \ $(top_srcdir)/../config/unwind_ipinfo.m4 \ - $(top_srcdir)/../libtool.m4 $(top_srcdir)/crossconfig.m4 \ - $(top_srcdir)/linkage.m4 $(top_srcdir)/acinclude.m4 \ - $(top_srcdir)/../config/tls.m4 $(top_srcdir)/configure.ac + $(top_srcdir)/../config/lib-ld.m4 $(top_srcdir)/../libtool.m4 \ + $(top_srcdir)/crossconfig.m4 $(top_srcdir)/linkage.m4 \ + $(top_srcdir)/acinclude.m4 $(top_srcdir)/../config/tls.m4 \ + $(top_srcdir)/configure.ac am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \ @@ -129,6 +130,7 @@ CYGPATH_W = @CYGPATH_W@ C_INCLUDE_DIR = @C_INCLUDE_DIR@ DEBUG_FLAGS = @DEBUG_FLAGS@ DEFS = @DEFS@ +DYNAMIC_LIST_CPP_NEW_LDFLAGS = @DYNAMIC_LIST_CPP_NEW_LDFLAGS@ ECHO_C = @ECHO_C@ ECHO_N = @ECHO_N@ ECHO_T = @ECHO_T@ @@ -193,6 +195,7 @@ SECTION_LDFLAGS = @SECTION_LDFLAGS@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ STRIP = @STRIP@ +SYMBOLIC_LDFLAGS = @SYMBOLIC_LDFLAGS@ SYMVER_FILE = @SYMVER_FILE@ TOPLEVEL_INCLUDES = @TOPLEVEL_INCLUDES@ USE_NLS = @USE_NLS@ --- gcc/libstdc++-v3/aclocal.m4.symbolic2006-10-17 07:33:04.0 -0700 +++ gcc/libstdc++-v3/aclocal.m4 2007-01-10 10:19:35.0 -0800 @@ -585,6 +585,7 @@ m4_include([../config/lead-dot.m4]) m4_include([../config/multi.m4]) m4_include([../config/no-executables.m4]) m4_include([../config/unwind_ipinfo.m4]) +m4_include([../config/lib-ld.m4]) m4_include([../libtool.m4]) m4_include([crossconfig.m4]) m4_include([linkage.m4]) --- gcc/libstdc++-v3/configure.ac.s
RFC: Add BID as a configure time option for DFP
Both AMD and Intel like to have BID as a configure time option for DFP. Intel is planning to contribute a complete BID runtime library, which can be used by executables generate by gcc. As the first step, we'd like to contribute a BID<->DPD library so that BID can be used with libdecnumber by executables generate by gcc before the complete BID runtime library is ready. Any comments? H.J.
Re: RFC: Add BID as a configure time option for DFP
On Wed, Jan 10, 2007 at 02:10:58PM -0800, Janis Johnson wrote: > On Wed, Jan 10, 2007 at 11:40:46AM -0800, H. J. Lu wrote: > > Both AMD and Intel like to have BID as a configure time option > > for DFP. Intel is planning to contribute a complete BID runtime > > library, which can be used by executables generate by gcc. > > > > As the first step, we'd like to contribute a BID<->DPD library so that > > BID can be used with libdecnumber by executables generate by gcc > > before the complete BID runtime library is ready. > > > > Any comments? > > libdecnumber doesn't use DPD (densely packed decimal), it uses the > decNumber format. Functions in libgcc convert from DPD to decNumber, > call into libdecnumber to do computations, and then convert the result > back to DPD. It's all parameterized in dfp-bit.[ch], so replacing > conversions between decNumber structs and DPD with conversions between > decNumber structs and BID (binary integer decimal) should be > straightforward; I don't think there's any need to convert between BID > and DPD to use libdecnumber. libdecnumber is used by both gcc and DFP executables. We only want to use BID for DFP executables. That means we will need BID<->decNumber for gcc to generate DFP executables which use the BID library. Since the real BID library won't be ready for a while and in the meantime, we like to enable BID for gcc now, that is why we propose the BID<->DPD<->libdecnumber approach as a stopgap measure. We can plug in the real BID library later. > > If all x86* targets will use BID then there's no need for a configure > option. Initial support using DPD for x86* was a proof of concept, I > doubt that anyone would care if you replace it with BID support. Glad to hear that. We can make it BID only for x86. H.J.
Re: PATCH: Build shared libraries with -Bsymbolic-functions
On Thu, Jan 11, 2007 at 09:03:42AM +0100, Paolo Bonzini wrote: > H. J. Lu wrote: > >On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote: > >>>>>>>"H.J." == H J Lu <[EMAIL PROTECTED]> writes: > >>H.J.> With the new linker switches, -Bsymbolic-functions and > >>H.J.> --dynamic-list-cpp-new, we can improve shared library > >>H.J.> performance in gcc. This change will build libstdc++.so with > >>H.J.> -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it > >>H.J.> to other libraries. > >> > >>I prefer to see semi-generic helper code like this in a new .m4 file > >>in config. That makes it somewhat simpler for other target libraries > >>to reuse it. > >> > > > >Here it is. If it is OK, I will extend it to Java and Fortran. > > If the libstdc++ bits are ok, the config bits are ok but please put them > in a new file. lib-ld.m4 is imported from gettext. (And commit the > config part to both gcc and src). > Here is the updated patch. I tested it on Linux/ia32, Linux/x86-64 and Linux/ia64. H.J. config/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * ld-symbolic.m4: New. libgfortran/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * aclocal.m4: Include ../config/lib-ld.m4 and ../config/ld-symbolic.m4. * configure.ac: Use PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libgfortran to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. * Makefile.in: Likewise. libgomp/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * aclocal.m4: Include ../config/lib-ld.m4 and ../config/ld-symbolic.m4. * configure.ac: Use PROG_LD_GNU_SYMBOLIC. Add $SYMBOLIC_LDFLAGS to OPT_LDFLAGS. * configure: Regenerated. * Makefile.in: Likewise. libjava/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * aclocal.m4: Include ../config/ld-symbolic.m4. * configure.ac: Use PROG_LD_GNU_SYMBOLIC. Set libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. * Makefile.in: Likewise. * gcj/Makefile.in: Likewise. * include/Makefile.in: Likewise. * testsuite/Makefile.in: Likewise. libobjc/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * aclocal.m4: Include ../config/lib-ld.m4 and ../config/ld-symbolic.m4. * configure.ac: Use PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libobjc to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. libstdc++-v3/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * aclocal.m4: Include ../config/lib-ld.m4 and ../config/ld-symbolic.m4. * configure.ac: Use PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW. Add $DYNAMIC_LIST_CPP_NEW_LDFLAGS to OPT_LDFLAGS. * configure: Regenerated. * Makefile.in: Likewise. * include/Makefile.in: Likewise. * libmath/Makefile.in: Likewise. * libsupc++/Makefile.in: Likewise. * po/Makefile.in: Likewise. * src/Makefile.in: Likewise. * testsuite/Makefile.in: Likewise. --- gcc/config/ld-symbolic.m4.symbolic 2007-01-11 08:59:04.0 -0800 +++ gcc/config/ld-symbolic.m4 2007-01-11 09:09:54.0 -0800 @@ -0,0 +1,45 @@ +dnl Copyright (C) 2007 Free Software Foundation, Inc. +dnl This file is free software, distributed under the terms of the GNU +dnl General Public License. As a special exception to the GNU General +dnl Public License, this file may be distributed as part of a program +dnl that contains a configuration script generated by Autoconf, under +dnl the same distribution terms as the rest of that program. + +dnl Set SYMBOLIC_LDFLAGS to -Bsymbolic-functions for GNU linker if it +dnl is supported. +AC_DEFUN([PROG_LD_GNU_SYMBOLIC], +[AC_CACHE_CHECK([if the GNU linker ($LD) supports -Bsymbolic-functions], +acl_cv_prog_gnu_ld_symbolic, [ +acl_cv_prog_gnu_ld_symbolic=no +AC_REQUIRE([AC_LIB_PROG_LD_GNU]) +if test x"$with_gnu_ld" = x"yes"; then + if $LD --help 2>&1 &5; then +acl_cv_prog_gnu_ld_symbolic=yes + fi +fi]) +if test x"$acl_cv_prog_gnu_ld_symbolic" = x"yes"; then + SYMBOLIC_LDFLAGS="-Wl,-Bsymbolic-functions" +else + SYMBOLIC_LDFLAGS='' +fi +]) + +dnl Set DYNAMIC_LIST_CPP_NEW_LDFLAGS to --dynamic-list-cpp-new for GNU +dnl linker if it is supported. +AC_DEFUN([PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW], +[AC_CACHE_CHECK([if the GNU linker ($LD) supports --dynamic-list-cpp-new], +acl_cv_prog_gnu_ld_dynamic_list_cpp_new, [ +acl_cv_prog_gnu_ld_dynamic_list_cpp_new=no +AC_REQUIRE([PROG_LD_GNU_SYMBOLIC]) +if test x"$with_gnu_ld" = x"yes" -a \ + x"$acl_cv_prog_gnu_ld_symbolic" = x"yes"; then + if $LD --help 2>&1 &a
Re: PATCH: Build shared libraries with -Bsymbolic-functions
On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote: > > >config/ > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > * ld-symbolic.m4: New. > > Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or > ACX_PROG_LD_GNU_SYMBOLIC. > > >libgfortran/ > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > * aclocal.m4: Include ../config/lib-ld.m4 and > > ../config/ld-symbolic.m4. > > Also, aclocal.m4 is automatically generated with "aclocal -I ../config" > except in libjava. > > > * configure.ac: Use PROG_LD_GNU_SYMBOLIC. Set > > libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set. > > Please check if libgcj_ld_symbolic is now obsolete in > libjava/configure.host. libjava will use -Bsymbolic on Linux, which is more aggresive than -Bsymbol-functions. It will bind global data references locally in additon to global function references. My patch will keep -Bsymbolic for libjava if it is set by libjava/configure.host. Here is an updated patch. H.J. - config/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * ld-symbolic.m4: New. libgfortran/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libgfortran to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. * aclocal.m4: Likewise. * Makefile.in: Likewise. libgomp/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Add $SYMBOLIC_LDFLAGS to OPT_LDFLAGS. * configure: Regenerated. * aclocal.m4: Likewise. * Makefile.in: Likewise. libjava/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. * aclocal.m4: Likewise. * Makefile.in: Likewise. * gcj/Makefile.in: Likewise. * include/Makefile.in: Likewise. * testsuite/Makefile.in: Likewise. libobjc/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libobjc to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. * aclocal.m4: Likewise. libstdc++-v3/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW. Add $DYNAMIC_LIST_CPP_NEW_LDFLAGS to OPT_LDFLAGS. * configure: Regenerated. * aclocal.m4: Likewise. * Makefile.in: Likewise. * include/Makefile.in: Likewise. * libmath/Makefile.in: Likewise. * libsupc++/Makefile.in: Likewise. * po/Makefile.in: Likewise. * src/Makefile.in: Likewise. * testsuite/Makefile.in: Likewise. --- gcc/config/ld-symbolic.m4.symbolic 2007-01-11 08:59:04.0 -0800 +++ gcc/config/ld-symbolic.m4 2007-01-11 09:09:54.0 -0800 @@ -0,0 +1,45 @@ +dnl Copyright (C) 2007 Free Software Foundation, Inc. +dnl This file is free software, distributed under the terms of the GNU +dnl General Public License. As a special exception to the GNU General +dnl Public License, this file may be distributed as part of a program +dnl that contains a configuration script generated by Autoconf, under +dnl the same distribution terms as the rest of that program. + +dnl Set SYMBOLIC_LDFLAGS to -Bsymbolic-functions for GNU linker if it +dnl is supported. +AC_DEFUN([ACX_PROG_LD_GNU_SYMBOLIC], +[AC_CACHE_CHECK([if the GNU linker ($LD) supports -Bsymbolic-functions], +acl_cv_prog_gnu_ld_symbolic, [ +acl_cv_prog_gnu_ld_symbolic=no +AC_REQUIRE([AC_LIB_PROG_LD_GNU]) +if test x"$with_gnu_ld" = x"yes"; then + if $LD --help 2>&1 &5; then +acl_cv_prog_gnu_ld_symbolic=yes + fi +fi]) +if test x"$acl_cv_prog_gnu_ld_symbolic" = x"yes"; then + SYMBOLIC_LDFLAGS="-Wl,-Bsymbolic-functions" +else + SYMBOLIC_LDFLAGS='' +fi +]) + +dnl Set DYNAMIC_LIST_CPP_NEW_LDFLAGS to --dynamic-list-cpp-new for GNU +dnl linker if it is supported. +AC_DEFUN([ACX_PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW], +[AC_CACHE_CHECK([if the GNU linker ($LD) supports --dynamic-list-cpp-new], +acl_cv_prog_gnu_ld_dynamic_list_cpp_new, [ +acl_cv_prog_gnu_ld_dynamic_list_cpp_new=no +AC_REQUIRE([ACX_PROG_LD_GNU_SYMBOLIC]) +if test x"$with_gnu_ld" = x"yes" -a \ + x"$acl_cv_prog_gnu_ld_symbolic" = x"yes"; then + if $LD --help 2>&1 &5; then +acl_cv_prog_gnu_ld_dynamic_list_cpp_new=yes + fi +fi]) +if test x"$acl_cv_prog_gnu_ld_dynamic_list_cpp_new" = x"yes"; then + DYNAMIC_LIST_CPP_NEW_LDFLAGS="$SYMBOLIC_LDFLAGS -Wl,--dynamic-list-cpp-new" +else + DYNAMIC_LIST_CPP_NEW_LDFLAGS='' +fi +]) --- gcc/libgfortran/Makefile.in.symbolic2007-01-09 16:44:22.0 -0800 +++ gcc/libgfortran/Makefile.in 2007-01-11 09:18:37.0 -0800 @@ -47,8 +47,10 @@ subdir = . ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/../config/lead-dot.m4 \ $(top_srcdir)/../config/multi.m4 \ -
Re: PATCH: Build shared libraries with -Bsymbolic-functions
On Fri, Jan 12, 2007 at 08:57:42AM +0100, Paolo Bonzini wrote: > > >libjava will use -Bsymbolic on Linux, which is more aggresive than > >-Bsymbol-functions. It will bind global data references locally in > >additon to global function references. My patch will keep -Bsymbolic > >for libjava if it is set by libjava/configure.host. > > > >Here is an updated patch. > > The configury logic is fine by me, but please wait for approval at least > from the libjava and libstdc++ maintainers since I don't understand > fully the consequences of the -Bsymbolic stuff. Could it be considered > an ABI change, in that programs previously overriding some symbols will > break? (Sorry if the question is dumb). My change should allow programs to override functions which are overridable as specified in language standards. That is why I build libstdc++.so with --dynamic-list-cpp-new so that programs can override C++ operator new/delete. Programs depending on overriding function symbols, which aren't overridable in language standards, are broken. In theory, you can have a huge .o file containing all library functions which aren't overridable in language standard. You won't be able to override any of those functions when that .o file is linked in statically. Since I used -Bsymbolic-functions, it has no effect on data symbols. H.J.
Re: PATCH: Build shared libraries with -Bsymbolic-functions
On Fri, Jan 12, 2007 at 12:13:11PM +, Andrew Haley wrote: > H. J. Lu writes: > > On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote: > > > > > > >config/ > > > > > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > > > > >* ld-symbolic.m4: New. > > > > > > Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or > > > ACX_PROG_LD_GNU_SYMBOLIC. > > > > > > >libgfortran/ > > > > > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > > > > >* aclocal.m4: Include ../config/lib-ld.m4 and > > > >../config/ld-symbolic.m4. > > > > > > Also, aclocal.m4 is automatically generated with "aclocal -I ../config" > > > except in libjava. > > > > > > >* configure.ac: Use PROG_LD_GNU_SYMBOLIC. Set > > > >libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set. > > > > > > Please check if libgcj_ld_symbolic is now obsolete in > > > libjava/configure.host. > > > > libjava will use -Bsymbolic on Linux, which is more aggresive than > > -Bsymbol-functions. > > libjava doesn't use -Bsymbolic for all of its libraries, just for > libgij, libjvm, and libawt. I'd use -Bsymbolic for libgcj as well, > but (because of copy relocs) we'd have to compile all gcj executables > -fpic. > > I presume your patch doesn't change this behaviour. I didn't realized that. I will update my patch to build libgcj with -Bsymbol-functions. You don't need to compile any gcj executables with -fpic. H.J.
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote: > On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote: > >Menezes, Evandro wrote: > >> Though not as pronounced, definitely significant. > >> > > > >Using binary search I've detected that 30% performance regression of > >cpu2006/437.leslie3d benchmark is caused by revision 117891. > > > >http://gcc.gnu.org/viewcvs?view=rev&revision=117891 > > > >I assume same commit causes regression of all other benchmarks from > >cpu2k6 suite (running others to confirm). > > This only affects 4.2, and the only solution would be to try to > backport some of the 4.3 aliasing stuff to 4.2, which i'm not sure is > a great idea. > If this serious performance in gcc 4.2 isn't addressed, it may make gcc 4.2 less attractive since it may generate much slower executables. H.J.
Re: GCC trunk revision 120704 failed to build spec cpu2k/gcc
On Fri, Jan 12, 2007 at 09:30:27PM +0300, Grigory Zagorodnev wrote: > Hi! > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and > higher optimization level at x86_64-redhat-linux. > > reload1.c: In function 'reload': > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > bad_spill_regs > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > bad_spill_regs > > reload1.c:449: internal compiler error: verify_stmts failed > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > > Does anybody see the same? Revision 120685 can compile gcc in SPEC CPU 2006. Grigory, can you back out revision 120695: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00970.html to see if it fixes the regression. H.J.
Re: PATCH: Build shared libraries with -Bsymbolic-functions
On Fri, Jan 12, 2007 at 06:38:56AM -0800, H. J. Lu wrote: > On Fri, Jan 12, 2007 at 08:57:42AM +0100, Paolo Bonzini wrote: > > > > >libjava will use -Bsymbolic on Linux, which is more aggresive than > > >-Bsymbol-functions. It will bind global data references locally in > > >additon to global function references. My patch will keep -Bsymbolic > > >for libjava if it is set by libjava/configure.host. > > > > > >Here is an updated patch. > > > > The configury logic is fine by me, but please wait for approval at least > > from the libjava and libstdc++ maintainers since I don't understand > > fully the consequences of the -Bsymbolic stuff. Could it be considered > > an ABI change, in that programs previously overriding some symbols will > > break? (Sorry if the question is dumb). > > My change should allow programs to override functions which are > overridable as specified in language standards. That is why I build > libstdc++.so with --dynamic-list-cpp-new so that programs can override > C++ operator new/delete. Programs depending on overriding function > symbols, which aren't overridable in language standards, are broken. > In theory, you can have a huge .o file containing all library > functions which aren't overridable in language standard. You > won't be able to override any of those functions when that .o file > is linked in statically. > > Since I used -Bsymbolic-functions, it has no effect on data symbols. > I extended -Bsymbolic-functions to libffi, libjava, libmudflap, libssp and libgcc. There are no regressions: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00511.html http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00510.html http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00509.html If we apply -Bsymbolic-functions to all shared libraries on a system, it will improve application startup time and overall runtime performance. H.J. config/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * ld-symbolic.m4: New. libffi/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * Makefile.am (ACLOCAL_AMFLAGS): Add -I ../config. (libffi_la_LDFLAGS): Add $(extra_ldflags_libffi) * Makefile.in: Regenerated. * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libffi to $SYMBOLIC_LDFLAGS. Substitute extra_ldflags_libffi. * configure: Regenerated. * aclocal.m4: Likewise. libgcc/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * Makefile.in (extra_ldflags_libgcc): New. (SHLIB_LINK): Add $(extra_ldflags_libgcc). * configure.ac: Include ../config/lib-ld.m4 and ../config/ld-symbolic.m4. Usde ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libgcc to $SYMBOLIC_LDFLAGS. Substitute extra_ldflags_libgcc. * configure: Regenerated. libgfortran/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libgfortran to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. * aclocal.m4: Likewise. * Makefile.in: Likewise. libgomp/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Add $SYMBOLIC_LDFLAGS to OPT_LDFLAGS. * configure: Regenerated. * aclocal.m4: Likewise. * Makefile.in: Likewise. libjava/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * Makefile.am (libgcj_la_LDFLAGS): Add $(LIBGCJ_LD_SYMBOLIC_FUNCTIONS). (libgcj_tools_la_LDFLAGS): Likewise. (libgcj_bc_la_LDFLAGS): Likewise. * Makefile.in: Regenerated. * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set LIBGCJ_LD_SYMBOLIC_FUNCTIONS to $SYMBOLIC_LDFLAGS. Set libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set. Substitute LIBGCJ_LD_SYMBOLIC_FUNCTIONS. * configure: Regenerated. * aclocal.m4: Likewise. * gcj/Makefile.in: Likewise. * include/Makefile.in: Likewise. * testsuite/Makefile.in: Likewise. libmudflap/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * Makefile.am (libmudflap_la_LDFLAGS): Add $(extra_ldflags_libmudflap). (libmudflapth_la_LDFLAGS): Likewise. * Makefile.in: Regenerated. * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libmudflap to $SYMBOLIC_LDFLAGS. Substitute extra_ldflags_libmudflap. * configure: Regenerated. * aclocal.m4: Likewise. libobjc/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libobjc to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. * aclocal.m4: Likewise. libssp/ 2007-01-12 H.J. Lu
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
On Fri, Jan 12, 2007 at 02:06:48PM -0500, Daniel Berlin wrote: > On 1/12/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > >On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote: > >> On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]> > >wrote: > >> >Menezes, Evandro wrote: > >> >> Though not as pronounced, definitely significant. > >> >> > >> > > >> >Using binary search I've detected that 30% performance regression of > >> >cpu2006/437.leslie3d benchmark is caused by revision 117891. > >> > > >> >http://gcc.gnu.org/viewcvs?view=rev&revision=117891 > >> > > >> >I assume same commit causes regression of all other benchmarks from > >> >cpu2k6 suite (running others to confirm). > >> > >> This only affects 4.2, and the only solution would be to try to > >> backport some of the 4.3 aliasing stuff to 4.2, which i'm not sure is > >> a great idea. > >> > > > >If this serious performance in gcc 4.2 isn't addressed, it may > >make gcc 4.2 less attractive since it may generate much slower > >executables. > > I'm happy to backport it, but it's going to introduce other possible > problems in 4.2. > It isn't my call. Mark, can you comment on this? Thanks. H.J.
Do we need assemble_external_libcall?
process_pending_assemble_externals will be called at the end, which calls assemble_external_real on all external symbols. Do we still need TARGET_ASM_EXTERNAL_LIBCALL? Why can't assemble_external_real handle it? H.J.
Re: 27% regression of gcc 4.3 performance on cpu2k6/calculix
On Mon, Jan 15, 2007 at 09:47:34PM +0100, Toon Moene wrote: > Grigory, > > Calculix is a combined C/Fortran program. Did you try to compile the > Fortran parts with --param max-aliased-vops= default 50> ? > > Diego up'd the default from 10 to 50 because one (or more) of the > (Fortran) Polyhedron benchmarks showed a dramatic performance regression. > I added --param max-aliased-vops=50 to Fortran. It doesn't make a difference to Calculix. H.J.
Re: Do we need assemble_external_libcall?
On Mon, Jan 15, 2007 at 07:35:22PM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > process_pending_assemble_externals will be called at the end,
> > which calls assemble_external_real on all external symbols.
> > Do we still need TARGET_ASM_EXTERNAL_LIBCALL? Why can't
> > assemble_external_real handle it?
>
> Look at, e.g., mcore_external_libcall in mcore.c, and at
> ASM_OUTPUT_EXTERNAL_LIBCALL in i386/cygming.h. You need to handle
> cases like those somehow. I agree that we could rework the way that
> TARGET_ASM_EXTERNAL_LIBCALL works today, but no matter what you still
> need some way to refer to an external libcall.
TARGET_ASM_EXTERNAL_LIBCALL is a subset of ASM_OUTPUT_EXTERNAL
which is called by assemble_external_real. Why do we need
TARGET_ASM_EXTERNAL_LIBCALL when there is ASM_OUTPUT_EXTERNAL?
---
@defmac ASM_OUTPUT_EXTERNAL (@var{stream}, @var{decl}, @var{name})
A C statement (sans semicolon) to output to the stdio stream
@var{stream} any text necessary for declaring the name of an external
symbol named @var{name} which is referenced in this compilation but
not defined. The value of @var{decl} is the tree node for the
declaration.
This macro need not be defined if it does not need to output anything.
The GNU assembler and most Unix assemblers don't require anything.
@end defmac
@deftypefn {Target Hook} void TARGET_ASM_EXTERNAL_LIBCALL (rtx @var{symref})
This target hook is a function to output to @var{asm_out_file} an assembler
pseudo-op to declare a library function name external. The name of the
library function is given by @var{symref}, which is a @code{symbol_ref}.
@end deftypefn
In fact, ia64 uses ASM_OUTPUT_EXTERNAL and mips uses
TARGET_ASM_EXTERNAL_LIBCALL for generating:
.globl foo
.type foo,...
or
.globl foo .text
for calling external function, foo.
H.J.
Re: Do we need assemble_external_libcall?
On Mon, Jan 15, 2007 at 08:23:05PM -0800, Ian Lance Taylor wrote: > "H. J. Lu" <[EMAIL PROTECTED]> writes: > > > > Look at, e.g., mcore_external_libcall in mcore.c, and at > > > ASM_OUTPUT_EXTERNAL_LIBCALL in i386/cygming.h. You need to handle > > > cases like those somehow. I agree that we could rework the way that > > > TARGET_ASM_EXTERNAL_LIBCALL works today, but no matter what you still > > > need some way to refer to an external libcall. > > > > TARGET_ASM_EXTERNAL_LIBCALL is a subset of ASM_OUTPUT_EXTERNAL > > which is called by assemble_external_real. Why do we need > > TARGET_ASM_EXTERNAL_LIBCALL when there is ASM_OUTPUT_EXTERNAL? > > In the larger scheme of things, we don't. > > At present, in particular, there are targets which implement > TARGET_ASM_EXTERNAL_LIBCALL (or ASM_OUTPUT_EXTERNAL_LIBCALL) but don't > implement ASM_OUTPUT_EXTERNAL, and there are targets which implement > both but implement them differently. Many of those targets, if not all, have TARGET_ASM_FILE_END and/or maintain their own lists of external symbols, which are obsolete with a properly implemented ASM_OUTPUT_EXTERNAL. > > So any attempt at cleaning this up would have to be done very > carefully so as to not break anything. I will open a bug report for enhancement. H.J.
Re: Do we need assemble_external_libcall?
On Mon, Jan 15, 2007 at 08:33:28PM -0800, H. J. Lu wrote: > > > TARGET_ASM_EXTERNAL_LIBCALL when there is ASM_OUTPUT_EXTERNAL? > > > > In the larger scheme of things, we don't. > > > I will open a bug report for enhancement. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30480 H.J.
C Parser
Hi all, I was quite surprised to see that the C Parser was manually implemented and you didn't use any parser generator. I would be curious regarding this decision. I would think the development of a C parser would be an almost unsurmountable task and not very logic given the parser generators in existence today. Can someone comment this? (which issues led to this decision?) Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Where the languages meet...
Hello all, After reading the internals of gcc wikibooks some questions come up. So, gcc has front end for C, C++, java, fortran, etc.. All these languages have a frontend which parse into AST and then GIMPLE which is converted to RTX and then assembly. Now, my guess is that GIMPLE is the _common_ ground for all languages. No matter which language, all will go through GIMPLE, so if I wished to implement some language analysis / optimizations, I should do it in GIMPLE to be able to implement in one go the optimization for all languages, right? Is there any formal syntax/semantics for GIMPLE? Or the SIMPLE paper is the only thing with this stuff? Any reference to the differences between GIMPLE and SIMPLE? Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Dumping gimple tree
Hello, from "GENERIC and GIMPLE: A New Tree Representation for Entire Functions" by Jason Merrill it says there's a flag -fdump-tree-simple to get the gimple tree (page 3). However, this doesn't exist in gcc 4.1: $ gcc -fdump-tree-simple bigger3.c cc1: error: unrecognized command line option "-fdump-tree-simple" Is there anything similar for gcc4.1? Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Dumping gimple tree
Argh, forget it! Found the answer in: http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Debugging-Options.html#Debugging-Options Regards, Paulo Matos On 1/18/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote: Hello, from "GENERIC and GIMPLE: A New Tree Representation for Entire Functions" by Jason Merrill it says there's a flag -fdump-tree-simple to get the gimple tree (page 3). However, this doesn't exist in gcc 4.1: $ gcc -fdump-tree-simple bigger3.c cc1: error: unrecognized command line option "-fdump-tree-simple" Is there anything similar for gcc4.1? Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Where the languages meet...
On 18 Jan 2007 07:42:38 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "Paulo J. Matos" <[EMAIL PROTECTED]> writes: > After reading the internals of gcc wikibooks some questions come up. > So, gcc has front end for C, C++, java, fortran, etc.. > All these languages have a frontend which parse into AST and then > GIMPLE which is converted to RTX and then assembly. Now, my guess is > that GIMPLE is the _common_ ground for all languages. No matter which > language, all will go through GIMPLE, so if I wished to implement some > language analysis / optimizations, I should do it in GIMPLE to be able > to implement in one go the optimization for all languages, right? Yes. > Is there any formal syntax/semantics for GIMPLE? Or the SIMPLE paper > is the only thing with this stuff? Any reference to the differences > between GIMPLE and SIMPLE? GIMPLE is more-or-less documented in the gcc internals manual. Ian Many thanks for the concise, direct answer. Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: 27% regression of gcc 4.3 performance on cpu2k6/calculix
On Tue, Jan 16, 2007 at 07:05:34PM +0300, Grigory Zagorodnev wrote: > Toon Moene wrote: > >Calculix is a combined C/Fortran program. Did you try to compile the > >Fortran parts with --param max-aliased-vops= >default 50> ? > Right, calculix is a combined program. Gprof says the regression is in > e_c3d routine which is 1k lines of Fortran code. > > Various max-aliased-vops give no difference for calculix: > Is that possible to extract a smaller testcase? H.J.
