Re: Mis-handled ColdFire submission?
Thanks to everyone for the feedback. I just wanted to apologise for something that Eric brought up... Eric Botcazou <[EMAIL PROTECTED]> writes: >> I know Andrew replied privately, but I hope he doesn't mind me raising >> the issue on-list. I just wanted to guage the general feeling as to >> whether I'd screwed up, and whether I should have submitted the patches >> in a different way. > > The only problem I personally have is that you apparently successively > replied > to the previous post, which means that all the patches are tied to a single > gigantic thread in my mailer. :-( Yeah, sorry about that. I'd wanted to keep all the messages in the same thread so that folks could kill the thread in one go if they weren't interested. But what I should have done was make each patch a reply to the introductory message instead. So that's one lesson learnt. Richard
Re: PATCH: Build shared libraries with -Bsymbolic-functions
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). Paolo
Re: Making gcc read from the standard input
Tathagato Rai Dastidar wrote: Hello, Is there a way I can make GCC read a C or C++ code from the standard input instead of from a file? In my application software, I am generating some C code on the fly, writing it to a file, then using GCC to compile it. Instead of that, I want to invoke GCC through a pipe, and write the C code directly into GCC, instead of writing it into a file and then calling GCC. Is this possible? This is a question only for gcc-help. Cross-posting gcc and gcc-help is almost always wrong. :-) But yes, it is possible by adding "-x c" to the command line, so that the gcc driver knows which front-end to invoke. In the case of "-E", in fact, GCC implicitly considers the language to be C (and invokes the C front-end) because the preprocessor is the same for all input languages; but for real compilation, you need to specify the language manually. HTH, Paolo
Re: Fwd: Re: gcc 4.1.1 for mcore
Hi Alex, Right - you should be able to build the MCore port now. At least as far as newlib/libgloss/libiberty anyway. libstdc++-v3 does not build at the moment due to a problem unrelated to the 64-bit build OS issue, but I assume that this does not bother you. (You will need the latest gcc and binutils sources for this...) Cheers Nick
Re: Mis-handled ColdFire submission?
Mike Stump writes: > On Jan 10, 2007, at 1:13 PM, Richard Sandiford wrote: > > I just wanted to guage the general feeling as to whether I'd > > screwed up, and whether I should have submitted the patches in a > > different way. > > I don't see a trivial way that is strictly better. The problem is > that some folks don't want the huge patch and some folks don't like > the spray of 60. Hard to please both at once. One strategy that > might be better would be to do them up on a development branch and > submit one patch at a time as you develop them and then when all is > said and done and all reviewed and approved, just merge it in. That's what I had in mind, yes. Develop a patch, test it, post it to list, commit to branch. Write the next patch, etc. Work in public, not in private. Unless there's some reason to hold a patch back, I can't see any reason not to post and commit a patch as soon as it's written and tested. > I'm used to this style from the Ada folks That style from the Ada folks tends to exclude other developers. Andrew.
Re: Tricky(?) aliasing question.
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Sergei Organov <[EMAIL PROTECTED]> writes:
>
>> Below are two example functions foo() and boo(), that I think both are
>> valid from the POV of strict aliasing rules. GCC 4.2 either warns about
>> both (with -Wstrict-aliasing=2) or doesn't warn about any (with
>> -Wstrict-aliasing), and generates the assembly as if the functions don't
>> violate the rules, i.e, both functions return 10.
>
> -Wstrict-aliasing=2 is documented to return false positives. Actually
> both current versions of -Wstrict-aliasing are pretty bad.
Well, they are indeed bad, but on the other hand I fail to see how to
make them pretty without analyzing the entire source of a program, and
even then the "effective type of an object" could change at run-time :(
Overall, I tend to refrain from blaming gcc too much for weakness of
these warnings.
>> $ cat alias.c
>> typedef struct { int i; } S;
>>
>> int i;
>> int foo()
>> {
>> S const sc = { 10 };
>> i = 20;
>> // Accessing object 'i' of type 'int' through 'S' containing 'int'
>> // field. Should be OK from C99 standard POV?
>> *(S*)&i = sc;
>
> C99 says that you can access an object via "an aggregate or union type
> that includes one of the aforementioned [basically, compatible] types
> among its members (including, recursively, a member of a subaggregate
> or contained union)" (section 6.5, paragraph 7). So on that basis
> this looks OK to me.
Yes, it looked OK due to that rule to me too, until I just came up with
the following example in which either I've finally violated some rule,
or GCC miscompiles the code:
$cat alias3.c
typedef struct {
int i;
float f;
} H0;
typedef struct {
float f;
int i;
} H1;
H1 h1 = { 0, 10 };
int float_as_int() __attribute__((noinline));
int float_as_int()
{
h1.f = 1;
H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
return h0.i;
}
#include
int main()
{
printf("%#x\n", float_as_int());
printf("%#x\n", float_as_int());
}
$ gcc-4.1 -W -Wstrict-aliasing -O3 alias3.c -o alias3
$ ./alias3
0
0x3f80
$
Any comments?
>
>> S s;
>> int boo()
>> {
>> s.i = 20;
>> // Accessing 's' of type 'S' through 'int'. Is it aliasing rules
>> // violation? Maybe yes, but on the other hand this could be
>> // considered as accessing 's.i' of type 'int' through 'int' that
>> // should be OK from C99 standard POV?
>> *(int*)&s = 10;
>> return s.i;
>> }
>
> I think this should also be OK.
>
> The main point is that you are accessing the object with the correct
> type (int).
Yes, I hoped it is so, my doubt was that C99 defines "effective type" of
an object to be "its declared type", and "declared type" of object 's'
is obviously 'S' in this example, but from the standard itself it was
not entirely clear for me that an address in memory could have multiple
effective types associated with it at the same time.
> The use of the struct wrapper does not change that. If
> you used a struct for which the type of the field was not the same as
> the type of the variable, then this usage would be an aliasing
> violation.
These are good news. In fact this particular function arose from a
doubt if it's possible to achieve C++-alike inheritance in C99 and still
write aliasing-clean code when accessing "derived" object through a
pointer to its "base" type.
Now my next doubt will be if it's possible to implement free() in C99 as
there seems to be no way to "forget" the effective object type of a
dynamically allocated object. ;)
>
> It is possible that somebody else will disagree with me.
Hopefully not, and thank you very much for the answers.
-- Sergei.
Re: Tricky(?) aliasing question.
Sergei Organov writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > Sergei Organov <[EMAIL PROTECTED]> writes:
> >
>
> >> $ cat alias.c
> >> typedef struct { int i; } S;
> >>
> >> int i;
> >> int foo()
> >> {
> >> S const sc = { 10 };
> >> i = 20;
> >> // Accessing object 'i' of type 'int' through 'S' containing 'int'
> >> // field. Should be OK from C99 standard POV?
> >> *(S*)&i = sc;
> >
> > C99 says that you can access an object via "an aggregate or union type
> > that includes one of the aforementioned [basically, compatible] types
> > among its members (including, recursively, a member of a subaggregate
> > or contained union)" (section 6.5, paragraph 7). So on that basis
> > this looks OK to me.
>
> Yes, it looked OK due to that rule to me too, until I just came up with
> the following example in which either I've finally violated some rule,
> or GCC miscompiles the code:
>
> $cat alias3.c
> typedef struct {
> int i;
> float f;
> } H0;
>
> typedef struct {
> float f;
> int i;
> } H1;
>
> H1 h1 = { 0, 10 };
>
> int float_as_int() __attribute__((noinline));
> int float_as_int()
> {
> h1.f = 1;
> H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
I don't think this is OK. Per C99, you can cast to the element type
from the struct or vice versa, but you can't cast from one struct type
to another via the first element. If this were possible, every struct
type that started with an int would be in a single alias set.
Andrew.
Re: Tricky(?) aliasing question.
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > Sergei Organov <[EMAIL PROTECTED]> writes:
> > >
> >
> > >> $ cat alias.c
> > >> typedef struct { int i; } S;
> > >>
> > >> int i;
> > >> int foo()
> > >> {
> > >> S const sc = { 10 };
> > >> i = 20;
> > >> // Accessing object 'i' of type 'int' through 'S' containing 'int'
> > >> // field. Should be OK from C99 standard POV?
> > >> *(S*)&i = sc;
> > >
> > > C99 says that you can access an object via "an aggregate or union type
> > > that includes one of the aforementioned [basically, compatible] types
> > > among its members (including, recursively, a member of a subaggregate
> > > or contained union)" (section 6.5, paragraph 7). So on that basis
> > > this looks OK to me.
> >
> > Yes, it looked OK due to that rule to me too, until I just came up with
> > the following example in which either I've finally violated some rule,
> > or GCC miscompiles the code:
> >
> > $cat alias3.c
> > typedef struct {
> > int i;
> > float f;
> > } H0;
> >
> > typedef struct {
> > float f;
> > int i;
> > } H1;
> >
> > H1 h1 = { 0, 10 };
> >
> > int float_as_int() __attribute__((noinline));
> > int float_as_int()
> > {
> > h1.f = 1;
> > H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
>
> I don't think this is OK. Per C99, you can cast to the element type
> from the struct or vice versa, but you can't cast from one struct type
> to another via the first element.
There is no word "casting" in the definition of the aliasing rules in
C99. It talks about accessing of object through an lvalue of compatible
type. In this example I access stored value of object "h1.f" of type
"float" through an lvalue of type "H0" that is an aggregate type that
includes "float" (a type compatible with the effective type of the
object) among its members. That IMHO should be OK from C99
aliasing rules POV.
> If this were possible, every struct type that started with an int
> would be in a single alias set.
How else should I interpret these C99 wordings (re-citing again):
An object shall have its stored value accessed only by an lvalue
expression that has one of the following types: {footnote 73}
- a type compatible with the effective type of the object,
[...]
- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union)
-- Sergei.
Re: Tricky(?) aliasing question.
Sergei Organov writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Sergei Organov writes:
> > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > Sergei Organov <[EMAIL PROTECTED]> writes:
> > > >
> > > int float_as_int()
> > > {
> > > h1.f = 1;
> > > H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
> >
> > I don't think this is OK. Per C99, you can cast to the element type
> > from the struct or vice versa, but you can't cast from one struct type
> > to another via the first element.
>
> There is no word "casting" in the definition of the aliasing rules in
> C99. It talks about accessing of object through an lvalue of compatible
> type. In this example I access stored value of object "h1.f"
No, that's not what the code above does. You're accessing an object
of type h1 through an lvalue of type h0. Accessing h1.f would have
been perfectly OK, but that's not what the code above does.
Look at it again:
H0 h0 = *(H0*)&h1.f;
The LHS of this assignment is of type h0. The RHS is an object of
effective type h1. The fact that you're going via a pointer cast to
its first member is neither here nor there.
> of type "float" through an lvalue of type "H0" that is an aggregate
> type that includes "float" (a type compatible with the effective
> type of the object) among its members. That IMHO should be OK from
> C99 aliasing rules POV.
No. You can only access an object through an lvalue of compatible
type. In this case you're accessing an object of type h1 through an
lvalue of type h0.
> > If this were possible, every struct type that started with an int
> > would be in a single alias set.
>
> How else should I interpret these C99 wordings (re-citing again):
>
> An object shall have its stored value accessed only by an lvalue
> expression that has one of the following types: {footnote 73}
>
> - a type compatible with the effective type of the object,
> [...]
> - an aggregate or union type that includes one of the aforementioned
>types among its members (including, recursively, a member of a
>subaggregate or contained union)
And this is neither.
Andrew.
Re: Tricky(?) aliasing question.
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > Sergei Organov writes:
> > > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > > Sergei Organov <[EMAIL PROTECTED]> writes:
> > > > >
>> > > int float_as_int()
> > > > {
> > > > h1.f = 1;
> > > > H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
> > >
> > > I don't think this is OK. Per C99, you can cast to the element type
> > > from the struct or vice versa, but you can't cast from one struct type
> > > to another via the first element.
> >
> > There is no word "casting" in the definition of the aliasing rules in
> > C99. It talks about accessing of object through an lvalue of compatible
> > type. In this example I access stored value of object "h1.f"
>
> No, that's not what the code above does. You're accessing an object
> of type h1 through an lvalue of type h0. Accessing h1.f would have
> been perfectly OK, but that's not what the code above does.
>
> Look at it again:
>
>H0 h0 = *(H0*)&h1.f;
>
> The LHS of this assignment is of type h0.
Yes.
> The RHS is an object of effective type h1. The fact that you're going
> via a pointer cast to its first member is neither here nor there.
So "h1.f" is not an object? If it is not, it brings us back to the
validity of my boo() function from the initial post, for which 2 persons
(3 including me) thought it's OK:
S s;
int boo()
{
s.i = 20;
// Accessing 's' of type 'S' through 'int'. Is it aliasing rules
// violation? Maybe yes, but on the other hand this could be
// considered as accessing 's.i' of type 'int' through 'int' that
// should be OK from C99 standard POV?
*(int*)&s = 10;
return s.i;
}
Do you think this one is OK then?
Anyway, I can rewrite the float_as_int() so that it will access plain
float f:
float f;
int float_as_int()
{
h1.f = 1;
H0 h0 = *(H0*)&f; // Should be OK? No, it is not?!
return h0.i;
}
Does it change anything in your reasoning?
-- Sergei.
Re: Tricky(?) aliasing question.
Sergei Organov writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Sergei Organov writes:
> > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > >
> > > > Sergei Organov writes:
> > > > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > > > Sergei Organov <[EMAIL PROTECTED]> writes:
> > > > > >
> >> > > int float_as_int()
> > > > > {
> > > > > h1.f = 1;
> > > > > H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
> > > >
> > > > I don't think this is OK. Per C99, you can cast to the element type
> > > > from the struct or vice versa, but you can't cast from one struct type
> > > > to another via the first element.
> > >
> > > There is no word "casting" in the definition of the aliasing rules in
> > > C99. It talks about accessing of object through an lvalue of compatible
> > > type. In this example I access stored value of object "h1.f"
> >
> > No, that's not what the code above does. You're accessing an object
> > of type h1 through an lvalue of type h0. Accessing h1.f would have
> > been perfectly OK, but that's not what the code above does.
> >
> > Look at it again:
> >
> >H0 h0 = *(H0*)&h1.f;
> >
> > The LHS of this assignment is of type h0.
>
> Yes.
>
> > The RHS is an object of effective type h1. The fact that you're going
> > via a pointer cast to its first member is neither here nor there.
>
> So "h1.f" is not an object?
This is too silly for words.
> If it is not, it brings us back to the validity of my boo()
> function from the initial post, for which 2 persons (3 including
> me) thought it's OK:
>
> S s;
> int boo()
> {
> s.i = 20;
> // Accessing 's' of type 'S' through 'int'. Is it aliasing rules
> // violation? Maybe yes, but on the other hand this could be
> // considered as accessing 's.i' of type 'int' through 'int' that
> // should be OK from C99 standard POV?
> *(int*)&s = 10;
> return s.i;
> }
>
> Do you think this one is OK then?
Yes. The standard says it's OK.
You can convert a pointer to a struct to the type of its first member,
and back to a pointer to the original struct and the pointer will
still be valid. What you can't do is use that converted pointer to
access an object of incompatible type.
> Anyway, I can rewrite the float_as_int() so that it will access plain
> float f:
>
> float f;
> int float_as_int()
> {
> h1.f = 1;
> H0 h0 = *(H0*)&f; // Should be OK? No, it is not?!
No. The types have to be compatible. If f were of type h0, this
would be OK. But f is of type float, so it isn't.
> return h0.i;
> }
>
> Does it change anything in your reasoning?
No.
Andrew.
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
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). - Grigory
Re: Tricky(?) aliasing question.
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > Sergei Organov writes:
> > > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > > >
> > > > > Sergei Organov writes:
> > > > > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > > > > Sergei Organov <[EMAIL PROTECTED]> writes:
> > > > > > >
> > >> > > int float_as_int()
> > > > > > {
> > > > > > h1.f = 1;
> > > > > > H0 h0 = *(H0*)&h1.f; // Should be OK? No, it is not?!
> > > > >
> > > > > I don't think this is OK. Per C99, you can cast to the element type
> > > > > from the struct or vice versa, but you can't cast from one struct
> type
> > > > > to another via the first element.
> > > >
> > > > There is no word "casting" in the definition of the aliasing rules in
> > > > C99. It talks about accessing of object through an lvalue of
> compatible
> > > > type. In this example I access stored value of object "h1.f"
> > >
> > > No, that's not what the code above does. You're accessing an object
> > > of type h1 through an lvalue of type h0. Accessing h1.f would have
> > > been perfectly OK, but that's not what the code above does.
> > >
> > > Look at it again:
> > >
> > >H0 h0 = *(H0*)&h1.f;
> > >
> > > The LHS of this assignment is of type h0.
> >
> > Yes.
> >
> > > The RHS is an object of effective type h1. The fact that you're going
> > > via a pointer cast to its first member is neither here nor there.
> >
> > So "h1.f" is not an object?
>
> This is too silly for words.
Sorry, I don't understand the meaning of this phrase. I thought I have
accessed object "h1.f" of type float. Didn't I? Anyway, this is not that
essential for the discussion, provided accessing bare float variable is
not permitted in your opinion as well.
> > If it is not, it brings us back to the validity of my boo()
> > function from the initial post, for which 2 persons (3 including
> > me) thought it's OK:
> >
> > S s;
> > int boo()
> > {
> > s.i = 20;
> > // Accessing 's' of type 'S' through 'int'. Is it aliasing rules
> > // violation? Maybe yes, but on the other hand this could be
> > // considered as accessing 's.i' of type 'int' through 'int' that
> > // should be OK from C99 standard POV?
> > *(int*)&s = 10;
> > return s.i;
> > }
> >
> > Do you think this one is OK then?
>
> Yes. The standard says it's OK.
OK, I think I see your point here. Due to the fact that 'S', as
declared, has the first field of type 'int', the 'S' and 'int' types are
compatible, so I simply access stored value of the object 's' through a
compatible type 'int', right?
> > Anyway, I can rewrite the float_as_int() so that it will access plain
> > float f:
> >
> > typedef struct {
> > int i;
> > float f;
> > } H0;
> >
> > float f;
> > int float_as_int()
> > {
> > f = 1;
> > H0 h0 = *(H0*)&f; // Should be OK? No, it is not?!
>
> No. The types have to be compatible. If f were of type h0, this
> would be OK. But f is of type float, so it isn't.
I agree the types 'H0' and 'float' are not compatible types. But the
question is not about compatibility of types, -- the question is about
violation (or not) of strict aliasing rules.
If we come back to strict aliasing rules, then I will have to refer once
again to already cited place in the standard that says that I'm
permitted to access an object not only through a compatible type, but
also through a structure containing a field of compatible type (and
there is no indication that those field should be the first one in the
structure):
An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:
- a type compatible with the effective type of the object,
[...]
- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union)
Or are you saying that I don't violate strict aliasing rules, but
instead some other rule from the standard? If so, then how to explain
that GCC stops to "miscompile" the code when I add -fno-strict-aliasing
option? Not that I insist on sane results of compilation of broken code,
but it seems that GCC thinks it's violation of strict aliasing rules.
-- Sergei.
Re: Tricky(?) aliasing question.
Sergei Organov writes: > If we come back to strict aliasing rules, then I will have to refer once > again to already cited place in the standard that says that I'm > permitted to access an object not only through a compatible type, but > also through a structure containing a field of compatible type (and > there is no indication that those field should be the first one in the > structure): > >An object shall have its stored value accessed only by an lvalue >expression that has one of the following types: > > - a type compatible with the effective type of the object, > [...] > - an aggregate or union type that includes one of the aforementioned > types among its members (including, recursively, a member of a > subaggregate or contained union) > > Or are you saying that I don't violate strict aliasing rules, but > instead some other rule from the standard? If so, then how to explain > that GCC stops to "miscompile" the code when I add -fno-strict-aliasing > option? That's what it's for. -fno-strict-aliasing exists to support such broken code. > Not that I insist on sane results of compilation of broken code, > but it seems that GCC thinks it's violation of strict aliasing > rules. 6.3.2.3 makes it quite clear that this: H0 h0 = *(H0*)&f; produces undefined behaviour. Andrew.
Re: Tricky(?) aliasing question.
On Jan 11, 2007, at 6:30 AM, Sergei Organov wrote: So "h1.f" is not an object? If it is not, it brings us back to the validity of my boo() function from the initial post, for which 2 persons (3 including me) thought it's OK: Would be nice for you to raise the issue directly with the C standards committee... Would be nice to see them improve the wording in the tricky corners.
Re: Tricky(?) aliasing question.
Andrew Haley <[EMAIL PROTECTED]> writes: > Sergei Organov writes: > > > If we come back to strict aliasing rules, then I will have to refer once > > again to already cited place in the standard that says that I'm > > permitted to access an object not only through a compatible type, but > > also through a structure containing a field of compatible type (and > > there is no indication that those field should be the first one in the > > structure): > > > >An object shall have its stored value accessed only by an lvalue > >expression that has one of the following types: > > > > - a type compatible with the effective type of the object, > > [...] > > - an aggregate or union type that includes one of the aforementioned > > types among its members (including, recursively, a member of a > > subaggregate or contained union) > > > > Or are you saying that I don't violate strict aliasing rules, but > > instead some other rule from the standard? If so, then how to explain > > that GCC stops to "miscompile" the code when I add -fno-strict-aliasing > > option? > > That's what it's for. -fno-strict-aliasing exists to support such > broken code. Could you please give direct answer to the following question: Does the code in question violate strict aliasing rules? > > > Not that I insist on sane results of compilation of broken code, > > but it seems that GCC thinks it's violation of strict aliasing > > rules. > > 6.3.2.3 makes it quite clear that this: > >H0 h0 = *(H0*)&f; > > produces undefined behaviour. What it has to do with strict aliasing rules? Anyway, the only undefined behavior in this section I've found is: "7. A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned(57) for the pointed-to type, the behavior is undefined." Let's suppose that in my example the alignment requirements for 'float' and 'H0' types are the same. Then the cited item (7) allows me to convert float* to/from H0* without invoking of undefined behavior. Did I miss anything? -- Sergei.
Re: Tricky(?) aliasing question.
Mike Stump <[EMAIL PROTECTED]> writes: > On Jan 11, 2007, at 6:30 AM, Sergei Organov wrote: >> So "h1.f" is not an object? If it is not, it brings us back to the >> validity of my boo() function from the initial post, for which 2 >> persons >> (3 including me) thought it's OK: > > Would be nice for you to raise the issue directly with the C standards > committee... Would be nice to see them improve the wording in the > tricky corners. Actually, this particular issue (the boo() validity) is gone, I think, as Andrew explained it quite clear, at least for me. On the other hand, I have no doubts that "h1.f" is an object by definition: "object: region of data storage in the execution environment, the contents of which can represent values" BTW, I've tried once to raise similar aliasing question in comp.std.c++. The result was that somebody started to talk about validity of pointers conversions that IMHO has nothing to do with strict aliasing, and the discussion died. -- Sergei.
Re: Tricky(?) aliasing question.
Sergei Organov writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > Sergei Organov writes: > > > > > If we come back to strict aliasing rules, then I will have to refer once > > > again to already cited place in the standard that says that I'm > > > permitted to access an object not only through a compatible type, but > > > also through a structure containing a field of compatible type (and > > > there is no indication that those field should be the first one in the > > > structure): > > > > > >An object shall have its stored value accessed only by an lvalue > > >expression that has one of the following types: > > > > > > - a type compatible with the effective type of the object, > > > [...] > > > - an aggregate or union type that includes one of the > > aforementioned > > > types among its members (including, recursively, a member of a > > > subaggregate or contained union) > > > > > > Or are you saying that I don't violate strict aliasing rules, but > > > instead some other rule from the standard? If so, then how to explain > > > that GCC stops to "miscompile" the code when I add -fno-strict-aliasing > > > option? > > > > That's what it's for. -fno-strict-aliasing exists to support such > > broken code. > > Could you please give direct answer to the following question: > > Does the code in question violate strict aliasing rules? Yes. > > > Not that I insist on sane results of compilation of broken code, > > > but it seems that GCC thinks it's violation of strict aliasing > > > rules. > > > > 6.3.2.3 makes it quite clear that this: > > > >H0 h0 = *(H0*)&f; > > > > produces undefined behaviour. > > What it has to do with strict aliasing rules? The strict aliasing rues, are, in part, defined by Section 6.3.2.3. > Anyway, the only undefined behavior in this section I've found is: > > "7. A pointer to an object or incomplete type may be converted to a > pointer to a different object or incomplete type. If the resulting > pointer is not correctly aligned(57) for the pointed-to type, the > behavior is undefined." > > Let's suppose that in my example the alignment requirements for 'float' > and 'H0' types are the same. Then the cited item (7) allows me to > convert float* to/from H0* without invoking of undefined behavior. This is the relevant language, in whole: "A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned 57) for the pointed-to type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer." Note that you do not have permission to do anything with the converted pointer _except_ convert it back to the original pointer; everything else is undefined. You certainly may not use the converted pointer to create an lvalue. Andrew.
Re: Tricky(?) aliasing question.
Sergei Organov writes: > > BTW, I've tried once to raise similar aliasing question in > comp.std.c++. The result was that somebody started to talk about > validity of pointers conversions that IMHO has nothing to do with > strict aliasing, It's the same issue. > and the discussion died. It is relevant to comp.std.c++. It is not relevant to this list. We're now way off-topic, so I'm leaving this discussion. Andrew.
Re: Tricky(?) aliasing question.
Sergei Organov wrote: Ian Lance Taylor <[EMAIL PROTECTED]> writes: Sergei Organov <[EMAIL PROTECTED]> writes: Below are two example functions foo() and boo(), that I think both are valid from the POV of strict aliasing rules. GCC 4.2 either warns about both (with -Wstrict-aliasing=2) or doesn't warn about any (with -Wstrict-aliasing), and generates the assembly as if the functions don't violate the rules, i.e, both functions return 10. -Wstrict-aliasing=2 is documented to return false positives. Actually both current versions of -Wstrict-aliasing are pretty bad. Well, they are indeed bad, but on the other hand I fail to see how to make them pretty without analyzing the entire source of a program, and even then the "effective type of an object" could change at run-time :( Overall, I tend to refrain from blaming gcc too much for weakness of these warnings. The current implementation of -Wstrict-aliasing runs in the C front end and looks at a single expression at once. Although I think it does OK given the limited scope, it has several drawbacks. First, it produces false positives, i.e., it warns when it should not. For instance, it warns about pointer conversions even when the pointers are not dereferenced. Second, it produces false negatives, i.e., it does not warn when it should. For instance, aliases to malloc-ed memory are not detected, among others. Third, it only checks C programs (and not C++). I am about to submit a patch that implements -Wstrict-aliasing in the backend based on flow-sensitive points-to information, which is computed by analyzing the entire source of each function. It is not perfect (the problem is undecidable), but it improves in all three directions: it checks whether pointers get dereferenced, it detects cross-type aliasing in heap (and other multiple statements situations) and it works on both C and C++. Silvius
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 &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 +++
Re: Tricky(?) aliasing question.
Silvius Rus <[EMAIL PROTECTED]> writes: [...] > I am about to submit a patch that implements -Wstrict-aliasing in the > backend based on flow-sensitive points-to information, which is > computed by analyzing the entire source of each function. It is not > perfect (the problem is undecidable), but it improves in all three > directions: it checks whether pointers get dereferenced, it detects > cross-type aliasing in heap (and other multiple statements situations) > and it works on both C and C++. That will be really *great* improvement over the current situation when those warnings are more annoying than helpful in most cases! -- Sergei.
Re: Tricky(?) aliasing question.
> > Sergei Organov wrote: > > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > >> Sergei Organov <[EMAIL PROTECTED]> writes: > >> > >> > >>> Below are two example functions foo() and boo(), that I think both are > >>> valid from the POV of strict aliasing rules. GCC 4.2 either warns about > >>> both (with -Wstrict-aliasing=2) or doesn't warn about any (with > >>> -Wstrict-aliasing), and generates the assembly as if the functions don't > >>> violate the rules, i.e, both functions return 10. > >>> > >> -Wstrict-aliasing=2 is documented to return false positives. Actually > >> both current versions of -Wstrict-aliasing are pretty bad. > >> > > > > Well, they are indeed bad, but on the other hand I fail to see how to > > make them pretty without analyzing the entire source of a program, and > > even then the "effective type of an object" could change at run-time :( > > Overall, I tend to refrain from blaming gcc too much for weakness of > > these warnings. > > > > > Third, it only checks C programs (and not C++). This has not been true for some time now (at least developmental wise). -- Pinski
Re: Tricky(?) aliasing question.
Andrew Haley <[EMAIL PROTECTED]> writes: > Sergei Organov writes: > > > > BTW, I've tried once to raise similar aliasing question in > > comp.std.c++. The result was that somebody started to talk about > > validity of pointers conversions that IMHO has nothing to do with > > strict aliasing, > > It's the same issue. > > > and the discussion died. > > It is relevant to comp.std.c++. It is not relevant to this list. > We're now way off-topic, so I'm leaving this discussion. Well, is adhering of GCC to the C99 standard is indeed off-topic here? If so, I'd leave the discussion as well. Where should I discuss it then? Obviously not in comp.std.c++. -- Sergei.
Re: Tricky(?) aliasing question.
Andrew Haley <[EMAIL PROTECTED]> writes: > Sergei Organov writes: > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > Sergei Organov writes: > > > > > > > If we come back to strict aliasing rules, then I will have to refer > once > > > > again to already cited place in the standard that says that I'm > > > > permitted to access an object not only through a compatible type, but > > > > also through a structure containing a field of compatible type (and > > > > there is no indication that those field should be the first one in the > > > > structure): > > > > > > > >An object shall have its stored value accessed only by an lvalue > > > >expression that has one of the following types: > > > > > > > > - a type compatible with the effective type of the object, > > > > [...] > > > > - an aggregate or union type that includes one of the > aforementioned > > > > types among its members (including, recursively, a member of a > > > > subaggregate or contained union) > > > > > > > > Or are you saying that I don't violate strict aliasing rules, but > > > > instead some other rule from the standard? If so, then how to explain > > > > that GCC stops to "miscompile" the code when I add > -fno-strict-aliasing > > > > option? > > > > > > That's what it's for. -fno-strict-aliasing exists to support such > > > broken code. > > > > Could you please give direct answer to the following question: > > > > Does the code in question violate strict aliasing rules? > > Yes. > > > > > Not that I insist on sane results of compilation of broken code, > > > > but it seems that GCC thinks it's violation of strict aliasing > > > > rules. > > > > > > 6.3.2.3 makes it quite clear that this: > > > > > >H0 h0 = *(H0*)&f; > > > > > > produces undefined behaviour. > > > > What it has to do with strict aliasing rules? > > The strict aliasing rues, are, in part, defined by Section 6.3.2.3. Really? Is it your interpretation, or is it written in the standard somewhere? > > > Anyway, the only undefined behavior in this section I've found is: > > > > "7. A pointer to an object or incomplete type may be converted to a > > pointer to a different object or incomplete type. If the resulting > > pointer is not correctly aligned(57) for the pointed-to type, the > > behavior is undefined." > > > > Let's suppose that in my example the alignment requirements for 'float' > > and 'H0' types are the same. Then the cited item (7) allows me to > > convert float* to/from H0* without invoking of undefined behavior. > > This is the relevant language, in whole: > > "A pointer to an object or incomplete type may be converted to a > pointer to a different object or incomplete type. If the resulting > pointer is not correctly aligned 57) for the pointed-to type, the > behavior is undefined. Otherwise, when converted back again, the > result shall compare equal to the original pointer." > > Note that you do not have permission to do anything with the converted > pointer _except_ convert it back to the original pointer; everything > else is undefined. You certainly may not use the converted pointer to > create an lvalue. Uh, in my reading the above citation says absolutely nothing about what happens if I *access* something with converted pointer. Suppose for a moment that your reading is correct. Why the entire section about strict aliasing is there in the standard then? Just throw it away and nothing changes. For example, accessing, say, float with an int* will still be undefined due to your reading of 6.3.2.3? -- Sergei.
Re: PATCH: Build shared libraries with -Bsymbolic-functions
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.
Re: Tricky(?) aliasing question.
Andrew Pinski wrote: Third, it only checks C programs (and not C++). This has not been true for some time now (at least developmental wise). -- Pinski Oops, had not noticed that. Forget third argument then. Silvius
Re: Mis-handled ColdFire submission?
On Wed, Jan 10, 2007 at 09:13:54PM +, Richard Sandiford wrote: > I know Andrew replied privately, but I hope he doesn't mind me raising > the issue on-list. I just wanted to guage the general feeling as to > whether I'd screwed up, and whether I should have submitted the patches > in a different way. I think splitting the submission into separate patches was a good idea and FWIW, I did read all 63 of them. I agree with Eric Botcazou about your way of posting them in a thread. My only critisism is that surely, all these improvements weren't carried out just last week. I.e. some of them could have been submitted earlier, thereby making them available to users earlier as well as preventing duplicate work. An example is PR target/28181, which was reported half a year ago and at least three people worked on fixing. So once your patches are ready, go ahead and submit them. -- Rask Ingemann Lambertsen
dump after RTL expand
Hi, how could I find out from which patterns, in the md file, the 00.expand file was generated (i.e. to map the patterns in the expand file with the ones in the .md file)? Is there a compiler option/switch which would tell the compiler mark the patterns in the expand file with the insns names from the md file? best regards Andrija Radicevic
Re: dump after RTL expand
On 1/11/07, Andrija Radicevic <[EMAIL PROTECTED]> wrote: Hi, how could I find out from which patterns, in the md file, the 00.expand file was generated (i.e. to map the patterns in the expand file with the ones in the .md file)? Is there a compiler option/switch which would tell the compiler mark the patterns in the expand file with the insns names from the md file? There isn't. You would have to walk over the insn and make recog assign them an insn code. Gr. Steven
Re: Mis-handled ColdFire submission?
>My only critisism is that surely, all these improvements weren't carried > out just last week. I.e. some of them could have been submitted earlier, > thereby making them available to users earlier as well as preventing > duplicate work. An example is PR target/28181, which was reported half a > year ago and at least three people worked on fixing. So once your patches > are ready, go ahead and submit them. 28181 has been popping up over the last several years in various forms (5373, 13803, 18421, 23695, etc). -- Peter Barada [EMAIL PROTECTED]
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 \ -
gcc on 64 bits machine
Hi, Can you please tell me can I use gcc 3.4 to compile a binary on a 64 bits machine? or I need to use gcc 4.1? Thank you.
Re: gcc on 64 bits machine
On Thu, Jan 11, 2007 at 02:09:51PM -0600, ying lcs wrote: > Can you please tell me can I use gcc 3.4 to compile a binary on a 64 > bits machine? or I need to use gcc 4.1? Please use gcc-help for questions like this. The gcc list is for developers and serious testers, not for user support.
libgcc-math
Richard -- The GCC SC has been discussing libgcc-math. RMS says that he will need to consider the issue, and that he has other things he wants to do first. So, I'm afraid that we can't give you a good timeline for a resolution of the question, but I can say that some progress is being made. FYI, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: dump after RTL expand
On Thursday 11 January 2007 19:27, Steven Bosscher wrote: > On 1/11/07, Andrija Radicevic <[EMAIL PROTECTED]> wrote: > > Hi, > > how could I find out from which patterns, in the md file, the 00.expand > > file was generated (i.e. to map the patterns in the expand file with the > > ones in the .md file)? Is there a compiler option/switch which would tell > > the compiler mark the patterns in the expand file with the insns names > > from the md file? > > There isn't. > > You would have to walk over the insn and make recog assign them an insn > code. That still wouldn't tell you what names were used to generate them. It's common to have a named expander that generates other (possibly anonymous insns). Paul
Re: RFC: Wextra digest (fixing PR7651)
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> The goal is to fix PR7651 and convert Wextra into a super-option, that
> is an -W* option that just enables other options but it doesn't emit
> warnings by itself (other super-options are Wall and Wunused).
Thanks again for tackling this.
These issues are tricky because on the one hand we don't want too many
different options, and on the other hand we want to give people the
control they are asking for with regard to turning off warnings.
> * Subscripting an array which has been declared register.
>
> * Taking the address of a variable which has been declared register.
Hmmm. In the C frontend these are pedwarns. But the C++ frontend
doesn't have pedwarns. And maybe C++ doesn't require these warnings
anyhow, I don't know. -Winvalid-register anyone?
> * A base class is not initialized in a derived class' copy constructor.
I think -Wuninitialized.
> * A non-static reference or non-static const member appears in a class
> without constructors.
-Wbad-code. Or, I dunno, how about -Wmissing-field-initializers?
> * Ambiguous virtual bases (virtual base inaccessible due to
> ambiguity). (There is also an unconditional warning for direct base
> inaccessible due to ambiguity)
What do you think of -Woverloaded-virtual?
> * An enumerator and a non-enumerator both appear in a conditional
> expression. (There is also an unconditional warning for two different
> enumeral types used in a conditional expression).
Maybe we should rename -Wswitch-enum to -Wenum and wrap these warnings
under there as well.
> * A function can return either with or without a value.
I give up.
> * An expression-statement or the left-hand side of a comma expression
> contains no side effects. For example, an expression such as x[i,j].
> This is also warned by Wunused-value. In addition, Wextra enables
> Wunused-value but this is not documented (and -Wunused-value is
> already enabled by -Wall).
I think this should just be -WUnused-value.
> * A pointer is compared against integer zero with <, <=, >, or >=.
> This is a pedwarn and it can also be enabled by using -pedantic. If
> the pointer is the rightmost operator, there is no warning for Wextra
> (surely a bug).
-Wpointer-arith, maybe.
> * An unsigned value is compared against zero with < or >=.
> Walways-true claims to warn for this but it doesn't. There is also an
> unconditional warning for expressions that are always true or false
> due to the range of types.
-Walways-true should warn for this.
> In ./gcc/config/sh/symbian.c:158 there is a warning enabled by Wextra
> with the following code (notice the OPT_Wattributes) :
>
> /* We ignore the dllimport attribute for inline member functions.
> This differs from MSVC behavior which treats it like GNUC
> 'extern inline' extension. */
> else if (TREE_CODE (decl) == FUNCTION_DECL && DECL_INLINE (decl))
> {
> if (extra_warnings)
> warning (OPT_Wattributes, "inline function %q+D is declared as "
>"dllimport: attribute ignored",
>decl);
> return false;
> }
Just drop the test of extra_warnings, I think.
> Finally, the manual page claims that Wextra warns for any of several
> floating-point events that often indicate errors, such as overflow,
> underflow, loss of precision, etc. I wasn't able to find any instance
> of this. I am fairly sure that Wextra doesn't do such thing.
I have no idea what that refers to.
Thanks again. Hope this helps. No doubt others will disagree with
some of my comments.
Ian
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
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. - Grigory
Re: RFC: Wextra digest (fixing PR7651)
On Jan 11, 2007, at 3:48 PM, Ian Lance Taylor wrote: * Taking the address of a variable which has been declared register. Hmmm. In the C frontend these are pedwarns. But the C++ frontend doesn't have pedwarns. And maybe C++ doesn't require these warnings anyhow, I don't know. Just FYI... In C++ there is no semantic content to register, it is rather like auto. C is different.
Re: RFC: Wextra digest (fixing PR7651)
On 11 Jan 2007 15:48:36 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> The goal is to fix PR7651 and convert Wextra into a super-option, that
> is an -W* option that just enables other options but it doesn't emit
> warnings by itself (other super-options are Wall and Wunused).
Thanks again for tackling this.
These issues are tricky because on the one hand we don't want too many
different options, and on the other hand we want to give people the
control they are asking for with regard to turning off warnings.
Yeah, I know but I thought it was a goal that every warning is
controlled by some option. I also think (and is under discussion
elsewhere) that super-options (as Wall) should only enable other
options and don't have associated any warning to themselves.
> * Subscripting an array which has been declared register.
>
> * Taking the address of a variable which has been declared register.
Hmmm. In the C frontend these are pedwarns. But the C++ frontend
doesn't have pedwarns. And maybe C++ doesn't require these warnings
anyhow, I don't know. -Winvalid-register anyone?
If we don't require them, we could drop them. Also, there is already
a patch in the queue [1] to name this -Waddress-of-register. I could
update it with Winvalid-register.
[1] http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01676.html
> * A base class is not initialized in a derived class' copy constructor.
I think -Wuninitialized.
If none disagrees, OK.
> * A non-static reference or non-static const member appears in a class
> without constructors.
-Wbad-code. Or, I dunno, how about -Wmissing-field-initializers?
Wbad-code is vague. -Wmissing-field-initializers seems fine and also
-Wuninitialized. Any other opinion?
There is a patch and a discussion about this:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01842.html
> * Ambiguous virtual bases (virtual base inaccessible due to
> ambiguity). (There is also an unconditional warning for direct base
> inaccessible due to ambiguity)
What do you think of -Woverloaded-virtual?
Fine to me but I am no C++ expert and we have to think if the users of
Woverloaded-virtual will be happy with this additional warning.
> * An enumerator and a non-enumerator both appear in a conditional
> expression. (There is also an unconditional warning for two different
> enumeral types used in a conditional expression).
Maybe we should rename -Wswitch-enum to -Wenum and wrap these warnings
under there as well.
I don't think they have much to do with each other. Moreover, this
warning applies only to C++. What about -Wconversion ?
Again, there is patch with testcases here:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01842.html
> * A function can return either with or without a value.
I give up.
:-) None said it was going to be easy. We have a warning similar to this:
-Wreturn-type
warn about any "return" statement with no return-value in a
function whose return-type is not "void".
However, this is enabled by Wall and the one from Wextra surely
produces false positives (I guess that is the reason it is in Wextra).
-Wreturn-type-may ?
> * An expression-statement or the left-hand side of a comma expression
> contains no side effects. For example, an expression such as x[i,j].
> This is also warned by Wunused-value. In addition, Wextra enables
> Wunused-value but this is not documented (and -Wunused-value is
> already enabled by -Wall).
I think this should just be -WUnused-value.
So do I. There is a patch to implement just that here:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00440.html
> * An unsigned value is compared against zero with < or >=.
> Walways-true claims to warn for this but it doesn't. There is also an
> unconditional warning for expressions that are always true or false
> due to the range of types.
-Walways-true should warn for this.
No, I think it shouldn't but let's leave this for now, please. I need
to do a bit more of research and archive archaeology to properly
justify why I think that this is a Really Bad Idea (TM). Or we could
just drop the idea @ kernel.org and see what happens. Any brave
volunteer?
> In ./gcc/config/sh/symbian.c:158 there is a warning enabled by Wextra
> with the following code (notice the OPT_Wattributes) :
>
> /* We ignore the dllimport attribute for inline member functions.
> This differs from MSVC behavior which treats it like GNUC
> 'extern inline' extension. */
> else if (TREE_CODE (decl) == FUNCTION_DECL && DECL_INLINE (decl))
> {
> if (extra_warnings)
> warning (OPT_Wattributes, "inline function %q+D is declared as "
>"dllimport: attribute ignored",
>decl);
> return false;
> }
Just drop the test of extra_warnings, I think.
OK. I just found out that Wattributes is enabled by default. So
dropping it from Wextra seems appropriate.
> Finally, the manual page claims that Wextr
Re: RFC: Wextra digest (fixing PR7651)
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: > On 11 Jan 2007 15:48:36 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > > These issues are tricky because on the one hand we don't want too many > > different options, and on the other hand we want to give people the > > control they are asking for with regard to turning off warnings. > > > > Yeah, I know but I thought it was a goal that every warning is > controlled by some option. I also think (and is under discussion > elsewhere) that super-options (as Wall) should only enable other > options and don't have associated any warning to themselves. Yes, I agree with that. What I was trying to say is that, given that goal, we have a choice between giving each warning its own option, or grouping warnings together. When warnings are grouped, people can only disable or enable the entire group, which makes it harder for them to control the specific warning they are interested in. When warnings are not grouped, there are too many options. We need to strike a balance between those extremes, and that is tricky. > > > * Subscripting an array which has been declared register. > > > > > > * Taking the address of a variable which has been declared register. > > > > Hmmm. In the C frontend these are pedwarns. But the C++ frontend > > doesn't have pedwarns. And maybe C++ doesn't require these warnings > > anyhow, I don't know. -Winvalid-register anyone? > > If we don't require them, we could drop them. Also, there is already > a patch in the queue [1] to name this -Waddress-of-register. I could > update it with Winvalid-register. > > [1] http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01676.html -Waddress-of-register works for me. > > > * A non-static reference or non-static const member appears in a class > > > without constructors. > > > > -Wbad-code. Or, I dunno, how about -Wmissing-field-initializers? > > > > Wbad-code is vague. -Wmissing-field-initializers seems fine and also > -Wuninitialized. Any other opinion? -Wbad-code was a joke, but we have so many warning options that it seems erious. I think -Wuninitialized is a good suggestion. > > > * Ambiguous virtual bases (virtual base inaccessible due to > > > ambiguity). (There is also an unconditional warning for direct base > > > inaccessible due to ambiguity) > > > > What do you think of -Woverloaded-virtual? > > Fine to me but I am no C++ expert and we have to think if the users of > Woverloaded-virtual will be happy with this additional warning. In my opinion, both the current -Woverloaded-virtual and an inaccessible virtual base are almost always mistakes. And they are the same sort of mistake: something in a base class is hidden in a child class. So I personally think using the same option here is reasonable. > > > * An enumerator and a non-enumerator both appear in a conditional > > > expression. (There is also an unconditional warning for two different > > > enumeral types used in a conditional expression). > > > > Maybe we should rename -Wswitch-enum to -Wenum and wrap these warnings > > under there as well. > > I don't think they have much to do with each other. Moreover, this > warning applies only to C++. What about -Wconversion ? -Wconversion is good. > > > * A function can return either with or without a value. > > > > I give up. > > :-) None said it was going to be easy. We have a warning similar to this: > > -Wreturn-type >warn about any "return" statement with no return-value in a > function whose return-type is not "void". > > However, this is enabled by Wall and the one from Wextra surely > produces false positives (I guess that is the reason it is in Wextra). > -Wreturn-type-may ? I tend to think that having some returns with a value and some without is an error. Maybe grouping them in -Wreturn-type makes sense, although the name is not quite right. > > > * An unsigned value is compared against zero with < or >=. > > > Walways-true claims to warn for this but it doesn't. There is also an > > > unconditional warning for expressions that are always true or false > > > due to the range of types. > > > > -Walways-true should warn for this. > > No, I think it shouldn't but let's leave this for now, please. I need > to do a bit more of research and archive archaeology to properly > justify why I think that this is a Really Bad Idea (TM). Or we could > just drop the idea @ kernel.org and see what happens. Any brave > volunteer? -Wunsigned-compare? > > > Finally, the manual page claims that Wextra warns for any of several > > > floating-point events that often indicate errors, such as overflow, > > > underflow, loss of precision, etc. I wasn't able to find any instance > > > of this. I am fairly sure that Wextra doesn't do such thing. > > > > I have no idea what that refers to. > > So we just remove it from doc/invoke.texi ? Yes. Ian
Re: proposal to clean up @node Warning Options in invoke.texi
Joe Buck <[EMAIL PROTECTED]> writes: | On Thu, Jan 11, 2007 at 04:09:16AM +0100, Gabriel Dos Reis wrote: | > The subtlety I'm refering to is not that "void* p = &p" is not well-defined, | > but rather the fact that when we see | > | > T t = some-expression-involving-t; | > | > we would like to warn for cases where there is a high probability that | > the *initialization* of "t" *results in undefined behaviour*, as opposed | > to leaving "t" undefined. -Wunintialized was not designed to handle | > those cases. That matter is compounded by the fact that | > some constructs such as | > | >circular_buffer buf = buf; | > | > are well-formed and not attempt to work around agreed deficiency of | > -Wunitialized. To do that, it is not clear -- without seeing the body | > of the copy constructor -- whether only the address is used or not. | | There are three cases: either you can be certain that an uninitialized | value will be used, or you can be certain that it won't be used, or | you don't know because you don't see the body of the copy constructor. | | Case 1: | int i = i; | or | SomeClass p = p; // compiler-generated copy constructor | Case 2: | void* p = &p; | Case 3: | SomeClass p = p; // user-defined copy constructor, can't see the body | | Case 2 is completely valid. In Case 1 we have uninitialized variables. | In Case 3 we cannot tell. | | There's an argument for not warning in case 3, though unfortunately | in my early days of C++ programming I often managed to make mistakes | similar to this, and the compiler would not warn. I would like the compiler to warn for case 1 when the copy-constructor is inline, along with cases like int i = 2 * i; There are comparable, relatively simple cases that the compiler can warn about without requiring optimization be turned on. -- Gaby
Re: libgcc-math
Mark Mitchell <[EMAIL PROTECTED]> writes: | Richard -- | | The GCC SC has been discussing libgcc-math. RMS says that he will need | to consider the issue, and that he has other things he wants to do | first. So, I'm afraid that we can't give you a good timeline for a | resolution of the question, but I can say that some progress is being made. I would like the SC to consider that liibgcc-math will also greatly help improve libstdc++, in particular for its numeric support. -- Gaby
-fprefetch-loop-arrays comportement.
Bonsoir, Je développe un programme de recalage de points sur une surface 3D. Donc il s'agit d'utilisation d'algorithmes de calculs, (projection, distance euclidienne..) je cherche comment optimiser mon code, je suis arriver a la moitié du temps d'exécution, mais après l'utilisation de cette option -fprefetch-loop-arrays, j'ai remarquer quelle ralentit un peut le code voila. Ps: j'utilise la dernière version de Gcc, cordialement. -- Karim Taha -Ing 1- Promo 2009 EPITA
bug management: WAITING bugs that have timed out
Hi, http://gcc.gnu.org/bugs/management.html says that bugs in WAITING state for more than three months, waiting for information on how to reproduce the bug, can be closed, but it is unclear what the "closed" state should be. The description of WORKSFORME sounds closest: we don't know how to reproduce the bug. Should that be used? The only other choices are FIXED (wrong), DUPLICATE (wrong), INVALID (we don't know that), or WONTFIX (we're not saying we won't fix it if we get a testcase). This came up because RMS raised a concern about the large number of wrong-code bugs; many of those not marked "regression" are WAITING, or should be WAITING. I'd like to knock off a few (and of course they can be re-opened if we get more data).
Re: Making gcc read from the standard input
Paolo Bonzini wrote: > Tathagato Rai Dastidar wrote: >> Hello, >> >> Is there a way I can make GCC read a C or C++ code from the standard >> input instead of from a file? >> >> In my application software, I am generating some C code on the fly, >> writing it to a file, then using GCC to compile it. Instead of that, I >> want to invoke GCC through a pipe, and write the C code directly into >> GCC, instead of writing it into a file and then calling GCC. >> >> Is this possible? > > This is a question only for gcc-help. Cross-posting gcc and gcc-help is > almost always wrong. :-) But yes, it is possible by adding "-x c" to > the command line, so that the gcc driver knows which front-end to > invoke. In the case of "-E", in fact, GCC implicitly considers the > language to be C (and invokes the C front-end) because the preprocessor > is the same for all input languages; but for real compilation, you need > to specify the language manually. The preprocessor shouldn't be the same for all languages; there are differences between C90, C++98 and C99 in a number of aspects (predefined macros, interpretation of true in expressions, vararg macro support, presence of alternate tokens in C++, support for long long values and probably more than slip my mind right now). Some of the differences can be ignored because they fall into the realms of defining undefined behaviours, but others have well-defined but differing behaviour depending on the language. -- James
Re: bug management: WAITING bugs that have timed out
> The description of WORKSFORME sounds closest: we don't know how to > reproduce the bug. Should that be used? The only other choices > are FIXED (wrong), DUPLICATE (wrong), INVALID (we don't know that), > or WONTFIX (we're not saying we won't fix it if we get a testcase). > > This came up because RMS raised a concern about the large number > of wrong-code bugs; many of those not marked "regression" are WAITING, > or should be WAITING. I'd like to knock off a few (and of course > they can be re-opened if we get more data). Create a new case then. Afterall it can't be that hard compared to working on GCC, right? Perhaps "STUCK-FOR-MORE-INFO" would make sense. I can see "WAITING" being that either there's not enough info or not enough testcase. Even if its state is WORKSFORME, I can see adding the testcase around on some automated tester to verify the compiler doesn't bork in the future. Any bug that creates an ICE should DEFINITELY remain open, and maintainers should persue the reporter for a testcase, if only to fix/add to an automated tester. As an example, a bunch of the ColdFire "move.b, ,%aY" bugs (5753 for example), with testcases, get getting hammered closed in various releases, only to pop up again in the future. Saddest is that is that in a batch of various related bug closings, the blanket comment "M68k/ColdFire is not a primary platform - CLOSED". Again, this misleads any analysis of how good GCC is as a compiler for non-primary targets. Is there a way of converting these to DEFERRED so they don't get magically CLOSED and their testcases get pulled into some automated tester? I can't see blindly punting bugs that someone has gone to at least the effort of reporting only to get ignored if no further information is forthcoming - perhaps the description of the issue is enough for some energetic intern to come along and create a testcase, who knows? -- Peter Barada [EMAIL PROTECTED]
Re: PATCH: Build shared libraries with -Bsymbolic-functions
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). Paolo
