Re: IPA branch
> On Thursday 04 August 2005 19:12, Jan Hubicka wrote: > > > Hi, > > > I've branches the IPA branch yesterday and re-directed current SPEC > > > testers running tree-profiling branch (now officially retired ;) to it. > > > ( http://www.suse.de/~aj/SPEC/amd64 ). > > > The branch should be used for interprocedural optimization projects that > > > has serious chance to get into 4.2 (or perhaps longer term plans as > > > long as they won't interfere with merging changes to 4.1). > > > > > > I plan to implement the SSA based inlining to the branch and will start > > > pushing patches probably sometime next week. > > > > > > I would especially welcome frotend fixes for the multiple decls problems > > > so we can compile SPEC in whole program mode wihtout ugly hacks ;)) > > > Please use IPA in the subject line if you don't want me to miss the > > > patches to branch. > > > > Forgot to mention, the tag is ipa-branch ;) > > I guess the web pages should be updated with something like the attached? This looks fine to me. Thanks! Perhaps even cvs.html should mention that tree-profiling was almost fully merged and retired? Honza > > Gr. > Steven > > Index: cvs.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/cvs.html,v > retrieving revision 1.198 > diff -u -3 -p -r1.198 cvs.html > --- cvs.html 28 Jul 2005 21:09:10 - 1.198 > +++ cvs.html 4 Aug 2005 18:30:25 - > @@ -145,12 +145,10 @@ generally of the form "gcc-X_Y > > > > - tree-profiling-branch > - This branch is for the development of profiling heuristics > - and profile based optimizations for trees, such as profile driven inline > - heuristics. Another goal of this branch is to demonstrate that maintaining > - the CFG and profile information over expanding from GIMPLE trees to RTL > - is feasible and can bring considerable performance improvements. > + ipa-branch > + This is a branch for the development interprocedural optimizations > + such as inlining and cloning, interprocedural alias analysis, and so on. > + This branch is being maintained by Jan Hubicka > >struct-reorg-branch >This branch is for the development of structure reorganization > @@ -476,6 +474,13 @@ be prefixed with the initials of the dis >of the passes. It has now been merged into mainline for the >4.1 release. > > + tree-profiling-branch > + This branch is for the development of profiling heuristics > + and profile based optimizations for trees, such as profile driven inline > + heuristics. Another goal of this branch is to demonstrate that maintaining > + the CFG and profile information over expanding from GIMPLE trees to RTL > + is feasible and can bring considerable performance improvements. > + >bje-unsw-branch >This branch was dedicated to some research work by Ben Elliston > at the University of New South Wales (UNSW) on transformation > Index: projects/tree-profiling.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-profiling.html,v > retrieving revision 1.2 > diff -u -3 -p -r1.2 tree-profiling.html > --- projects/tree-profiling.html 4 Jul 2004 21:00:54 - 1.2 > +++ projects/tree-profiling.html 4 Aug 2005 18:30:25 - > @@ -6,6 +6,10 @@ > > Improving GCC's Interprocedural Optimizaion Infrastructure > > +This page describes the work done in 2005 on the > +tree-profiling-branch. This branch is now retired. Work > +in the same area (IPA) has continued on the ipa-branch > + > This page describes ongoing work to improve GCC's infrastructure > for tree-based interprocedural optimizers. The work is done on a > branch in GCC's CVS repository called tree-profiling-branch.
Re: memcpy to an unaligned address
On 8/4/05, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> Are you using an x86 host and an arm target?
>
Actually no, my major concern at the time was the large quantity of
legacy code with packed structures that we have on an embedded linux
x86 system. I was just testing that we didn't have an issue there with
the structure access.
> Did it produce an open code memcpy, and was it correct?
>
I couldn't see any problems with the generated code - with no
optimisation memcpy was called as a normal function, under
optimisation the memcpy was replaced with the same code as the s->b =
n line produced.
> Interesting. Can you post an assembler snippet of this?
>
I created an executable and made it report the alignment -
I used your test case and declared a variable of the packed structure then did
printf("Address of a = %p\n", &test.a);
printf("Address of b = %p\n", &test.b);
with interesting differences between gcc 3 and 4.
On further consideration i'd also add
printf("Address of test = %p\n", &test);
just to see if it showed up anything interesting.
If I had more time I'd investigate where gcc 4 is putting this
variable in memory, I have a small concern that it may be leaving
padding bytes on the stack to align the structure, I'm not sure it's a
big issue though (it definitely isn't to me anyway since we're using
2.95.3 and the unmentionable 2.96 ;o) ).
Not sure any of this helps with the memcpy alignment issue though.
Problems bootstrapping mainline on cygwin: warning: ./cc1-checksum.o ./cc1obj-checksum.o ./cc1plus-checksum.o libgcc/_chkstk.o differ
I haven't bootstrapped gcc on cygwin for a while now... but, using gcc cvs trunk LAST_UPDATED: Fri Aug 5 09:05:37 UTC 2005, I get comparison warnings...: warning: ./cc1-checksum.o differs warning: ./cc1obj-checksum.o differs warning: ./cc1plus-checksum.o differs what does that mean?? the compare passes... and the build continues... --- Cheers, /ChJ
PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE
In PR 23046 we ICE inside tree-vrp.c because fold() does not
realize that for
enum enumtype { ENUM1, ENUM2 } x;
the predicate 'if (x > 1)' is always false. This causes VRP to
create the impossible range [2, 1] for that predicate.
While it would be trivial for VRP to paper over this problem, the
real fix should be in fold(). I looked at the logic that detects
these cases and it is fairly convoluted (fold-const.c:9174).
I'm wondering why doesn't fold() just use TYPE_MAX_VALUE/TYPE_MIN_VALUE
if they're available?
Thanks.
Re: IPA branch
On Fri, 5 Aug 2005, Jan Hubicka wrote: >> I guess the web pages should be updated with something like the attached? Yes... > This looks fine to me. Thanks! Perhaps even cvs.html should mention > that tree-profiling was almost fully merged and retired? ...and, yes. ;-) Minor comments for the original patch: > > + This is a branch for the development interprocedural optimizations > > + such as inlining and cloning, interprocedural alias analysis, and so on. > > + This branch is being maintained by Jan Hubicka "for the development of...", and can you add a full stop at the end? Gerald
GNU Fortran Compiler
Hallo, what must I do for becomming the GNU Fortran Compiler? Sincerely, Hans. BEGIN:VCARD VERSION:2.1 N:Karl;Hans-Volker;;; FN:Hans-Volker Karl BDAY:1955-11-30 ORG:Paris-Lodron-Universität Salzburg; NOTE:Dipl. Phil. Dr. rer. nat. Präparator f. Geowissenschaften u. Medizin; TEL;HOME;VOICE:+493616535452 ADR;WORK:;;Institut für Geographie, Geologie und Mineralogie/ Abteilung Paläontologie;Hellbrunner Straße 34;;A- 5020;Österreich ADR;HOME:;;Jenaer Straße 32;Erfurt;;D- 99099;Deutschland EMAIL;INTERNET:[EMAIL PROTECTED] EMAIL;INTERNET:[EMAIL PROTECTED] END:VCARD
Re: GNU Fortran Compiler
On Fri, Aug 05, 2005 at 05:52:20PM +0200, [EMAIL PROTECTED] wrote: > what must I do for becomming the GNU Fortran Compiler? > If you are running a recent Linux distribution that includes GCC 4, you should already have it. Try 'gfortran'. If not, you can find binaries at http://gcc.gnu.org/install/binaries.html
RE: GNU Fortran Compiler
Original Message >From: [EMAIL PROTECTED] >Sent: 05 August 2005 16:52 > Hallo, > what must I do for becomming the GNU Fortran Compiler? > Sincerely, Hans. To become the compiler, you must _think_ like the compiler. cheers, DaveK -- Can't think of a witty .sigline today
Re: memcpy to an unaligned address
On 8/5/05, Carl Whitwell <[EMAIL PROTECTED]> wrote: > On 8/4/05, Shaun Jackman <[EMAIL PROTECTED]> wrote: > > Are you using an x86 host and an arm target? > > Actually no, my major concern at the time was the large quantity of > legacy code with packed structures that we have on an embedded linux > x86 system. I was just testing that we didn't have an issue there with > the structure access. The x86 includes hardware to fetch a word from an unaligned address by fetching from two aligned address and shifting and combining to produce the correct result. So, unaligned accesses on the x86 might effect a slight performance hit, but they will still act correctly. The ARM on the other hand does not include such hardware, so a load instruction fetching from an unaligned address will behave incorrectly. My primary concern is really just code correctness. Cheers, Shaun
RE: GNU Fortran Compiler
On Fri, 5 Aug 2005, Dave Korn wrote: Hallo, what must I do for becomming the GNU Fortran Compiler? Sincerely, Hans. To become the compiler, you must _think_ like the compiler. It's an easy mistake to make for Germans speaking English, because the German verb "bekommen" means "to get, obtain, receive"... Nick
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE
Hi Diego,
On Fri, 5 Aug 2005, Diego Novillo wrote:
> In PR 23046 we ICE inside tree-vrp.c because fold() does not
> realize that for
>
> enum enumtype { ENUM1, ENUM2 } x;
>
> the predicate 'if (x > 1)' is always false. This causes VRP to
> create the impossible range [2, 1] for that predicate.
>
> While it would be trivial for VRP to paper over this problem, the
> real fix should be in fold(). I looked at the logic that detects
> these cases and it is fairly convoluted (fold-const.c:9174).
>
> I'm wondering why doesn't fold() just use TYPE_MAX_VALUE/TYPE_MIN_VALUE
> if they're available?
I'm trying to remember/find the conclusions of the many discussions
on the ranges of enumeral types, that we've had in the past.
One of the explanations describing the problems in this area was
at http://gcc.gnu.org/ml/gcc-patches/2004-05/msg02002.html
There was also a huge thread (famewar?) at the time over the issue
which began at http://gcc.gnu.org/ml/gcc/2004-08/msg01129.html
One of the fundamental problem/contentious issues was whether GCC
guarantees that enumeral variables are always truncated and sign
or zero extended when assigned from integers, or whether the optimizers
can take advantage of the of the fact that the stored representation
is always in its enumerated range.
A related discussion can also be found in the thread following
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00968.html
Perhaps the issue may now be closer the resolution than in was last
time around. But the uneasy "detente" is that the middle-end currently
treats enumerated types as having the widths of their machine modes.
Perhaps things have now changed significantly since the last time this
was discussed, I have no vested interest in one side vs. the other, other
than the semantics need to be consistent lest the same kinds of tree-ssa
bugs resurface again.
I hope this helps. My personal advice, assuming that you're looking
for an easy life, is to place the seemingly unnessary consistency checks
in VRP. Some of the cases discussed in the above threads might make
interesting tests for the VRP code. I'll admit some of this "lore" should
be documented, but the issue has never been satisfactorily resolved to
everyone's satisfaction, so we keep with the less than idea "status quo".
Roger
--
RE: GNU Fortran Compiler
Original Message >From: Nicholas Nethercote >Sent: 05 August 2005 17:15 > On Fri, 5 Aug 2005, Dave Korn wrote: > >>> Hallo, >>> what must I do for becomming the GNU Fortran Compiler? >>> Sincerely, Hans. >> >> To become the compiler, you must _think_ like the compiler. > > It's an easy mistake to make for Germans speaking English, because the > German verb "bekommen" means "to get, obtain, receive"... > > Nick Thank you for the explanation! (I thought he wanted to become a contributor because he Cc'd the assign address.) cheers, DaveK -- Can't think of a witty .sigline today
successful gcc 4.0.1 build on alpha ev68
Debian GNU/Linux 3.1 using a custom-built 2.4.27 smp kernel and glibc 2.3.2.ds1-22: $ config.guess alphaev68-unknown-linux-gnu $ gcc -v Using built-in specs. Target: alphaev68-unknown-linux-gnu Configured with: ../gcc-4.0.1/configure --prefix=/opt/gcc-4.0.1 Thread model: posix gcc version 4.0.1 $ uname -srvmo Linux 2.4.27 #1 SMP Fri Aug 5 05:27:09 CEST 2005 alpha GNU/Linux -- Best regards, Andreas Bolkamailto:[EMAIL PROTECTED]
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE
On Fri, 2005-08-05 at 09:59 -0400, Diego Novillo wrote:
> In PR 23046 we ICE inside tree-vrp.c because fold() does not
> realize that for
>
> enum enumtype { ENUM1, ENUM2 } x;
>
> the predicate 'if (x > 1)' is always false. This causes VRP to
> create the impossible range [2, 1] for that predicate.
>
> While it would be trivial for VRP to paper over this problem, the
> real fix should be in fold(). I looked at the logic that detects
> these cases and it is fairly convoluted (fold-const.c:9174).
>
> I'm wondering why doesn't fold() just use TYPE_MAX_VALUE/TYPE_MIN_VALUE
> if they're available?
IIRC the C standard does not guarantee that an object stay within
the bounds of its enumerated type. You'll have to do some digging
in the relevant standards.
jeff
Template instantiation stack messages "staggered" -- why?
Hi all, Something about GCC's instantiation stack messages seems curious to me: for a given stack layer, the location in the message is not that of the template instance name that appears in the same message, but instead the point of instantiation of a template instance named in the immediately preceding message. (So the shallowest point of instantiation is always given in a message that reads "instantiated from here".) I can't see anything wrong with this approach, but I can't see the advantage either. (AFAIK, GCC is unique in this respect: there are other compilers that produce instantiation stacks, but for each of the ones that I've seen, each stack message contains both a template instance name and its corresponding POI.) James Widman -- Gimpel Software http://gimpel.com
Re: Template instantiation stack messages "staggered" -- why?
On Aug 5, 2005, at 2:22 PM, James Widman wrote: Hi all, Something about GCC's instantiation stack messages seems curious to me: for a given stack layer, the location in the message is not that of the template instance name that appears in the same message, but instead the point of instantiation of a template instance named in the immediately preceding message. (So the shallowest point of instantiation is always given in a message that reads "instantiated from here".) I realise that ISO 14.6.4.1 defines "point of instantiation" to mean something different from the meaning I implied above, but I couldn't think of a correct short descriptor for those locations. James Widman -- Gimpel Software http://gimpel.com
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
On Fri, Aug 05, 2005 at 11:57:45AM -0600, Jeffrey A Law wrote: > IIRC the C standard does not guarantee that an object stay within > the bounds of its enumerated type. You'll have to do some digging > in the relevant standards. For the record, I believe we've addressed these issues sometime within the last year or two. The TYPE_MIN/MAX_VALUE for an enum should be set to the range truely required by the relevant language standards (different between C and C++). I don't know for a fact that Ada has been adjusted for this though. The minimum Definitely Correct change at the moment appears to be -int width = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (arg1))); +int width = TYPE_PRECISION (TREE_TYPE (arg1)); But if an Ada developer can verify that enumerations are correctly created, we can delete about 100 lines of code. Which would be nice. r~
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
The TYPE_MIN/MAX_VALUE for an enum should be set to the range truely required by the relevant language standards (different between C and C++). I don't know for a fact that Ada has been adjusted for this though. But if an Ada developer can verify that enumerations are correctly created, we can delete about 100 lines of code. Which would be nice. I'm not sure I understand what "correct" means in this context. Ada just calls make_signed_type or make_unsigned_type and changes it to an ENUMERAL_TYPE. But it's pretty trivial to do whatever "correct" is, so if you're specific, it's easy to do. (There's not much code involved: it's case E_Enumeration_Type in ada/decl.c:gnat_to_gnu_entity.)
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Richard Henderson:
> For the record, I believe we've addressed these issues sometime
> within the last year or two. The TYPE_MIN/MAX_VALUE for an enum
> should be set to the range truely required by the relevant language
> standards (different between C and C++).
>
> I don't know for a fact that Ada has been adjusted for this though.
>From GIGI (around line 4115 in declc):
if ((kind == E_Enumeration_Type && Present (First_Literal (gnat_entity)))
|| (kind == E_Floating_Point_Type && !Vax_Float (gnat_entity)))
{
tree gnu_scalar_type = gnu_type;
[...]
TYPE_MIN_VALUE (gnu_scalar_type)
= gnat_to_gnu (Type_Low_Bound (gnat_entity));
TYPE_MAX_VALUE (gnu_scalar_type)
= gnat_to_gnu (Type_High_Bound (gnat_entity));
This is wrong (as discussed before) and is likely the cause of PR21573
(not VRP-related, the expanders for SWITCH_EXPR look at these
attributes, too). I'm not sure if it is safe to delete these
assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
quite extensively throught GIGI.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
This is wrong (as discussed before) and is likely the cause of PR21573 (not VRP-related, the expanders for SWITCH_EXPR look at these attributes, too). I'm not sure if it is safe to delete these assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used quite extensively throught GIGI. Well, what *should* they be set to? That is indeed setting them to the minimum and maximum values as defined by the language.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Richard Kenner: > This is wrong (as discussed before) and is likely the cause of PR21573 > (not VRP-related, the expanders for SWITCH_EXPR look at these > attributes, too). I'm not sure if it is safe to delete these > assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used > quite extensively throught GIGI. > > Well, what *should* they be set to? That is indeed setting them to the > minimum and maximum values as defined by the language. No, the language (or, more precisely, GNAT) defines them as 0 and 2**size - 1. Otherwise the 'Valid attribute doesn't work. Necessary range checks will be optimized away, too.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
No, the language (or, more precisely, GNAT) defines them as 0 and 2**size - 1. Otherwise the 'Valid attribute doesn't work. Necessary range checks will be optimized away, too. No, enumeration types are defined as having precisely the set of values specifically listed. In the presence of rep clauses, these may not even be a contiguous set. The language doesn't define the concept of a "base type" for enumeration types, but I think Gigi has to pretend there is such a thing and make it the full range of the underlying precision. That would make the enumeration type a subtype. The problem is that I think there's code in the middle-end that assumes that all subtypes are INTEGER_TYPE, so there's a real mess here about what should be done. But there's no question that the type directly corresponding to the Ada type needs the proper bounds: the issue is that we may be able to promote computations in it into a wider type corresponding to the "base type" of integers.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Richard Kenner: > No, the language (or, more precisely, GNAT) defines them as 0 and > 2**size - 1. Otherwise the 'Valid attribute doesn't work. Necessary > range checks will be optimized away, too. > > No, enumeration types are defined as having precisely the set of > values specifically listed. This is simply not true for Ada. Look at the definition of the 'Valid attribute in the standard: 3. X'Valid Yields True if and only if the object denoted by X is normal and has a valid representation. The value of this attribute is of the predefined type Boolean. If your claim were true, 'Valid could never return False for enumeration types.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote: > TYPE_MIN_VALUE (gnu_scalar_type) > = gnat_to_gnu (Type_Low_Bound (gnat_entity)); > TYPE_MAX_VALUE (gnu_scalar_type) > = gnat_to_gnu (Type_High_Bound (gnat_entity)); > > This is wrong (as discussed before) and is likely the cause of PR21573 > (not VRP-related, the expanders for SWITCH_EXPR look at these > attributes, too). I'm not sure if it is safe to delete these > assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used > quite extensively throught GIGI. Well, perhaps yes, perhaps no. What I don't know is if it is actively illegal to assign 0 to an enumeration that doesn't contain 0 as a member. It's clear that if it is in fact illegal, that the Ada front end has to use some other type than the enumeration to validate the values going into the enumeration. Which could be construed as the case with 21573 -- we should have used an int32_t equivalent instead of the enumeration. r~
Re: Wrong ChangeLog entries
Giovanni Bajo wrote:
Mark,
- with your commit for PR 20142, you also committed a hunk to name-lookup.c
which is not described in the ChangeLog. It is also unclear whether it is
effectively need for that PR or not, but nonetheless it went in, so the entry
should probably be fixed.
Thanks for spotting that. It was a harmless, but, as far as I can tell,
spurious check-in. I tested that removing it caused no regression on
x86_64-linux-gnu, so I'm going to remove it. Patch below.
- It is unclear which patch fixed PR 19063, which patch fixed PR 13268, or if
the same patch fixed both.
The same patch fixed both. Part of the confusion here comes from the
fact that PR19063 contains references to a source file called PR13628.
I think that's part of how I got tangled.
* Both bugs were closed at the same time, but the ChangeLog entry does not
mention PR 19063.
That's confusing; I'll fix testsuite/ChangeLog to say 19063.
* In the testsuite, I cannot find a testcase for PR13268, I can only find a
testcase for PR 19063 (g++.dg/template/crash31.C), and the testcase is also
wrong (contains a typo, so it does not probably test what it was supposed to
test).
That was an intentional change. The test case in the PR:
template struct A {};
is confusing, since it looks like "operator" is a template argument. In
fact, the parser (correctly) sees that as "operator>" and there is no
closing ">" symbol.
If those bugs were duplicates, it should have probably be mentioned in both the
ChangeLog and the bug description; also one should be closed as duplicate of
the other, instead of simply marked as "fixed".
I don't think it makes sense to put duplicate information in ChangeLogs;
I find the fact that we put PR#s in ChangeLogs and testcases to be
redundant enough. :-) However, I do very much agree that I made a hash
of this, and that they should be marked as duplicates in Bugzilla.
So, to some up:
1. I reverted the name-lookup.c patch.
2. I changed testsuite/ChangeLog to say 19063.
3. I marked 13268 as a duplicate of 19063 in bugzilla.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
2005-08-05 Mark Mitchell <[EMAIL PROTECTED]>
* name-lookup.c (pushtag): Remove accidental commit from:
2004-12-21 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/19063
* decl.c (grokdeclarator): Return error_mark_node, not
void_type_node, to indicate errors.
* parser.c (cp_parser_template_parameter_list): Robustify.
(cp_parser_template_parameter): Likewise.
Index: cp/name-lookup.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/name-lookup.c,v
retrieving revision 1.133
diff -c -5 -p -r1.133 name-lookup.c
*** cp/name-lookup.c1 Aug 2005 04:02:26 - 1.133
--- cp/name-lookup.c5 Aug 2005 20:59:31 -
*** pushtag (tree name, tree type, tag_scope
*** 4711,4723
pushdecl_class_level (d);
}
else if (b->kind != sk_template_parms)
d = pushdecl_with_scope (d, b);
- if (d == error_mark_node)
- POP_TIMEVAR_AND_RETURN (TV_NAME_LOOKUP, error_mark_node);
-
TYPE_CONTEXT (type) = DECL_CONTEXT (d);
/* If this is a local class, keep track of it. We need this
information for name-mangling, and so that it is possible to find
all function definitions in a translation unit in a convenient
--- 4711,4720
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Richard Henderson: > On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote: >> TYPE_MIN_VALUE (gnu_scalar_type) >> = gnat_to_gnu (Type_Low_Bound (gnat_entity)); >> TYPE_MAX_VALUE (gnu_scalar_type) >> = gnat_to_gnu (Type_High_Bound (gnat_entity)); >> >> This is wrong (as discussed before) and is likely the cause of PR21573 >> (not VRP-related, the expanders for SWITCH_EXPR look at these >> attributes, too). I'm not sure if it is safe to delete these >> assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used >> quite extensively throught GIGI. > > Well, perhaps yes, perhaps no. What I don't know is if it is > actively illegal to assign 0 to an enumeration that doesn't > contain 0 as a member. Illegal from which viewpoint? Language definition or GCC optimizers? > It's clear that if it is in fact illegal, that the Ada front > end has to use some other type than the enumeration to validate > the values going into the enumeration. In the Ada case, all the necessary compile-time checks should be performed by the front end anyway.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
This is simply not true for Ada. Look at the definition of the 'Valid attribute in the standard: 3. X'Valid Yields True if and only if the object denoted by X is normal and has a valid representation. The value of this attribute is of the predefined type Boolean. Right. That says what a "valid representation" is. Except for the result of an unchecked_conversion being given as the operand of 'Valid, any other value in that type is erroneous. If your claim were true, 'Valid could never return False for enumeration types. I think you misunderstand what 'Valid is. It tests for objects being *in the type*. If the type were in fact the full range, then 'Valid would always return True.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
Well, perhaps yes, perhaps no. What I don't know is if it is actively illegal to assign 0 to an enumeration that doesn't contain 0 as a member. It's not "illegal", but there's no way to do it in the language without using an Unchecked_Conversion (or similar sorts of punning). And if the Unchecked_Conversion produced a result that did not correspond to the value of an enumeration literal, the only non-erroneous use of that value is as the operand of 'Valid.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
* Richard Kenner: > This is simply not true for Ada. Look at the definition of the 'Valid > attribute in the standard: > >3. X'Valid > > Yields True if and only if the object denoted by X is normal > and has a valid representation. The value of this attribute > is of the predefined type Boolean. > > Right. That says what a "valid representation" is. Except for the > result of an unchecked_conversion being given as the operand of 'Valid, > any other value in that type is erroneous. Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity Checking) require that such reads are NOT erroneous.
Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)
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.
Re: Problems bootstrapping mainline on cygwin: warning: ./cc1-checksum.o ./cc1obj-checksum.o ./cc1plus-checksum.o libgcc/_chkstk.o differ
Christian Joensson wrote: warning: ./cc1-checksum.o differs warning: ./cc1obj-checksum.o differs warning: ./cc1plus-checksum.o differs what does that mean?? the compare passes... and the build continues... The checksums are used for PCH validatation. We generate md5 checksums for each cc1 binary, write them into the PCH files, and then check them when reading PCH files to make sure the right PCH files are used with the right compiler binaries. If the checksums differ, then this could be an assembler/linker issue for the target that makes it difficult to generate repeatable checksums of executable files during a bootstrap, or it could mean a portability problem with the code that generates the checksums. It does not mean a compiler code generation error. Hence it is a warning instead of an error that stops the bootstrap. See the checksum related rules in the Makefile, and the genchecksum.c file. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
c++ performance regressions in gcc > 2.95.3
We observed that certain large C++ applications perform worse in gcc-3.x and gcc-4.x than they did in gcc-2.95.3. On the theory that at least some of the cause would show up in microbenchmarks, we tried running bench++ with both old and new toolchains. Because we suspect that part of the regression is due to libstdc++, we also measured performance using stlport. Here are our results. A table of nanoseconds-per-iteration for each individual microbenchmark in bench++ for g++-2.95.3, and for g++-4.0.1 and g++-4.1.0-20050723 with and without STLport, is at http://www.cis.udel.edu/~danalis/OSS/bench_plus_plus/files/report-f15_m2_X_2.6-absolute.txt A table normalized relative to the gcc-2.95.3 results is at http://www.cis.udel.edu/~danalis/OSS/bench_plus_plus/files/report-f15_m2_X_2.6.txt The interesting bits are summarized in a table showing just the performance regressions, and annotated with descriptions of the microbenchmarks which regressed. It's at http://www.cis.udel.edu/~danalis/OSS/bench_plus_plus/results.html We reported one of the regressions already as http://gcc.gnu.org/PR22563 . There seem to be at least ten others that might be worth reporting. I'll try to post bug reports for a few, but my summer internship is running out soon. If anyone else has time to look at the data, I'd appreciate suggestions or criticism; maybe I can fix a few problems in my benchmark scripts before I turn into a pumpkin. Anthony Danalis & Dan Kegel
Re: IPA branch
Hi, Patch from Michael Matz (http://gcc.gnu.org/ml/fortran/2005-07/msg00331.html) may partly fixes the multiple decls problems. I've tested and tuned this patch. It works, small functions can be inlined after DECL_INLINE flags (build_function_decl in trans-decl.c) have been set for them. The only regression is FORTRAN 95 testcase function_modulo_1.f90, it produces a wong result. Canqun Yang Creative Compiler Research Group. National University of Defense Technology, China.
GCC 4.0.1 - iostream: No such file or dir....
I finally got 4.0.1 built in msys. I must have screwed up my msys/gcc
setup because a clean install of msys and gcc-3.4.1 worked. I started
with a simple test:
main.cpp:
~~
#include
int main()
{
cout << "Hello\n";
return 0;
}
then I try and build it:
~~
[EMAIL PROTECTED] /d/tmp/simple$ g++ main.cpp -o main
main.cpp:1:20: error: iostream: No such file or directory
main.cpp: In function 'int main()':
main.cpp:5: error: 'cout' was not declared in this scope
I looked thru in /mingw/include/c++/4.0.1 and iostream exists in that
directory. Is there something I'm missing? Do you need to specify gcc's
include directories explicitly now?
Thank you
Chris
My system details:
WinXP Pro
GCC 3.4.1
Msys
config cmd:
~~
../gcc-4.0.1/configure \
--prefix=/mingw \
--with-gcc \
--with-gnu-ld \
--with-gnu-as \
--enable-threads \
--disable-shared \
--disable-nls \
--enable-languages=c,c++,f95 \
--disable-win32-registry \
--with-gmp=/usr/local/gmp-4.1.4
make cmd:
~~
make \
CFLAGS="-O2 -march=i686 -fomit-frame-pointer" \
CXXFLAGS="-mthreads -O2 -march=i686 -fomit-frame-pointer" \
LIBCFLAGS="-O2" \
LIBCXXFLAGS="-O2 -fno-implicit-templates" \
LDFLAGS="-s" \
bootstrap
PACTH: Fix dejagnu for SMP
I have seen random "make check" failures in gcc on Linux/x86-64 SMP
machines. The log file doesn't say much except for compiler exit
status 1. When I ran the failed command by hand, it was OK.
I think the problem is in lib/remote.exp:
expect {
-i $spawn_id -timeout $timeout -re ".+" {
append output $expect_out(buffer)
if { [string length $output] < 512000 } {
exp_continue -continue_timer
}
}
timeout {
warning "program timed out."
}
eof {
set got_eof 1
}
}
...
set r2 [catch "wait -i $spawn_id" wres]
if { $id > 0 } {
set r2 [catch "close $id" res]
} else {
verbose "waitres is $wres" 2
if { $r2 == 0 } {
set r2 [lindex $wres 3]
if { [llength $wres] > 4 } {
if { [lindex $wres 4] == "CHILDKILLED" } {
set r2 1
}
But the expect command will close the connection when it sees EOF. On
SMP machine, close the connection may send SIGHUP to the child and
cause it to exit before it can exit normally. In this case,
set r2 [catch "wait -i $spawn_id" wres]
will return "CHILDKILLED SIGHUP hangup". This patch will make sure
that compiler will ignore SIGHUP sent by expect when it sees EOF.
H.J.
--- dejagnu-1.4.4/lib/remote.exp.smp2003-10-10 23:42:46.0 -0700
+++ dejagnu-1.4.4/lib/remote.exp2005-08-05 12:32:10.107161990 -0700
@@ -91,9 +91,13 @@ proc local_exec { commandline inp outp t
# programs that bear children. We can't use tcl's exec because it has
# no way to timeout programs that hang. *sigh*
#
+# The expect command will close the connection when it sees EOF. On
+# SMP machine, close the connection may send SIGHUP to the child
+# and cause it to exit before it can exit normally. We should make
+# the child to ignore SIGHUP.
if { "$inp" == "" && "$outp" == "" } {
set id -1
- set result [catch "eval spawn \{${commandline}\}" pid]
+ set result [catch "eval spawn -ignore SIGHUP \{${commandline}\}" pid]
if { $result == 0 } {
set result2 0
} else {
@@ -134,7 +138,7 @@ proc local_exec { commandline inp outp t
return [list -1 "open of $commandline $inp $outp failed:
$errorInfo"]
}
set pid [pid $id]
- set result [catch "spawn -leaveopen $id" result2]
+ set result [catch "spawn -ignore SIGHUP -leaveopen $id" result2]
}
# Prepend "-" to each pid, to generate the "process group IDs" needed by
# kill.
Re: IPA branch
On Aug 5, 2005, at 9:24 PM, Canqun Yang wrote: Hi, Patch from Michael Matz (http://gcc.gnu.org/ml/fortran/2005-07/msg00331.html) may partly fixes the multiple decls problems. That will only help with the fortran problem, the C++ front-end have the same issue. The C front-end have still some issues but most of the problems with multiple decls in the C front-end was fixed in 4.0.0. -- pinski
