gcc Digest 21 Dec 2004 03:07:11 -0000 Issue 3937
Topics (messages 106915 through 106944):
Warning for different pointer signedness
106915 by: Gabriel Dos Reis <gdr@integrable-solutions.net>
106917 by: Gabriel Dos Reis <gdr@integrable-solutions.net>
106919 by: Paul Schlie <schlie@comcast.net>
106922 by: Mike Stump <mrs@apple.com>
106924 by: "Joseph S. Myers" <joseph@codesourcery.com>
106925 by: Joe Buck <Joe.Buck@synopsys.COM>
106927 by: Mike Stump <mrs@apple.com>
106928 by: Andrew Pinski <pinskia@physics.uc.edu>
[PATCH] GCC 3.4.3: libobjc build failure
106916 by: Denis Zaitsev <zzz@anda.ru>
gimplify_parameters
106918 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
106929 by: Richard Henderson <rth@redhat.com>
106936 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
106938 by: Richard Henderson <rth@redhat.com>
106939 by: Richard Henderson <rth@redhat.com>
106940 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
106941 by: Richard Henderson <rth@redhat.com>
106942 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
106943 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
106944 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
gcc 4.0 libgcc_eh static linking
106920 by: Richard Henderson <rth@redhat.com>
-fdump-translation-unit considered harmful
106921 by: Stefan Strasser <sstrasser@systemhaus-gruppe.de>
106926 by: Joe Buck <Joe.Buck@synopsys.COM>
Popping registers
106923 by: Richard Henderson <rth@redhat.com>
106930 by: "Dave Korn" <dave.korn@artimi.com>
106931 by: "Sam Lauber" <sam124@operamail.com>
106932 by: Peter Barada <peter@the-baradas.com>
106933 by: "Dave Korn" <dave.korn@artimi.com>
106934 by: Zack Weinberg <zack@codesourcery.com>
106935 by: "Dave Korn" <dave.korn@artimi.com>
106937 by: "Sam Lauber" <sam124@operamail.com>
Administrivia:
To subscribe to the digest, e-mail:
gcc-digest-subscribe@gcc.gnu.org
To unsubscribe from the digest, e-mail:
gcc-digest-unsubscribe@gcc.gnu.org
To post to the list, e-mail:
gcc@gcc.gnu.org
----------------------------------------------------------------------
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Gabriel Dos Reis <gdr@integrable-solutions.net>
Date:
21 Dec 2004 00:08:46 +0100
To:
Joe Buck <Joe.Buck@synopsys.com>
To:
Joe Buck <Joe.Buck@synopsys.com>
CC:
Ian Lance Taylor <ian@airs.com>, Andrew Pinski
<pinskia@physics.uc.edu>, Paul Schlie <schlie@comcast.net>,
gcc@gcc.gnu.org, mrs@apple.com
Joe Buck <Joe.Buck@synopsys.com> writes:
| On Mon, Dec 20, 2004 at 11:14:58PM +0100, Gabriel Dos Reis wrote:
| > Yes, that means they springle cast as approppriate, not that an
| > implicit conversion on pointers is performed.
| >
| > | So
| > | int foo (unsigned char *p) { return strcmp (p, "foo"); }
| > | will always work correctly. But now the compiler emits an
| > | unconditional warning. This seems dubious to me. The code is safe.
| >
| > The code looks dubious to me, as in real life it would hardly pass
| > code-review stage.
|
| Sorry, Gaby, I don't buy this argument, given the C aliasing rules.
Well, are you pretending you'll let it pass in code review in your
company? :-)
| C says a pointer to unsigned T and a pointer to signed T can point to
| the same object.
But, it does not say that the comparison with unadorned cast is valide.
What I find in my copy of the C definition is:
[#7] An object shall have its stored value accessed only by
an lvalue expression that has one of the following types:73)
-- a type compatible with the effective type of the
object,
-- a qualified version of a type compatible with the
effective type of the object,
-- a type that is the signed or unsigned type
corresponding to the effective type of the object,
-- a type that is the signed or unsigned type
corresponding to a qualified version of 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
-- a character type.
That paragraph does not say that you can compare a pointer to unsigned
T with a pointer to signed T. Aliasing is a very different notion of
pointer comparison.
For example, consider:
typedef struct {
double* m;
} S;
What the above paragraph says is that a pointer to double may alias
an S, but it does not imply that you can compare a double* with a S*
without any appropriate cast.
| C specifies the meaning of the foo routine above.
It says that there is no implicit conversion from "unsigned char*" to
"const char*", so yes, it specifies the meaning as ill-formed, but
then it would not pass a code review.
| There is no ambiguity with the code. I think that we were right before,
| when we warned about this code only when -pedantic was specified.
I think there are two issues here:
(1) whether the code is valid; it is not.
(2) whether we should diagnose it.
As of (2), I think we need a clear roadmap, as the above is just a
specific example, one which I would find in real-life code that passes
code review. So, if we decide to accept it, then we need a clear rule.
-- Gaby
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Gabriel Dos Reis <gdr@integrable-solutions.net>
Date:
21 Dec 2004 00:16:38 +0100
To:
Joe Buck <Joe.Buck@synopsys.com>
To:
Joe Buck <Joe.Buck@synopsys.com>
CC:
Paul Schlie <schlie@comcast.net>, Andrew Pinski
<pinskia@physics.uc.edu>, gcc@gcc.gnu.org
Joe Buck <Joe.Buck@synopsys.com> writes:
| On Mon, Dec 20, 2004 at 10:21:38PM +0100, Gabriel Dos Reis wrote:
| > Pointers-to-object comparaison make sense (from the relevant standards
| > point of view) only if they
| >
| > (i) point into the same object; or
| > (ii) are (or one of them is) one-past-the-end of the same object; or
| > (iii) are (or one of them is) null.
| >
| > You then realize that if the pointers are not of the same type or cannot be
| > implicitly converted to each other, then the comparison become
| > invalid.
|
| But there is the interesting fact that pointers that differ only in
| the signed-ness of the pointed-to object can alias each other. That
| seems to imply that testing for equality makes sense, even without casting.
Are you advocating that we should be accepting this?
typedef struct S S;
int cmp(S* p, double* q) { return p == q; }
struct S {
double m;
};
If not why? The provision that supports the aliasing rule you're
alluding to is also the rule that would support the above.
I think the bottom line is that aliasing is very different from pointer
comparison, and aliasing is better tested when both pointers are
casted either to void* or char*.
-- Gaby
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Paul Schlie <schlie@comcast.net>
Date:
Mon, 20 Dec 2004 19:16:02 -0500
To:
Gabriel Dos Reis <gdr@integrable-solutions.net>, Joe Buck
<Joe.Buck@synopsys.com>
To:
Gabriel Dos Reis <gdr@integrable-solutions.net>, Joe Buck
<Joe.Buck@synopsys.com>
CC:
Andrew Pinski <pinskia@physics.uc.edu>, <gcc@gcc.gnu.org>
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
Joe Buck <Joe.Buck@synopsys.com> writes:
| On Mon, Dec 20, 2004 at 10:21:38PM +0100, Gabriel Dos Reis wrote:
| > Pointers-to-object comparaison make sense (from the relevant standards
| > point of view) only if they
| >
| > (i) point into the same object; or
| > (ii) are (or one of them is) one-past-the-end of the same object; or
| > (iii) are (or one of them is) null.
| >
| > You then realize that if the pointers are not of the same type or cannot
be
| > implicitly converted to each other, then the comparison become
| > invalid.
|
| But there is the interesting fact that pointers that differ only in
| the signed-ness of the pointed-to object can alias each other. That
| seems to imply that testing for equality makes sense, even without casting.
Are you advocating that we should be accepting this?
typedef struct S S;
int cmp(S* p, double* q) { return p == q; }
struct S {
double m;
};
If not why? The provision that supports the aliasing rule you're
alluding to is also the rule that would support the above.
I think the bottom line is that aliasing is very different from pointer
comparison, and aliasing is better tested when both pointers are
casted either to void* or char*.
-- Gaby
It would seem that it would have been more useful to define pointers
compatible if they reference equivalent effective types; as it's the
basis of determining if an arbitrary object may be modified by it directly.
(which would then preserve useful warnings when attempting to compare
pointers to nonequivalent effective types, such as between p == q above)
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Mike Stump <mrs@apple.com>
Date:
Mon, 20 Dec 2004 16:46:01 -0800
To:
Andrew Pinski <pinskia@physics.uc.edu>
To:
Andrew Pinski <pinskia@physics.uc.edu>
CC:
Joe Buck <Joe.Buck@synopsys.COM>, Ian Lance Taylor <ian@airs.com>,
gcc@gcc.gnu.org, Paul Schlie <schlie@comcast.net>, Gabriel Dos Reis
<gdr@integrable-solutions.net>
On Dec 20, 2004, at 2:51 PM, Andrew Pinski wrote:
Maybe the correct fix was to document it but that is what the JSM
wanted and nobody yelled when Mike proposed this in the first
place.
Since the impact of the recent change to always warn for this invalid
code seems larger than what people were expecting, do we want to
consider adding a flag to add the extension or to otherwise inhibit
the warning? If yes, what should it be called -fsigned-conversions or
-Wsigned-conversions?
I'm thinking of something like:
*** ./c-typeck.c.~1~ Fri Jul 23 16:16:25 2004
--- ./c-typeck.c Fri Jul 23 16:18:02 2004
*************** convert_for_assignment (tree type, tree
*** 3472,3478 ****
|| target_cmp)
;
/* If there is a mismatch, do warn. */
! else
warn_for_assignment ("pointer targets in %s differ in signedness",
errtype, funname, parmnum);
}
--- 3472,3478 ----
|| target_cmp)
;
/* If there is a mismatch, do warn. */
! else if (!flag_signed_conversions)
warn_for_assignment ("pointer targets in %s differ in signedness",
errtype, funname, parmnum);
}
What do others think? This type of change exactly restores the
extension as it existed before we started changing this area of the
compiler.
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
"Joseph S. Myers" <joseph@codesourcery.com>
Date:
Tue, 21 Dec 2004 00:56:00 +0000 (UTC)
To:
Mike Stump <mrs@apple.com>
To:
Mike Stump <mrs@apple.com>
CC:
gcc@gcc.gnu.org
On Mon, 20 Dec 2004, Mike Stump wrote:
Since the impact of the recent change to always warn for this invalid code
seems larger than what people were expecting, do we want to consider adding a
flag to add the extension or to otherwise inhibit the warning? If yes, what
should it be called -fsigned-conversions or -Wsigned-conversions?
I'd suggest -Wno-pointer-sign-conversions to disable the warning (i.e. the
warning defaults to on as now but can be disabled with that option).
Given there seems no likelihood of having an agreed design for general
warning control soon, adding specific options for any warning people want
to control separately seems reasonable to me.
In any case, the warning - plus the new option if added - should evidently
be mentioned in the release notes.
I'm thinking of something like:
(The code has changed substantially since the version this diff is
against.)
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Joe Buck <Joe.Buck@synopsys.COM>
Date:
Mon, 20 Dec 2004 17:09:16 -0800
To:
Mike Stump <mrs@apple.com>
To:
Mike Stump <mrs@apple.com>
CC:
Andrew Pinski <pinskia@physics.uc.edu>, Ian Lance Taylor
<ian@airs.com>, gcc@gcc.gnu.org, Paul Schlie <schlie@comcast.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net>
On Mon, Dec 20, 2004 at 04:46:01PM -0800, Mike Stump wrote:
Since the impact of the recent change to always warn for this invalid
code seems larger than what people were expecting, do we want to
consider adding a flag to add the extension or to otherwise inhibit the
warning? If yes, what should it be called -fsigned-conversions or
-Wsigned-conversions?
I'm kind of curious about how often it shows up. Are people who build
distros seeing lots of new warnings?
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Mike Stump <mrs@apple.com>
Date:
Mon, 20 Dec 2004 17:22:50 -0800
To:
Joe Buck <Joe.Buck@synopsys.com>
To:
Joe Buck <Joe.Buck@synopsys.com>
CC:
Andrew Pinski <pinskia@physics.uc.edu>, Ian Lance Taylor
<ian@airs.com>, gcc@gcc.gnu.org, Paul Schlie <schlie@comcast.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net>
On Dec 20, 2004, at 5:09 PM, Joe Buck wrote:
I'm kind of curious about how often it shows up. Are people who build
distros seeing lots of new warnings?
Side world build at Apple, 1 project hit out of 1280 projects; that
project, gdb, had 28 hits, dwarf2read.c was the single theme in that
project.
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Andrew Pinski <pinskia@physics.uc.edu>
Date:
Mon, 20 Dec 2004 20:26:07 -0500
To:
Mike Stump <mrs@apple.com>
To:
Mike Stump <mrs@apple.com>
CC:
Ian Lance Taylor <ian@airs.com>, gcc@gcc.gnu.org, Paul Schlie
<schlie@comcast.net>, Joe Buck <Joe.Buck@synopsys.com>, Gabriel Dos
Reis <gdr@integrable-solutions.net>
On Dec 20, 2004, at 8:22 PM, Mike Stump wrote:
On Dec 20, 2004, at 5:09 PM, Joe Buck wrote:
I'm kind of curious about how often it shows up. Are people who build
distros seeing lots of new warnings?
Side world build at Apple, 1 project hit out of 1280 projects; that
project, gdb, had 28 hits, dwarf2read.c was the single theme in that
project.
I hear it shows up in the Linux kernel a lot but I still have not seen
the source to say to forget about it (and have the Linux kernel people
fix their source) or change how the warning is done.
-- Pinski
------------------------------------------------------------------------
Subject:
Re: [PATCH] GCC 3.4.3: libobjc build failure
From:
Denis Zaitsev <zzz@anda.ru>
Date:
Tue, 21 Dec 2004 04:14:30 +0500
To:
Andrew Pinski <pinskia@physics.uc.edu>
To:
Andrew Pinski <pinskia@physics.uc.edu>
CC:
linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org,
Zack Weinberg <zack@codesourcery.com>
On Mon, Dec 20, 2004 at 05:48:17PM -0500, Andrew Pinski wrote:
On Dec 20, 2004, at 5:46 PM, Denis Zaitsev wrote:
Ok. Does it means that something alike should be applied for the
files, which are including coretypes.h and tm.h for now?
Those are more complex and will not be fixed until 4.1.
Ok. Thanks.
------------------------------------------------------------------------
Subject:
gimplify_parameters
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 19:13:02 EST
To:
rth@redhat.com
To:
rth@redhat.com
CC:
gcc@gcc.gnu.org
This is the cause of the build failure (s-fileio.adb).
We can't just call gimplify_type_sizes in that context because it can make
variables in the current function that should be in the parent function (or
be nowhere, if the type is global, though the latter can occur only in Ada).
The way this was intended to work is that every type that is variably
modified would be in a DECL_EXPR; that was supposed to be the only place that
calls gimplify_type_sizes.
Now, in the case in the PR, the type is being defined as part of the
parameter list and is indeed supposed to be in the inner function and there
indeed doesn't seem to be any convenient place to put the DECL_EXPR.
The following C test case shows what's going wrong here and causes an ICE.
This is similar to the Ada case in question.
void f (int a)
{
typedef struct {int b[a];} c;
c cs;
void g (c c) {};
g (cs);
}
One approach would be to set a flag when gimplify_type_sizes has been called
on a type, but that would be wasteful of a flag and probably also cause
problems with global types in Ada (though the latter is easily fixable if it
occurs).
Fundmanentally, I see this as a front-end issue because the semantics of the
case in PR16417 is determined only by the C front-end. So it needs to find
*some* way to represent what's going on. One approach might be to extend the
type system to allow a TYPE_DECL inside the list of args and then
gimplify_parameters would only do the gimplify_type_sizes on things that had
a TYPE_DECL. But that might be major surgery. However, it seems clear
that the order of evaluation has to be "a", "type of c", "c".
So I don't have any good solution at the moment, but will keep trying to
come up with one.
------------------------------------------------------------------------
Subject:
Re: gimplify_parameters
From:
Richard Henderson <rth@redhat.com>
Date:
Mon, 20 Dec 2004 17:43:31 -0800
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
CC:
gcc@gcc.gnu.org
On Mon, Dec 20, 2004 at 07:13:02PM -0500, Richard Kenner wrote:
The following C test case shows what's going wrong here and causes an ICE.
...
void f (int a)
{
typedef struct {int b[a];} c;
c cs;
void g (c c) {};
g (cs);
}
No, it doesn't show what you think it does. The ICE happens because
there's apparently a mismatch between cgraph and the inliner about
what's legal to inline. So we abort trying to remove the cgraph call
edge from f to g.
Which happens because I removed some bits from c-common that previously
prevented inlining in this case.
Which wouldn't have affected Ada at all, so it can't be the same problem.
r~
------------------------------------------------------------------------
Subject:
Re: gimplify_parameters
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 21:25:39 EST
To:
rth@redhat.com
To:
rth@redhat.com
CC:
gcc@gcc.gnu.org
No, it doesn't show what you think it does. The ICE happens because
there's apparently a mismatch between cgraph and the inliner about
what's legal to inline. So we abort trying to remove the cgraph call
edge from f to g.
I admit I didn't look at the ICE.
Which wouldn't have affected Ada at all, so it can't be the same problem.
This isn't necessarily going to ICE, but it's going to show the case
that occurs in s-fileio.adb: where gimplify_type_sizes is getting called twice.
The fact that this case isn't complex enough for that to cause a problem
isn't the point.
Perhaps the following more complex case would show it: I can't check due
to the problem above.
int f (int a)
{
typedef struct {int b[a]; int d;} c;
c cs;
int g (c c) {return c.d;};
return g (cs) + cs.d;
}
But read my description of the problem: it should be clear.
------------------------------------------------------------------------
Subject:
Re: gimplify_parameters
From:
Richard Henderson <rth@redhat.com>
Date:
Mon, 20 Dec 2004 18:24:01 -0800
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
CC:
gcc@gcc.gnu.org
On Mon, Dec 20, 2004 at 07:13:02PM -0500, Richard Kenner wrote:
We can't just call gimplify_type_sizes in that context because it can make
variables in the current function that should be in the parent function (or
be nowhere, if the type is global, though the latter can occur only in Ada).
So I see that Temp_File_Record is apparently a non-local varible sized
structure. I see that the Ada front end has done *some* stuff to try
to make this work, like promoting portions of the computation into
global variables. E.g. system__file_io__temp_file_record__next___OFFSET.
Not having managed to get a breakpoint set at the right place to watch
things happen, I'm _presuming_ that there is still a SAVE_EXPR or three
buried inside Temp_File_Record somewhere. I can't see any other way
for D.935 to leak between the two functions.
Now, given that there is a SAVE_EXPR, and that SAVE_EXPR mechanisms
didn't change with gimplify_parameters, I'm not clear on how this was
supposed to be working beforehand. Namely,
(1) SAVE_EXPRs may be evaluated zero or one times. Subsequent evaluations
don't matter because we use previous results. Thus the only time we
can evidence a change in behaviour is when previously we had zero
evaluations and now we have one.
(2) Access to sizeof(parm) or parm.foo where foo is at some varying offset
implies that these SAVE_EXPRs must be evaluated. Thus the only way to
get zero evaluations is not to reference the data at all.
(3) Data exists to be referenced, and thus never referencing data is a
degenerate case. Thus in the common case there is at least one
evaluation of the offsets.
Given all this, I don't see how calling gimplify_type_sizes on the
parameters on function entry should break things. The common case
should have evaluated the same expressions, causing the same sort
of side effects on the SAVE_EXPRs.
So what am I missing? How did things function previously? Why are
there SAVE_EXPRs inside the sizes of non-local variable sized types
in the first place?
r~
------------------------------------------------------------------------
Subject:
Re: gimplify_parameters
From:
Richard Henderson <rth@redhat.com>
Date:
Mon, 20 Dec 2004 18:25:07 -0800
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
CC:
gcc@gcc.gnu.org
On Mon, Dec 20, 2004 at 07:13:02PM -0500, Richard Kenner wrote:
The following C test case shows what's going wrong here and causes an ICE.
This is similar to the Ada case in question.
Any chance someone could isolate a minimal version of the Ada case?
r~
------------------------------------------------------------------------
Subject:
Re: gimplify_parameters
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 21:44:16 EST
To:
rth@redhat.com
To:
rth@redhat.com
CC:
gcc@gcc.gnu.org
So I see that Temp_File_Record is apparently a non-local varible sized
structure. I see that the Ada front end has done *some* stuff to try
to make this work, like promoting portions of the computation into
global variables. E.g.
system__file_io__temp_file_record__next___OFFSET.
Right.
Not having managed to get a breakpoint set at the right place to watch
things happen, I'm _presuming_ that there is still a SAVE_EXPR or
three buried inside Temp_File_Record somewhere.
No, there can't be because a SAVE_EXPR conceptually belongs to one
function and this is shared among all.
I can't see any other way for D.935 to leak between the two functions.
The point is that Temp_File_Record is used as the type of a parameter in
*two* functions, so gimplify_parameters is being called with that type
*twice*. The first time, nothing has gone wrong but it's updated DECL_OFFSET
to be a new variable in the context of that first function.
It's the *second* function where things get messed up because now DECL_OFFSET
contains a VAR_DECL from that first function but it gets gimplified again and
we make a new VAR_DECL whose initial value is derived from that first
VAR_DECL, in some brother function, which is wrong and is the cause of the ICE.
Now, given that there is a SAVE_EXPR, and that SAVE_EXPR mechanisms
It has absolutely nothing to do with SAVE_EXPRs: there are none involved.
The handling of global variable-sized types took me *quite* a while to get
right and was probably the largest task in Gigi for the tree-ssa conversion
of Ada. I tried numerous iterations.
What I ended up with was fairly straightforward: I left in the existing
mechanisms to have all the sizes and positions be expression that only
involve constants and readonly globals, so there's no multiple evaluation
issue within the type or decl itself. There's no reason whatsoever to
gimplify a size or position of a global type (or decl): it can remain an
arbitrary GENERIC expression so long as it's readonly and has no
side-effects. Instead, whenever such a size or position is used, a copy is
made and *that copy* is gimplified in the context of the function that uses it.
------------------------------------------------------------------------
Subject:
Re: gimplify_parameters
From:
Richard Henderson <rth@redhat.com>
Date:
Mon, 20 Dec 2004 18:40:00 -0800
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
CC:
gcc@gcc.gnu.org
On Mon, Dec 20, 2004 at 09:25:39PM -0500, Richard Kenner wrote:
This isn't necessarily going to ICE, but it's going to show the case
that occurs in s-fileio.adb: where gimplify_type_sizes is getting
called twice.
Yes, but I can't see why you think this is a Real Bug rather than
a possible inefficiency.
int f (int a)
{
typedef struct {int b[a]; int d;} c;
c cs;
int g (c c) {return c.d;};
return g (cs) + cs.d;
}
I do see an ICE here, due to SRA exposing a new variable in the nested
function that hadn't been seen previously, and thus tree-nested.c wasn't
given a chance to mutate it properly. Which *is* a bug.
But this still isn't related to calling gimplify_type_sizes twice.
r~
------------------------------------------------------------------------
Subject:
Re: gimplify_parameters
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 21:46:19 EST
To:
rth@redhat.com
To:
rth@redhat.com
CC:
gcc@gcc.gnu.org
Any chance someone could isolate a minimal version of the Ada case?
Perhaps the more complex C case will show it, but it's not hard to
to see what's going wrong with the real file: set a breakpoint to find
the make_node_stat call that allocates the decl that's causing the ICE
in make_decl_rtl and you'll see what's going on.
------------------------------------------------------------------------
Subject:
Re: gimplify_parameters
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 21:50:46 EST
To:
rth@redhat.com
To:
rth@redhat.com
CC:
gcc@gcc.gnu.org
Any chance someone could isolate a minimal version of the Ada case?
Sure. You need two files, though. tbg1220.ads is
package Tbg1220 is
function Foo return Integer;
pragma Import (C, Foo);
type R is record
F1: String (1..Foo);
F2: Integer;
end record;
function Bar (X: R) return Integer;
end Tbg1220;
and tbg1220.adb is
package body Tbg1220 is
function Bar (X: R) return Integer is
begin
return X.F2;
end Bar;
end Tbg1220;
------------------------------------------------------------------------
Subject:
Re: gimplify_parameters
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 22:12:05 EST
To:
rth@redhat.com
To:
rth@redhat.com
CC:
gcc@gcc.gnu.org
Yes, but I can't see why you think this is a Real Bug rather than
a possible inefficiency.
Because the call to gimplify_type_sizes will leave junk around that
the next one will pick up, improperly. See my message that went by while
you were writing this.
I do see an ICE here, due to SRA exposing a new variable in the nested
function that hadn't been seen previously, and thus tree-nested.c wasn't
given a chance to mutate it properly. Which *is* a bug.
What an interesting test case! It was written to show one bug. So far
it hasn't shown that one, but found two others ...
------------------------------------------------------------------------
Subject:
Re: gcc 4.0 libgcc_eh static linking
From:
Richard Henderson <rth@redhat.com>
Date:
Mon, 20 Dec 2004 16:42:18 -0800
To:
Roland Lengfeldner <lengfeldner_roland@gmx.at>
To:
Roland Lengfeldner <lengfeldner_roland@gmx.at>
CC:
gcc@gcc.gnu.org
On Mon, Dec 20, 2004 at 01:25:49PM +0100, Roland Lengfeldner wrote:
The Problem is, that I link another shared library libHugoPerl to the
resulting libHugo, in order have an interface to perl. A workaround would be
to link libgcc_eh.a also to libHugoPerl.
No, that is *not* a workaround. This will not work in all corner cases.
You are supposed to be linking both libraries to libgcc_s.so. There are
reasons why there must be exactly one copt of the eh routines live in the
system.
This has been true since the beginning of time. Versions of gcc before
3.0 didn't have any mechanism to do this, which is why exceptions across
shared libraries simply don't work with gcc2. Since gcc 3.0, we've simply
gotten better at enforcing this restriction. So the fact that you can no
longer shoot yourself in the foot in this particular manner with 4.0 is in
fact a feature.
r~
------------------------------------------------------------------------
Subject:
Re: -fdump-translation-unit considered harmful
From:
Stefan Strasser <sstrasser@systemhaus-gruppe.de>
Date:
Tue, 21 Dec 2004 01:44:56 +0100
To:
Pjotr Kourzanov <peter.kourzanov@xs4all.nl>, gcc@gcc.gnu.org
To:
Pjotr Kourzanov <peter.kourzanov@xs4all.nl>, gcc@gcc.gnu.org
Pjotr Kourzanov schrieb:
For anyone interested in interfacing proprietary programs to GCC,
that's
not even much of a speed bump.
As soon as that binary API is written, someone will write a small
calling
program that will use the API to dump the translation unit into a
nicely
documented XML format. The dumper will, of course, be released
under the
GPL. Then the proprietary backend will simply read in the XML data.
I suspect the XML output thus generated will be comparable is size
to what -fdump-translation-unit generates now. As it is, it takes
*ages* to re-parse those megabytes of ASCII data (even for simple C
source files including lots of headers). The really problematic case
is only when a binary API at the tree level is exposed.
I really don't understand why this is so much of a political problem.
I understand the intentions, but isn't compiling proprietary code with
gcc the same? and that is explicitely allowed.
then, the API is already there, cp tree. it's just not very stable so
another level of abstraction would be nice to make it stable. but I
don't think this will prevent anyone to export data. (at least, not me)
to make things clear, I have no proprietary interest in this, but I am
following the XML approach stated above for other reasons. (with the
exception of "nicely documented" ;)
------------------------------------------------------------------------
Subject:
Re: -fdump-translation-unit considered harmful
From:
Joe Buck <Joe.Buck@synopsys.COM>
Date:
Mon, 20 Dec 2004 17:23:03 -0800
To:
Stefan Strasser <sstrasser@systemhaus-gruppe.de>
To:
Stefan Strasser <sstrasser@systemhaus-gruppe.de>
CC:
Pjotr Kourzanov <peter.kourzanov@xs4all.nl>, gcc@gcc.gnu.org
On Tue, Dec 21, 2004 at 01:44:56AM +0100, Stefan Strasser wrote:
I really don't understand why this is so much of a political problem. I
understand the intentions, but isn't compiling proprietary code with gcc
the same? and that is explicitely allowed.
RMS would tell you that we only have a GNU C++ compiler because Mike
Tiemann's employer could not make it proprietary, and we only have a
GNU Objective-C compiler because Steve Jobs could not make it proprietary.
Had the equivalent of dump formats existed at the time, we'd only have
C. (Of course, that's the inverse issue: proprietary front ends connecting
to GNU back ends). By making just building onto GCC and GPLing the code
the path of least resistance, RMS hopes to motivate more people to produce
free software.
------------------------------------------------------------------------
Subject:
Re: Popping registers
From:
Richard Henderson <rth@redhat.com>
Date:
Mon, 20 Dec 2004 16:52:09 -0800
To:
Sam Lauber <sam124@operamail.com>
To:
Sam Lauber <sam124@operamail.com>
CC:
gcc@gcc.gnu.org
On Mon, Dec 20, 2004 at 09:23:44PM +0100, Sam Lauber wrote:
I was wondering, how do you pop a register (like EAX) into a C variable?
You don't. Messing with the stack like that behind the compiler's
back is strictly verboten.
r~
------------------------------------------------------------------------
Subject:
RE: Popping registers
From:
"Dave Korn" <dave.korn@artimi.com>
Date:
Tue, 21 Dec 2004 01:45:27 -0000
To:
"'Richard Henderson'" <rth@redhat.com>, "'Sam Lauber'"
<sam124@operamail.com>
To:
"'Richard Henderson'" <rth@redhat.com>, "'Sam Lauber'"
<sam124@operamail.com>
CC:
<gcc@gcc.gnu.org>
-----Original Message-----
From: gcc-owner On Behalf Of Richard Henderson
Sent: 21 December 2004 00:52
On Mon, Dec 20, 2004 at 09:23:44PM +0100, Sam Lauber wrote:
I was wondering, how do you pop a register (like EAX) into
a C variable?
You don't. Messing with the stack like that behind the compiler's
back is strictly verboten.
r~
Oh, come on, it's Christmas! Let's show him how to do it: use an inline asm
to pop into a pre-reserved asm register variable like this:-
-----------------<!snip!>-----------------
Admin@ubik ~/test> cat foo.c
#include <stdlib.h>
int main (int argc, const char **argv)
{
register int Eax asm ("%eax");
asm volatile ("pop %0" : "=r" (Eax) : );
printf ("Eax was $%08x\n", Eax);
return -1;
}
-----------------<!snip!>-----------------
As you'll see, it compiles without problems and produces exactly the code Sam
wants:
-----------------<!snip!>-----------------
Admin@ubik ~/test> gcc -O3 foo.c --save-temps -o foo
Admin@ubik ~/test> cat foo.s
.file "foo.c"
.def ___main; .scl 2; .type 32; .endef
.section .rdata,"dr"
LC0:
.ascii "Eax was $%08x\12\0"
.text
.p2align 4,,15
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
xorl %eax, %eax
call __alloca
call ___main
/APP
pop %eax
/NO_APP
movl %eax, 4(%esp)
movl $LC0, (%esp)
call _printf
movl $-1, %eax
movl %ebp, %esp
popl %ebp
ret
.def _printf; .scl 2; .type 32; .endef
DKAdmin@ubik ~/test> ./foo.exe
Eax was $6101c900
DKAdmin@ubik ~/test>
-----------------<!snip!>-----------------
It even works perfectly! That's just the sort of value you would expect to
see on the stack of a cygwin application. I mean, what more could you want? ;)
cheers,
DaveK
------------------------------------------------------------------------
Subject:
Re: Popping registers
From:
"Sam Lauber" <sam124@operamail.com>
Date:
Tue, 21 Dec 2004 02:48:01 +0100
To:
"Richard Henderson" <rth@redhat.com>, gcc@gcc.gnu.org
To:
"Richard Henderson" <rth@redhat.com>, gcc@gcc.gnu.org
What is a stack? What does the compiler use it for? Why would messing with it be a bad idea? And no, I do not know assembly, and I haven't had computer science class yet.
Samuel Lauber
I was wondering, how do you pop a register (like EAX) into a C variable?
You don't. Messing with the stack like that behind the compiler's
back is strictly verboten.
r~
------------------------------------------------------------------------
Subject:
Re: Popping registers
From:
Peter Barada <peter@the-baradas.com>
Date:
Mon, 20 Dec 2004 20:58:46 -0500 (EST)
To:
sam124@operamail.com
To:
sam124@operamail.com
CC:
rth@redhat.com, gcc@gcc.gnu.org
What is a stack? What does the compiler use it for? Why would messing
with it be a bad idea? And no, I do not know assembly, and I haven't
had computer science class yet.
Well if you don't know what a stack is, then why are you asking how to
pop from it? :)
The stack is where the program allocates local storage and
pushes parameters and save/restores registers used by called functions
as well as save the return address when it calls another function so
the called function knows where to access the parameters and how to return to
the caller function.
Directly or indirectly modifying the stack pointer behind the back
of the compiler is *really* asking for trouble since modifications to
the stack pointer that are not known to the compiler will break the
ABI and cause you rprogram to "go off into the weeds" with no hope of
understanding why. Richard is right; it is *definitely* something you
don't want to do in C. If you have to abuse the stack, then roll up
your sleeves and write in assembler.
Perhaps the real question is to ask *why* you believe that you need to
pop a value from the stack(and thereby modify the stack pointer)?
Do some research on what a stack is and how its used in
programming(here Google is *definitely* your friend).
------------------------------------------------------------------------
Subject:
RE: Popping registers
From:
"Dave Korn" <dave.korn@artimi.com>
Date:
Tue, 21 Dec 2004 01:58:03 -0000
To:
"'Sam Lauber'" <sam124@operamail.com>, "'Richard Henderson'"
<rth@redhat.com>, <gcc@gcc.gnu.org>
To:
"'Sam Lauber'" <sam124@operamail.com>, "'Richard Henderson'"
<rth@redhat.com>, <gcc@gcc.gnu.org>
-----Original Message-----
From: gcc-owner On Behalf Of Sam Lauber
Sent: 21 December 2004 01:48
To: Richard Henderson; gcc
Subject: Re: Popping registers
I was wondering, how do you pop a register (like EAX) into
a C variable?
You don't. Messing with the stack like that behind the compiler's
back is strictly verboten.
r~
What is a stack? What does the compiler use it for? Why would
messing with it be a bad idea? And no, I do not know
assembly, and I haven't had computer science class yet.
Samuel Lauber
The "stack" is like a great big pile of junk where the compiler discards all
the old data it doesn't need any more, deleted strings, values of dead
variables, etc. etc., a bit like /dev/null only right inside the compiled
program. It's a bad idea to go messing with it because all the stale old data
can come flooding back out and fill your code with stuck bits, and they can take
an awful long time to clean up again.
cheers,
DaveK
------------------------------------------------------------------------
Subject:
Re: Popping registers
From:
Zack Weinberg <zack@codesourcery.com>
Date:
Mon, 20 Dec 2004 18:04:19 -0800
To:
"Sam Lauber" <sam124@operamail.com>
To:
"Sam Lauber" <sam124@operamail.com>
CC:
gcc@gcc.gnu.org
At Tue, 21 Dec 2004 02:48:01 +0100,
Sam Lauber wrote:
What is a stack?
An ubiquitous data structure, an ordered list of items that can be
augmented or diminished but only from one end; think of a stack of
dishes. "The stack" without further qualification refers to the stack
used to keep track of procedure calls.
The verbs "push" and "pop", when used in computer-science contexts
without further qualification, invariably refer to adding items to, or
taking items away from, a stack; it should be obvious which is which.
This is why Richard thinks you are talking about messing with the
(procedure-call) stack behind the compiler's back.
It seems your original question was asking something rather different,
but I do not know what that was. However, given your level of
confusion and inexperience ...
And no, I do not know assembly, and I haven't had computer science
class yet.
... you should not be posting to this mailing list at all. This
mailing list is for discussion among people developing gcc itself;
it's not for basic programming questions.
If you would like to become a developer, you first need to learn how
to program. We do encourage this, but we're not going to teach you.
Not here, anyway. It sounds like you are already taking a course;
that's a good start. There are plenty of good books that you could
read, too. Once you have done those things, then you will probably
know enough to start asking questions in general programming forums.
But, this mailing list is not one of them either.
zw
------------------------------------------------------------------------
Subject:
RE: Popping registers
From:
"Dave Korn" <dave.korn@artimi.com>
Date:
Tue, 21 Dec 2004 02:12:46 -0000
To:
"'Zack Weinberg'" <zack@codesourcery.com>, "'Sam Lauber'"
<sam124@operamail.com>
To:
"'Zack Weinberg'" <zack@codesourcery.com>, "'Sam Lauber'"
<sam124@operamail.com>
CC:
<gcc@gcc.gnu.org>
-----Original Message-----
From: gcc-owner On Behalf Of Zack Weinberg
Sent: 21 December 2004 02:04
And no, I do not know assembly, and I haven't had computer science
class yet.
... you should not be posting to this mailing list at all. This
mailing list is for discussion among people developing gcc itself;
it's not for basic programming questions.
If you would like to become a developer, you first need to learn how
to program. We do encourage this, but we're not going to teach you.
Not here, anyway. It sounds like you are already taking a course;
that's a good start. There are plenty of good books that you could
read, too. Once you have done those things, then you will probably
know enough to start asking questions in general programming forums.
But, this mailing list is not one of them either.
zw
Oh, and let me add a P.S.: Don't take any explanation *I* offer too
seriously. :) Not at this time of night in the holiday season!
Merry Christmas,
DaveK
------------------------------------------------------------------------
Subject:
Re: Popping registers
From:
"Sam Lauber" <sam124@operamail.com>
Date:
Tue, 21 Dec 2004 03:21:22 +0100
To:
"Peter Barada" <peter@the-baradas.com>, gcc@gcc.gnu.org
To:
"Peter Barada" <peter@the-baradas.com>, gcc@gcc.gnu.org
I didn't know that registers are on a stack.
What is a stack? What does the compiler use it for? Why would messing
with it be a bad idea? And no, I do not know assembly, and I haven't
had computer science class yet.
Well if you don't know what a stack is, then why are you asking how to
pop from it? :)
The stack is where the program allocates local storage and
pushes parameters and save/restores registers used by called functions
as well as save the return address when it calls another function so
the called function knows where to access the parameters and how to return to
the caller function.
Directly or indirectly modifying the stack pointer behind the back
of the compiler is *really* asking for trouble since modifications to
the stack pointer that are not known to the compiler will break the
ABI and cause you rprogram to "go off into the weeds" with no hope of
understanding why. Richard is right; it is *definitely* something you
don't want to do in C. If you have to abuse the stack, then roll up
your sleeves and write in assembler.
Perhaps the real question is to ask *why* you believe that you need to
pop a value from the stack(and thereby modify the stack pointer)?
Do some research on what a stack is and how its used in
programming(here Google is *definitely* your friend).
--
Peter Barada
peter@the-baradas.com