Popping registers
Lucas (a.k.a T-Bird or bsdfan3)
tbird-contact@cox.net
Tue Dec 21 18:03:00 GMT 2004
OK, now I see what Sam wants to do. The proper thing to do (IMHO) would
be to let the compiler allocate the stack space and then use a 'mov'
instruction to shuffle the data around, like this:
int i; // now the compiler knows that i takes up stack space
.
.
.
asm ("movl %%eax, %0": "m" (i) ::);
Lucas
gcc-digest-help@gcc.gnu.org wrote:
>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
>>>
>>>
>>
>>
>>
More information about the Gcc
mailing list