Re: Lost gccbug submission
Daniel Berlin writes: > > Could you please check what's going on there? Is this a general problem > > with gcc-gnats processing or a problem parsing that particular message? > > Dunno. Grepping mail logs older than an hour takes a while on > sourceware, because they are large. Can you resend it and notify me when > you do? I just did so. > gcc-gnats parsing will probably go the way of the dodo when i move us to > bugzilla 2.20 in a month or two, because i imagine it will break, and I > just don't have the time or care to update that script. > > Do you just want some way to submit bugs by email, or what? Exactly: I don't care for gccbug or gnats in particular, only for a way to submit email bug submission (just as I can add comments by email once I've submitted the initial report). > I'm happy to provide a simple python script that uses a sane interface to > submit bugs so you don't have to use the web interface, but i'm curious if That would be nice (although perl instead of python would be a tad more convenient since it is probably more widespread, especially on non-Linux OSes, but a python script is certainly much better than having to go through a web browser). Especially important is that the script uses whatever editor I prefer to compose the actual message. > the draw is the ability to send by email or just not use a web browser (IE > are you actually composing gccbug style emails, or using gccbug)? I'm using gccbug since it provides the complete template where I just need to fill in the beef of the report. All I care for is the ability to handle bugs completely by email. Thanks. Rainer
GCC-4.0.2 20050811: should GCC consider inlining functions in between different sections?
Hello,
Subject says it all - I do not know if that is new. I just have a bug
in Gujin-1.2 with this new compiler, because function:
__attribute__ ((section (".xcode_start"), noreturn))
void xcodeseg_never_call_address_zero (void)
calls xcodeseg_BOOT1_putstr() generated by macro:
#define GENERATE_VOID_EXTRA2CODE_INDIRECT_STUB(fctname, fctadr, params...) \
__attribute__ ((section (STRING(.Xxcode2text_ ## fctname \
void xcodeseg_ ## fctname (params) {\
EXTRASEG_REVERSE_STUB (fctadr, STRING(.Xtext2xcode_ ## fctname));\
}
Adding ", noinline" to the attribute list fix it all, I just was wondering
if inlining in between GCC sections is safe in the general case.
Etienne.
___
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
[SUMMARY] Old machine cluster for GCC compile/testing
Thanks to all who proposed projects and volunteered, I've informed FSF France that the project has enough volunteers to move ahead. I'll write a summary in the GCC wiki this week-end, feel free to add more projects then. The machines should appear online at the beginning of september, script volunteers and developpers who currently do not have access to better hardware for GCC work will get a user account with ssh access. I haven't discussed yet of the opensolaris-x86 issue with FSF France, if someone really volunteer to guide me for the install process and maintain useful scripts on the machine then I'll ask. I'm also all open to non Linux OS like the *BSD family, also subject to volunteer effective availability (no issue with FSF France for *BSD :). Sincerely, Laurent On Mon, 2005-08-08 at 23:21 +0200, Laurent GUERBY wrote: > Hi, > > FSF France has received in donation 9 Dell poweredge 1550 bi processor > 1U machines with one 18GB SCSI disk and 1GB RAM, processors total 19.5 > GHz distributed as follows: > > - 3 bi pentium III 1.25 GHz > - 6 bi pentium III 1.00 GHz > > The machines are about four years old, so of course there may be > hardware problems in the coming years, but we might also be able > to get cheap parts on the used market (or from other donations). > > An offer has been made for hosting those 9 1U machines in Paris provided > low use of external bandwidth, so this would be useable for a GCC > compile farm. > > FSF France has to say yes or no to the hosting offer by friday 12Aug2005 > 17:00 UTC (end of this week), if we do not set up some > compile/compute-farm like project FSF France will allocate these > machines to other tasks. FYI 31 other machines of this type were also > donated and have been allocated to various projects. > > So I'm asking for project proposals, that is to say people that think > that their volunteer time to work on these old machine (scripts, > compiling, ... under the limit of minimal external bandwidth use) is of > some significant benefit to some free software project. > > Project participants would get ssh access to the machines at > the beginning of september 2005. > > The machines are currently installed with ubuntu 5.04, but this could > change if needed (and expertise provided). > > Feel free to pass this offer to projects that are related to GCC, like > free software compiled with GCC that come with a useful test suite and > where volunteer are willing to help. > > Discussions are welcome on this list. > > Sincerely, > > Laurent > > PS: sorry for the short notice, I wasn't aware until recently that > there was a time limit on the hosting offer. We might be able > to get another hosting offer, but I prefer not count on it. > > >
Re: GCC-4.0.2 20050811: should GCC consider inlining functions in between different sections?
On 8/12/05, Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Subject says it all - I do not know if that is new. I just have a bug
> in Gujin-1.2 with this new compiler, because function:
>
> __attribute__ ((section (".xcode_start"), noreturn))
> void xcodeseg_never_call_address_zero (void)
>
> calls xcodeseg_BOOT1_putstr() generated by macro:
>
> #define GENERATE_VOID_EXTRA2CODE_INDIRECT_STUB(fctname, fctadr, params...) \
> __attribute__ ((section (STRING(.Xxcode2text_ ## fctname \
> void xcodeseg_ ## fctname (params) {\
> EXTRASEG_REVERSE_STUB (fctadr, STRING(.Xtext2xcode_ ## fctname));\
> }
>
> Adding ", noinline" to the attribute list fix it all, I just was wondering
> if inlining in between GCC sections is safe in the general case.
Please explain the problem you're seeing. I can see nothing wrong with inlining
functions within different sections in general. If you're trying to
do things behind
the compilers back, though, be prepared to change workarounds with compiler
versions.
Richard.
Re: Lost gccbug submission
Rainer Orth <[EMAIL PROTECTED]> writes: [...] | I'm using gccbug since it provides the complete template where I just need | to fill in the beef of the report. All I care for is the ability to handle | bugs completely by email. Amen. And it is important that one has at least a good flexibility for querying and changing fields as appropriate -- something particularly missing currently. -- Gaby
Re: GCC-4.0.2 20050811: should GCC consider inlining functions in between different sections?
--- Richard Guenther <[EMAIL PROTECTED]> wrote: > Please explain the problem you're seeing. I can see nothing wrong with > inlining functions within different sections in general. If you're > trying to do things behind the compilers back, though, be prepared to > change workarounds with compiler versions. For my project, i.e. Gujin on sourceforge, I am putting some sections in one place, some other in another place, and the relation in between sections has to be tightly controlled. For instance in Gujin, section names decides on which i386 code segment the code will be put - so that if you want to reference some symbols in another code section you have to do the equivalent of a far code instead of a near call. I have added a command to the linker file to forbid reference from one section to another: NOCROSSREFS (.text .xcode); so that I can catch the unexpected use at link time. The inter-segment references have to be in some special sections - using some out-of-line functions. Inlining those special functions makes a symbol reference from a section name appear in another - in this special case my software would still work when the "NOCROSSREFS (.text .xcode);" is commented out. The question is in fact: what is a section for GCC? Is it just a way to group functions together to improve memory cache efficiency; or is the GCC user authorised to use sections to forbid access to some functions at link time? Is there a third use of sections I am not aware of? (excluding function sections for LD garbage collection of section, which is quite an orthogonal problem). Thanks for information, Etienne. ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com
Re: Lost gccbug submission
On Fri, 2005-08-12 at 13:24 +0200, Gabriel Dos Reis wrote: > Rainer Orth <[EMAIL PROTECTED]> writes: > > [...] > > | I'm using gccbug since it provides the complete template where I just need > | to fill in the beef of the report. All I care for is the ability to handle > | bugs completely by email. > > Amen. And it is important that one has at least a good flexibility > for querying and changing fields as appropriate -- something > particularly missing currently. > You are always free to write something if you don't like the time schedule i can do this work on :) The scripts are in CVS, and commits to them will automatically update the running system. For querying, you want to edit bugzilla_email.pl, and just add the functionality you want. AFAICT (at least according to mail logs, etc) you are the only user of the querying/changing by email script, so it's not something i prioritize incredibly high, though i do get to it eventually. (Sorry, but that's just the way it is. I try to spend the time i have on the things that will help the most folks) --Dan
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Richard Kenner:
> Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity
> Checking) require that such reads are NOT erroneous.
>
> It depends what "such reads" mean. 13.9.1(12) clearly says that the
> result of an Unchecked_Conversion is erroneous if it isn't a valid
> representation. There are some cases, however, where an out-of-range
> value is a bounded error instead of being erroneous.
>
> However, note 20 (13.9.2) says that 'Valid is not considered a "read"
> and hence its use is not erroneous.
I'm sorry for my rude discussion style. I was a bit frustrated
because of some unrelated matters.
I think the GNAT documentation makes additional guarantees. If you
think this is wrong, the documentation can be fixed, of course. In
addition, the first example in PR21573 follows your advice and applies
'Valid to the result of an instantiation of Ada.Unchecked_Conversion.
This still doesn't work.
If this still doesn't convince you, here's an example which doesn't
use Ada.Unchecked_Conversion at all.
-- Another test case for PR21573. Note that if PR23354 is fixed and
-- X is initialized to a different value, this test case might no
-- longer check the same bug (but it should still print SUCCESS).
-- (The Bug3_P package is necessary to prevent compile-time
-- evaluation.)
pragma Normalize_Scalars;
with Bug3_P; use Bug3_P;
procedure Bug3 is
X : U;
-- The subtype causes X to be initialized with 0, according to the
-- current Normalize_Scalars rules.
begin
Test (X);
end Bug3;
with Ada.Text_IO; use Ada.Text_IO;
package Bug3_P is
type T is (A, B, C, D);
for T'Size use 8;
for T use (A => 2, B => 3, C => 5, D => 7);
subtype U is T range B .. D;
procedure Test (X : T);
end Bug3_P;
package body Bug3_P is
procedure Test (X : T) is
begin
-- Check with a debugger that X is zero at this point.
if X'Valid then
Put_Line ("FAIL");
else
Put_Line ("SUCCESS");
end if;
end Test;
end Bug3_P;
Re: Lost gccbug submission
On Fri, 2005-08-12 at 11:23 +0200, Rainer Orth wrote: > Daniel Berlin writes: > > > > Could you please check what's going on there? Is this a general problem > > > with gcc-gnats processing or a problem parsing that particular message? > > > > Dunno. Grepping mail logs older than an hour takes a while on > > sourceware, because they are large. Can you resend it and notify me when > > you do? > > I just did so. Fixed. Perl syntax is weird enough that when people update it, they sometimes add compile errors by accident, so the script doesn't even run enough to be able to issue an error message :(. > > > gcc-gnats parsing will probably go the way of the dodo when i move us to > > bugzilla 2.20 in a month or two, because i imagine it will break, and I > > just don't have the time or care to update that script. > > > > Do you just want some way to submit bugs by email, or what? > > Exactly: I don't care for gccbug or gnats in particular, only for a way to > submit email bug submission (just as I can add comments by email once I've > submitted the initial report). > > > I'm happy to provide a simple python script that uses a sane interface to > > submit bugs so you don't have to use the web interface, but i'm curious if > > That would be nice (although perl instead of python would be a tad more > convenient since it is probably more widespread, especially on non-Linux > OSes, but a python script is certainly much better than having to go > through a web browser). The problem is that perl is much harder for me to maintain. > Especially important is that the script uses > whatever editor I prefer to compose the actual message. Fine, but the tagging will probably be very different than what gnats uses. It will be something much more xml like, such as summary text > > the draw is the ability to send by email or just not use a web browser (IE > > are you actually composing gccbug style emails, or using gccbug)? > > I'm using gccbug since it provides the complete template where I just need > to fill in the beef of the report. All I care for is the ability to handle > bugs completely by email. I understand, but you need to realize I'm trying to provide you this with a maintenance burden that is at or below the level of use. Right now, the biggest time sink in maintaining and improving the Bugzilla code *is* the email handling scripts. Not the comment appender, which is rather small and simple, but in particular, the gnats email parser, and to a lesser extent, the query/update interface. However, the number of people using these things has been very steadily declining, to the point where there appear to now be only three regular users of the gnats email interface, including you. It's very hard for me to justify the time i end up spending updating that gnats interface when new bugzilla versions come along (these are the ones that live on my machine until they get moved into production. I didn't put any development version of 2.19 into production, though it was living on my machine. I plan on putting the next stable series, 2.20, into production). > > Thanks. > Rainer
Re: Lost gccbug submission
Daniel Berlin <[EMAIL PROTECTED]> writes: | AFAICT (at least according to mail logs, etc) you are the only user of apparently, you've to count properly.
Re: Question on updating ssa for virtual operands (PR tree-optimization/22543)
> The other thing we could try to do is put virtual variables in loop-closed- > form, at least just before the vectorizer, and at least just for some > loops. Does this sound reasonabale? (By the way, why don't we keep virtual > variables in loop-closed-form?) We used to, nobody could come up with a good reason to keep doing it, so we stopped. This was a couple months ago, i still have the emails somewhere. > > comments/ideas? I would start by figuring out why update_ssa + rewrite_into_loop_closed isn't putting SFT.3 into loop closed ssa form. Even if we do put virtual vars back into loop closed, that's still a bug. > > thanks, > dorit >
Re: Lost gccbug submission
> > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | AFAICT (at least according to mail logs, etc) you are the only user of > > apparently, you've to count properly. gccbug is different from what you are using. -- Pinski
Re: Lost gccbug submission
On Fri, 2005-08-12 at 16:52 +0200, Gabriel Dos Reis wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | AFAICT (at least according to mail logs, etc) you are the only user of > > apparently, you've to count properly. What? You do read what i wrote, right? I said you appear to be the only user of the *query* script, according to the mail logs. This is a true and factually correct statement. No mail deliveries from people other than you to gcc-bugzilla-query have been recorded in the past 3 weeks. In the past few days, we have: -rwxr--r--1 qmaill qmail16775215 Aug 10 20:29 @400042fa63b9035ad16c.s -rwxr--r--1 qmaill qmail16775239 Aug 10 23:57 @400042fa947a2521da0c.s -rwxr--r--1 qmaill qmail16775335 Aug 11 03:47 @400042faca4f3a05fb24.s -rwxr--r--1 qmaill qmail16775305 Aug 11 09:21 @400042fb189303a80324.s -rwxr--r--1 qmaill qmail16775345 Aug 11 12:47 @400042fb48ed365ee06c.s -rwxr--r--1 qmaill qmail16775235 Aug 11 14:47 @400042fb651f1cfcb52c.s -rwxr--r--1 qmaill qmail16775342 Aug 11 17:00 @400042fb842f2adcffe4.s -rwxr--r--1 qmaill qmail16775308 Aug 11 20:59 @400042fbbc373429b0ec.s -rwxr--r--1 qmaill qmail16775382 Aug 12 02:13 @400042fc05c0149b94d4.s -rwxr--r--1 qmaill qmail16775307 Aug 12 08:34 @400042fc5f2522034874.s -rwxr--r--1 qmaill qmail16775296 Aug 12 12:36 @400042fc97da055f9664.s -rw-r--r--1 qmaill qmail15861633 Aug 12 15:01 current -bash-2.05b$ grep gcc-bugzilla-query * @400042fbbc373429b0ec.s:@400042fb98c03906f9e4 starting delivery 529997: msg 1372321 to local [EMAIL PROTECTED] -bash-2.05b$ 1 use. And *that* was actually a spammer @400042fb98c038758784 new msg 1372321 @400042fb98c038758f54 info msg 1372321: bytes 20231 from <[EMAIL PROTECTED]> qp 12731 uid 22791 @400042fb98c03906e274 starting delivery 529996: msg 1372321 to local [EMAIL PROTECTED] @400042fb98c03906f214 status: local 1/10 remote 2/255 @400042fb98c03906f9e4 starting delivery 529997: msg 1372321 to local [EMAIL PROTECTED] @400042fb98c03907059c status: local 2/10 remote 2/255 @400042fb98c0398cf6ac starting delivery 529998: msg 1372321 to local [EMAIL PROTECTED] @400042fb98c0398d1204 status: local 3/10 remote 2/255 @400042fb98c0398d19d4 starting delivery 52: msg 1372321 to local [EMAIL PROTECTED] @400042fb98c0398d258c status: local 4/10 remote 2/255 @400042fb98c039f1fa0c starting delivery 53: msg 1372321 to local [EMAIL PROTECTED] @400042fb98c039f2194c status: local 5/10 remote 2/255 @400042fb98c03a8930fc starting delivery 530001: msg 1372321 to local [EMAIL PROTECTED] @400042fb98c03a895424 status: local 6/10 remote 2/255 @400042fb98c03a9838a4 starting delivery 530002: msg 1372321 to local [EMAIL PROTECTED] @400042fb98c03a985014 status: local 7/10 remote 2/255 @400042fb98c03b1b89d4 starting delivery 530003: msg 1372321 to local [EMAIL PROTECTED] This is just not a very used feature. Sorry --Dan
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Florian Weimer wrote: If this still doesn't convince you, here's an example which doesn't use Ada.Unchecked_Conversion at all. this example must print Success, that is guaranteed by the RM it is definitely critical that 'Valid not make "in-range" assumptions. the actual problem is optimization of this routine presumably: function bug3_p__tRP (A : bug3_p__t; F : boolean) return integer is begin case system__unsigned_types__unsigned!(A) is when 2 => return 0; when 3 => return 1; when 5 => return 2; when 7 => return 3; when others => [constraint_error when F "invalid data"] return -1; end case; end bug3_p__tRP; the unchecked conversion to unsigned must prevent any optimization. the optimizer must not be able to "see through" an unchecked conversion!
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Robert Dewar: > Florian Weimer wrote: >> If this still doesn't convince you, here's an example which doesn't >> use Ada.Unchecked_Conversion at all. > > this example must print Success, that is guaranteed by the RM Yes, I think so. What about the first one in PR21573? IMHO, the GNAT Reference Manual makes a guarantee that it prints SUCESS, too, but I could be misreading the documentation. > it is definitely critical that 'Valid not make "in-range" > assumptions. > the actual problem is optimization of this > routine presumably: > function bug3_p__tRP (A : bug3_p__t; F : boolean) return integer is Indeed. In this case, bug3_p__t has TYPE_MIN_VALUE and TYPE_MAX_VALUE set according to T'First'Enum_Rep and T'Last'Enum_Rep. Even without VRP, add_case_node and node_has_high_bound in stmt.c check these attributes and use them in optimizations. > the unchecked conversion to unsigned must prevent any optimization. > the optimizer must not be able to "see through" an unchecked conversion! I don't think we currently have a convenient way to express such an optimization barrier in the tree language. I fear that such barriers are also needed for all checks on scalars, by the way, not just 'Valid.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Florian Weimer wrote: I fear that such barriers are also needed for all checks on scalars, by the way, not just 'Valid. indded, and we do unchecked conversions to the base type in these cases. i guess we could fix the enum case by using unsigned as the arg type, but that would not help the general case. why can't we just completely turn off this optimization for Ada since it is wrong!
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Robert Dewar: > Florian Weimer wrote: > >> I fear that such barriers are also needed for all checks on scalars, >> by the way, not just 'Valid. > > indded, and we do unchecked conversions to the base type in these > cases. i guess we could fix the enum case by using unsigned as the > arg type, but that would not help the general case. It would also fail when the 'Valid code is inlined and the tree optimizers propagate the range information present in the enumeration type. > why can't we just completely turn off this optimization for Ada > since it is wrong! If I read the documentation correctly, you have to set TYPE_MAX_VALUE/TYPE_MIN_VALUE to the values for the base type. However, GIGI uses these attributes for other things besides passing data to the middle end, so it's not an easy change.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
If this still doesn't convince you, here's an example which doesn't use Ada.Unchecked_Conversion at all. Well sure, reading an uninitialized value is erroneous except for the use of 'Valid. I'm not saying that things aren't broken, just being very careful in the definition of what a "valid" value in an object is. The point is that these values are not "valid" (which is why 'Valid returns FALSE) and that the compiler (specifically VRP) is *correct* in deducing that the values are in the valid range of the type *except* for 'Valid and range checks. Those checks need to be done another way, such as by using the "base type". The issues with that have to do with debug output, representation within Gigi, and whether the NOP_EXPRs that would have to be used to implement that will be maintained.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Richard Kenner: > If this still doesn't convince you, here's an example which doesn't > use Ada.Unchecked_Conversion at all. > > Well sure, reading an uninitialized value is erroneous except for the use > of 'Valid. No, it's not, as Ada is not C. And please not the presence of pragma Normalize_Scalars. > I'm not saying that things aren't broken, just being very careful in the > definition of what a "valid" value in an object is. To be honest, I think your definitions don't match what is described in the in the ARM and the GNAT RM. > The point is that these values are not "valid" (which is why 'Valid > returns FALSE) and that the compiler (specifically VRP) This is not a VRP bug. It also happens with GCC 4.0.1.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
> Well sure, reading an uninitialized value is erroneous except for the use > of 'Valid. No, it's not, as Ada is not C. What's "not"? My statement is based on the Ada RM. And please note the presence of pragma Normalize_Scalars. That doesn't affect validity or erroneousness.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Richard Kenner: > > Well sure, reading an uninitialized value is erroneous except for the > use > > of 'Valid. > > No, it's not, as Ada is not C. > > What's "not"? My statement is based on the Ada RM. Quote from section 13.9.1 follows. Note the "but does not by itself lead to erroneous or unpredictable execution" part. Bounded (Run-Time) Errors 9. If the representation of a scalar object does not represent a value of the object's subtype (perhaps because the object was not initialized), the object is said to have an invalid representation. It is a bounded error to evaluate the value of such an object. If the error is detected, either Constraint_Error or Program_Error is raised. Otherwise, execution continues using the invalid representation. The rules of the language outside this subclause assume that all objects have valid representations. The semantics of operations on invalid representations are as follows: 10. If the representation of the object represents a value of the object's type, the value of the type is used. 11. If the representation of the object does not represent a value of the object's type, the semantics of operations on such representations is implementation-defined, but does not by itself lead to erroneous or unpredictable execution, or to other objects becoming abnormal. > And please note the presence of pragma Normalize_Scalars. > > That doesn't affect validity or erroneousness. It affects predictability. As Robert wrote, the test case must print SUCCESS.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Richard Kenner wrote: If this still doesn't convince you, here's an example which doesn't use Ada.Unchecked_Conversion at all. Well sure, reading an uninitialized value is erroneous except for the use of 'Valid. That is wrong, it is a bounded error. and of course validit checks must work as described in the ghnat rm. I'm not saying that things aren't broken, just being very careful in the definition of what a "valid" value in an object is. The point is that these values are not "valid" (which is why 'Valid returns FALSE) and that the compiler (specifically VRP) is *correct* in deducing that the values are in the valid range of the type *except* for 'Valid and range checks. right, but range ckecks for validity checking arr crucial Those checks need to be done another way, such as by using the "base type". The issues with that have to do with debug output, representation within Gigi, and whether the NOP_EXPRs that would have to be used to implement that will be maintained. the are done with the base type now!
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Quote from section 13.9.1 follows. Note the "but does not by itself lead to erroneous or unpredictable execution" part. Right, because it's a "bounded error".
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Richard Kenner wrote: > Well sure, reading an uninitialized value is erroneous except for the use > of 'Valid. No, it's not, as Ada is not C. What's "not"? My statement is based on the Ada RM. the rm is quite clear, lack of initialization never leads to erroneous behavior. an uninitialized variable may have an invalid value, but is not abnormal. For example it is not a valid implementation for a(i) := 0; to overwrite memory outside the array a when i is uninitialized, a validity check is required here. same thing with case statements. And please note the presence of pragma Normalize_Scalars. That doesn't affect validity or erroneousness. the progrm is not erroneous in either case
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Robert Dewar <[EMAIL PROTECTED]> wrote: > why can't we just > completely turn off this optimization for Ada since it is wrong! Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a way which is (now) incorrect, and this causes wrong optimizations. Of course, this might be seen as an evolution (the exact semantics weren't as clear before), but it does not change things. You can either disable the optimization or fix Gigi. I'd also note that you already have SRA disabled, which is an optimization which would be *very* useful to Ada, because of other Gigi bugs. -- Giovanni Bajo
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Richard Kenner wrote: Quote from section 13.9.1 follows. Note the "but does not by itself lead to erroneous or unpredictable execution" part. Right, because it's a "bounded error". which, contrary to your previous email, is definitely not an erroneous situation. Precision is very important here!
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a way which is (now) incorrect, No, that usage is correct. What's incorrect is the way that 'Valid and range checks are being implemented and/or optimized. Those should not be using the bounds of the subtype. I'd also note that you already have SRA disabled, which is an optimization which would be *very* useful to Ada, because of other Gigi bugs. No, SRA is disabled due to a very subtle front-end issue having to do with renamed discriminants in cases where the resulting subtype has fewer fields than the original record. The front end has to include the "nonexistant" fields in the subtype for Gigi's use but in a way that won't interfere with front-end semantics. This has been on the to-do list for the front end folks for quite a while.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
which, contrary to your previous email, is definitely not an erroneous situation. Precision is very important here! Yes, and I'm sorry for the confusion. However, for the purposes of this discussion, there's no difference between erroneous and bounded error: the issue is whether it's right to say that the only "valid" values of the subtype are what's given by its range and that's the case whether an invalid value would be a bounded error or erroneous.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Giovanni Bajo wrote: Robert Dewar <[EMAIL PROTECTED]> wrote: Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a way which is (now) incorrect, and this causes wrong optimizations. Of course, this might be seen as an evolution (the exact semantics weren't as clear before), but it does not change things. i may not know enougn here. but i thought that these were fields associated with the type. if so that's a wrong model for ada, where there are two situations: a) constrycts which are allowed to assume in range b) constructs which are not allowed to make this assumption how do wedistinguish these cases. right now, the front end assumes that the backend will essentially assume a) everywhere, and it widens the type in cases b) using unchecked conversions. assuming that uc's should be a barrier to range propagation. You can either disable the optimization or fix Gigi. I'd also note that you already have SRA disabled, which is an optimization which would be *very* useful to Ada, because of other Gigi bugs. really not clear to me what the fix is here
Re: GCC-4.0.2 20050811: should GCC consider inlining functions in between different sections?
On Aug 12, 2005, at 5:05 AM, Etienne Lorrain wrote: I have added a command to the linker file to forbid reference from one section to another: NOCROSSREFS (.text .xcode); It sounds like this feature isn't compatible with inlining, -fno- inline I suspect is one of the few ways to `fix' it in general, that, or require that all functions be marked noinline that would otherwise be wrong to inline. The question is in fact: what is a section for GCC? Anything a user wants. We don't limit the uses, so this question cannot, in general be answered, at best a few users could tell you how a few of them are using sections. For example, I would not expect most people to know about NOCROSSREFS.
Re: GCC-4.0.2 20050811: should GCC consider inlining functions in between different sections?
> On Aug 12, 2005, at 5:05 AM, Etienne Lorrain wrote: > > I have added a command to the linker file to forbid reference from > > one section to another: > >NOCROSSREFS (.text .xcode); > > It sounds like this feature isn't compatible with inlining, -fno- > inline I suspect is one of the few ways to `fix' it in general, that, -fno-inline still won't suppress inlining of functions called once... Honza > or require that all functions be marked noinline that would otherwise > be wrong to inline. > > > The question is in fact: what is a section for GCC? > > Anything a user wants. We don't limit the uses, so this question > cannot, in general be answered, at best a few users could tell you > how a few of them are using sections. For example, I would not > expect most people to know about NOCROSSREFS.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Richard Kenner wrote: Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a way which is (now) incorrect, No, that usage is correct. What's incorrect is the way that 'Valid and range checks are being implemented and/or optimized. Those should not be using the bounds of the subtype. they do not! the use the bounds of the base type the problem is that the 'Valid in Ada really has no analog in C. Actually the Ada 95 RM had this wrong, and did not create the special rule for 'Valid, but this was obviously intended, so an AI was issued to correct this. The AI ensures that the sequence X : t; ... if X'Valid ... is correct and works as intended to test if the uninitialized value in X is invalid. The Ada front end works by doing an unchecked conversion of X to t'Base, followed by a range check. The issue is to stop range propagation through the unchecked conversion. we certainly do NOT want to say that the bounds of t are the same as the bounds of t'base, since then we lose the valuable range optimizations in all other cases. Only 'Valid is special! P.S. i do think that for the enum type the argument should be the unsigned "base type". I will fix this but it won't help the more general case
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Richard Kenner wrote: which, contrary to your previous email, is definitely not an erroneous situation. Precision is very important here! Yes, and I'm sorry for the confusion. However, for the purposes of this discussion, there's no difference between erroneous and bounded error: the issue is whether it's right to say that the only "valid" values of the subtype are what's given by its range and that's the case whether an invalid value would be a bounded error or erroneous. no, there is a big difference x'Valid must work if x is invalid but x'valid is erroneous if x is abnormal
Inlining vs the stack
We had a situation come up here where things are like this (simplified,
obviously):
c() { char x[100]; }
a() { b(); c(); }
b() { a(); c(); }
c() is a leaf. Without inlining, no problem. WIth c() inlined into
a() and/or b(),
a few mutually recursive calls to a() and b() blow out the stack. It's
not clear
the inliner should try to do anything about this, but I think it's
worth discussing.
The inliner can't detect the recursive loop in the general case, since
it might
be split across files, so the thing to do would be put some
(target-OS-dependent)
limit on local stack usage of the inlinee. Right now there's no such
check.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
The Ada front end works by doing an unchecked conversion of X to t'Base, followed by a range check. The issue is to stop range propagation through the unchecked conversion. And as we discussed on the phone, the core of the problem is that Gigi treats unchecked conversions of numeric types as if they were normal conversions (in order to make them work for different size types) and GCC is (properly) propagating information through those conversions. What has to happen is that we need some sort of way of indicating that it's not permissible to derive information through a particular conversion.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
On Fri, 2005-08-12 at 11:53 -0400, Richard Kenner wrote: > I'm not saying that things aren't broken, just being very careful in the > definition of what a "valid" value in an object is. The point is that these > values are not "valid" (which is why 'Valid returns FALSE) and that the > compiler (specifically VRP) is *correct* in deducing that the values are > in the valid range of the type *except* for 'Valid and range checks. You meant "for 'Valid range checks" right? (no "and"). My understanding is that VRP (the compiler) is free to remove all other language mandated range checks based on type min/max information but has to keep the ones generated for 'Valid. An implementation model could be for the front-end to generate for each family of scalar type T a function Base_Type_Internal_Valid (X, Min, Max : in Base_Type_Of_T) return Boolean, generate a call to it at all 'Valid uses and then tell the compiler to never do any inlining at all on such generated function. Since I think there are not that many scalar base types around, I guess such functions could even be included in the Ada RTS and not generated on the fly. Of course performance wouldn't be as good as possible, but if there's no other way... Laurent
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Laurent GUERBY wrote: My understanding is that VRP (the compiler) is free to remove all other language mandated range checks based on type min/max information but has to keep the ones generated for 'Valid. and any implicit validity checks, and for gnat, validity checks from -gnatVa An implementation model could be for the front-end to generate for each family of scalar type T a function Base_Type_Internal_Valid (X, Min, Max : in Base_Type_Of_T) return Boolean, generate a call to it at all 'Valid uses and then tell the compiler to never do any inlining at all on such generated function. sounds ver inefficient, remember that many left hand side array references require implicit validity checks. Since I think there are not that many scalar base types around, I guess such functions could even be included in the Ada RTS and not generated on the fly. Of course performance wouldn't be as good as possible, but if there's no other way... Laurent
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Laurent GUERBY: > An implementation model could be for the front-end to generate for each > family of scalar type T a function Base_Type_Internal_Valid (X, Min, > Max : in Base_Type_Of_T) return Boolean, generate a call to it at all > 'Valid uses and then tell the compiler to never do any inlining at all > on such generated function. I think you could have a similar effect with an empty machine code insertion. But it's still a kludge.
Re: Ada character types : tree code and DW_AT_encoding
> "Jim" == James E Wilson <[EMAIL PROTECTED]> writes: Jim> I see that Nathan posted a patch last December to try to remove some Jim> CHAR_TYPE support. Jim> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00689.html Yeah, that must be what I remember. Jim> A possible way to solve this problem is to add a single-bit flag to Jim> INTEGER_TYPE nodes that indicates whether this is actually a character Jim> type. For my purposes, it doesn't matter exactly what approach we take, as long as we just pick one and document it. I think the affected code in gcjx is just a single line. If/when the CHAR_TYPE removal resumes, handling debug info properly ought to be a new requirement on the solution. Tom
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
> compiler (specifically VRP) is *correct* in deducing that the values are > in the valid range of the type *except* for 'Valid and range checks. You meant "for 'Valid range checks" right? (no "and"). I meant "and". Range checks are essentially 'Valid.
Re: Lost gccbug submission
Daniel Berlin writes: > Fixed. Indeed: a new resubmission just worked, thanks. > Perl syntax is weird enough that when people update it, they sometimes > add compile errors by accident, so the script doesn't even run enough to > be able to issue an error message :(. True enough: perl can easily be a write-only language ;-) > > That would be nice (although perl instead of python would be a tad more > > convenient since it is probably more widespread, especially on non-Linux > > OSes, but a python script is certainly much better than having to go > > through a web browser). > > The problem is that perl is much harder for me to maintain. Ok, so given that the number of email submitters is small, it's certainly much better to use python than having no email submission channel anymore. > > Especially important is that the script uses > > whatever editor I prefer to compose the actual message. > > Fine, but the tagging will probably be very different than what gnats > uses. > It will be something much more xml like, such as > summary text No problem here: since many people are used to xml, this should be ok (and is certainly easier to parse). > I understand, but you need to realize I'm trying to provide you this > with a maintenance burden that is at or below the level of use. > > Right now, the biggest time sink in maintaining and improving the > Bugzilla code *is* the email handling scripts. Not the comment > appender, which is rather small and simple, but in particular, the gnats > email parser, and to a lesser extent, the query/update interface. > > However, the number of people using these things has been very steadily > declining, to the point where there appear to now be only three regular > users of the gnats email interface, including you. > > It's very hard for me to justify the time i end up spending updating > that gnats interface when new bugzilla versions come along (these are > the ones that live on my machine until they get moved into production. > I didn't put any development version of 2.19 into production, though it > was living on my machine. I plan on putting the next stable series, > 2.20, into production). Ok, I understand. Since adding comments already works fine, if you can provide a way for initial bug submission via email, I'm perfectly happy. Querying by web is ok for me. Thanks alot for all the effort you put into the whole infrastructure. Rainer
Re: Inlining vs the stack
On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
We had a situation come up here where things are like this
(simplified, obviously):
c() { char x[100]; }
I think we should turn off inlining for functions > 100k stack size.
(Or maybe 500k, if you want).
Re: Inlining vs the stack
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
>> We had a situation come up here where things are like this
>> (simplified, obviously):
>>
>> c() { char x[100]; }
Mike> I think we should turn off inlining for functions > 100k stack
Mike> size. (Or maybe 500k, if you want).
Why should stack size be a consideration? Code size I understand, but
stack size doesn't seem to matter.
paul
Re: Inlining vs the stack
On Aug 12, 2005, at 12:25 PM, Paul Koning wrote:
"Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
We had a situation come up here where things are like this
(simplified, obviously):
c() { char x[100]; }
Mike> I think we should turn off inlining for functions > 100k stack
Mike> size. (Or maybe 500k, if you want).
Why should stack size be a consideration? Code size I understand, but
stack size doesn't seem to matter.
Sometimes it matters, as in the original example:
c() { char x[100]; }
a() { b(); c(); }
b() { a(); c(); }
Re: Inlining vs the stack
On Aug 12, 2005, at 4:00 PM, Dale Johannesen wrote:
Sometimes it matters, as in the original example:
c() { char x[100]; }
a() { b(); c(); }
b() { a(); c(); }
Actually in this case, x is removed so it does not matter at all.
This case though it does matter:
int f(int*); int g(void); int h(void); int i(void);
int g(void) { int a[100]; return f(&a[0]);}
int h(void) { i(); return g(); }
int i(void) { h(); return g(); }
-- Pinski
Re: Inlining vs the stack
> > "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
>
> Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
> >> We had a situation come up here where things are like this
> >> (simplified, obviously):
> >>
> >> c() { char x[100]; }
>
> Mike> I think we should turn off inlining for functions > 100k stack
> Mike> size. (Or maybe 500k, if you want).
>
> Why should stack size be a consideration? Code size I understand, but
> stack size doesn't seem to matter.
The problem is that the function you inline into starts consuming a lot
of stack space even when it didn't previously. This showed up in the
past in glibc where inlining some subfunction of printf caused printf to
kill some threading library testsuite tests and linux kernel.
Unforutnately the actual size we want to limit is somewhat variable (for
kernel it is pretty small, in usual case few hounderd K is probably good
choice). So I guess we can add command line flag for this. Other
problem is how to realistically estimate stack consumption in current
tree representation, but perhaps just summing size of all temporaries
would work
Honza
>
> paul
>
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Richard Kenner wrote: > compiler (specifically VRP) is *correct* in deducing that the values are > in the valid range of the type *except* for 'Valid and range checks. You meant "for 'Valid range checks" right? (no "and"). I meant "and". Range checks are essentially 'Valid. no, range checks are quite different from validity checks. range checks can assume data is valid, validity checks can not make thisd assumption.
Re: Inlining vs the stack
On Aug 12, 2005, at 12:25 PM, Paul Koning wrote: Mike> I think we should turn off inlining for functions > 100k stack Mike> size. (Or maybe 500k, if you want). Why should stack size be a consideration? Code size I understand, but stack size doesn't seem to matter. In general you'll want to understand how OSes allocate stack, and how the determine if an access is to the stack or not. The canonical unix way is to catch a fault, and if that fault is within X MB (8MB in years past) of the top of the stack, assume that the access is meant for the stack, extend it, and then retry the instruction. If the access is X+1 MB away, the program dies a horrible death. This line is arbitrary, exists, and is the difference between a running application and one that dies. Any transformation that increases the stack size from X to X + 1 is an invalid transformation. Currently, inlining can do this, and it is wrong. X can be run time selectable, OMF selectable, OS defined...
Re: Inlining vs the stack
Mike Stump <[EMAIL PROTECTED]> writes: > In general you'll want to understand how OSes allocate stack, and how > the determine if an access is to the stack or not. The canonical > unix way is to catch a fault, and if that fault is within X MB (8MB > in years past) of the top of the stack, assume that the access is > meant for the stack, extend it, and then retry the instruction. If > the access is X+1 MB away, the program dies a horrible death. This > line is arbitrary, exists, and is the difference between a running > application and one that dies. Yes. > Any transformation that increases the stack size from X to X + 1 is > an invalid transformation. Currently, inlining can do this, and it > is wrong. X can be run time selectable, OMF selectable, OS defined... No. Making the stack bigger by inlining is no different from making it bigger by declaring and using more local variables or calls to alloca. If the compiler can't handle a large stack, that is a bug in the compiler. In particular, see the allocate_stack instruction pattern. Ian
Question of 2nd instruction scheduling pass
I'm porting gcc-4.0.1 to a new VLIW architecture.
I figured out that the `insn' and `jump_insn' were grouped together in the 2nd
sched pass
however there is a `structural hazard' between them.
Such as the following code which generated by gcc -O3 -dP -S code.c:
@(insn:TI 319 315 474 (set (reg/v:SI 7 r7 [orig:107 j.162 ] [107])
@(const_int 0 [0x0])) 14 {*movsi_const} (nil)
@(nil))
mov .r0 r7, #0 \\ @ 319 *movsi_const/1 [length = 4]
@(jump_insn 474 319 475 (set (pc)
@(label_ref 229)) 81 {jump} (nil)
@(nil))
b .L37@ 474 jump[length = 4]
I think that the jump_insn must have the TImode, but it don't.
The insn attribute `type' of "*movsi_const" is called "r_dp" (RISC data
processing).
The insn attribute `type' of "jump" is called "r_branch" (RISC branch).
The two type of instructions are handled by the same `RISC' function unit
(called `r0').
My automata-based pipeline description is also written the following code:
(define_insn_reservation "risc_data_processing" 4
(eq_attr "type" "r_dp")
"r0")
(define_insn_reservation "risc_branch" 0
(eq_attr "type" "r_branch")
"r0")
They should reserved the `r0' (RISC 0) when they're issued.
So they shouldn't be issued in the same cycle however.
Nevertheless, sometimes the jump_insn has the correct mode:
@(insn/f:TI 58 57 59 (set (reg/f:SI 11 r11)
@(plus:SI (reg:SI 13 r13)
@(const_int -4 [0xfffc]))) 45 {*addsi3} (insn_list:REG_DEP_ANTI
57 (insn_list:REG_DEP_TRUE 56 (nil)))
@(expr_list:REG_DEAD (reg:SI 13 r13)
@(nil)))
sub .r0 r11, r13, #4@ 58*addsi3/2 [length = 4]
@(jump_insn:TI 17 59 19 (set (pc)
@(if_then_else (le (reg/v:SI 2 r2 [orig:111 size ] [111])
@(const_int 0 [0x0]))
@(label_ref 37)
@(pc))) 83 {cbranchsi4} (insn_list:REG_DEP_ANTI 56
(insn_list:REG_DEP_ANTI 58 (insn_list:REG_DEP_ANTI 57 (nil
@(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
@(nil)))
b {!C} .r0 .L11@ 17cbranchsi4/1[length = 4]
I discoverd that the `unconditional branch' is always issued with other insns
and the `conditional branch' isn't.
Are there any ways to tell GCC that don't group an jump_insn with other insns
when structural hazard occured?
Thanks a lot.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VA
[EMAIL PROTECTED] (Richard Kenner) wrote on 12.08.05 in <[EMAIL PROTECTED]>: > What has to happen is that we need some sort of way of indicating that it's > not permissible to derive information through a particular conversion. That may be the only practical solution, but it seems to me it's not the perfect solution. The point is that there are two different kinds of value range calculations. You have value range information from program flow, and you have value range information from types. You want 'Valid optimization to ignore range information from types, because that's what you're checking for in the first place. On the other hand, you *want* to use range information from program flow. For example, if you just assigned a constant, you *know* the exact range of the thing. Or maybe you already passed a program point where any out-of- range value would have been caught by an implicit 'Valid. It could optimize away a lot of implicit 'Valid checks done, say, on the same variable used as an array index multiple times. Now that is certainly nontrivial to implement, and may not be worth it for gcc. But I believe it would be better than the other way. MfG Kai
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VA
Isn't it possible to attach some information on a comparison statement that tells code generation never to never optimize away this particular comparison even if it seems to be able to prove it is always true or false? (just like volatile does for memory read) For code executed after this kind of comparison code generation (except other of such comparison) can of course assume information gained from the comparison, so we get the best of both world. Laurent On Fri, 2005-08-12 at 22:08 +0200, Kai Henningsen wrote: > [EMAIL PROTECTED] (Richard Kenner) wrote on 12.08.05 in <[EMAIL PROTECTED]>: > > > What has to happen is that we need some sort of way of indicating that it's > > not permissible to derive information through a particular conversion. > > That may be the only practical solution, but it seems to me it's not the > perfect solution. > > The point is that there are two different kinds of value range > calculations. You have value range information from program flow, and you > have value range information from types. > > You want 'Valid optimization to ignore range information from types, > because that's what you're checking for in the first place. > > On the other hand, you *want* to use range information from program flow. > For example, if you just assigned a constant, you *know* the exact range > of the thing. Or maybe you already passed a program point where any out-of- > range value would have been caught by an implicit 'Valid. It could > optimize away a lot of implicit 'Valid checks done, say, on the same > variable used as an array index multiple times. > > Now that is certainly nontrivial to implement, and may not be worth it for > gcc. But I believe it would be better than the other way. > > MfG Kai >
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VA
On Aug 12, 2005, at 3:45 PM, Laurent GUERBY wrote: Isn't it possible to attach some information on a comparison statement that tells code generation never to never optimize away this particular comparison even if it seems to be able to prove it is always true or false? Cough, hack, ick.
Re: Lost gccbug submission
Andrew Pinski <[EMAIL PROTECTED]> writes: | > | > Daniel Berlin <[EMAIL PROTECTED]> writes: | > | > | AFAICT (at least according to mail logs, etc) you are the only user of | > | > apparently, you've to count properly. | | gccbug is different from what you are using. OK. -- Gaby
bubblestrap on the 3.4 branch?
Hi... Is there something special I need to do on to run bubblestrap on the 3.4 branch? I get into this problem: configure: loading cache ./config.cache configure: error: `LDFLAGS' was not set in the previous run configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm ./config.cache' and start over make[1]: *** [config.status] Error 1 make[1]: Leaving directory `/usr/local/src/branch/objdir.3.4/gcc' make: *** [bootstrap] Error 2 I surely don't want to run make distclean... so, I'll try rm .config.cache and see what happens... If you have any help, pls let me know. -- Cheers, /ChJ
