Re: GCC 4.0.2 Released
Ulrich Weigand wrote: > Mark Mitchell wrote: > > >>GCC 4.0.2 has been released. > > > Results on s390(x)-ibm-linux are here: > http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01323.html > http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01324.html > > Unfortunately, it is not zero-FAIL after all; at the last > minute this one appears to have crept in: > FAIL: g++.dg/template/array14.C (test for excess errors) > > The error is: > array14.C: In function 'void t(int)': > array14.C:9: error: invalid lvalue in unary '&' > > Any idea what this is all about? No, that's very weird; that was PR 23993, which I fixed. Or, thought I did. It's definitely fixed for me on x86_64-unknown-linux-gnu. But, the nature of the bug didn't seem at all system-dependent. I've checked that I have no local patches in my GCC 4.0.x tree. So, I'm pretty mystified... -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Aliasing violation generated by fold_builtin_memcmp?
Richard Henderson wrote: > Try > > cst_uchar_ptr_node > = build_pointer_type_for_mode (cst_uchar_node, ptr_mode, true); > > which is apparently in use by the Ada front end, but only if a > certain pragma is given. Dunno how reliably that's likely to work. We are seeing regressions in our local testsuite on cases exercising that pragma. Passing 'true' as CAN_ALIAS_ALL sets TYPE_REF_CAN_ALIAS_ALL (t), but this apparently has no influence on what tree-ssa-alias computes. Out of a preliminary look into this code (new to me), a possible place to address that appears to be 'get_tmt_for', which presumably should assign a zero alias set to tags for pointer types with that bit set. The current code doesn't do that: tree tag_type = TREE_TYPE (TREE_TYPE (ptr)); HOST_WIDE_INT tag_set = get_alias_set (tag_type); I'd be happy to work-on and submit a patch to deal with this the proper way. I'd welcome hints or directions on what the proper way should be, as I don't yet have a global view of the complete alias analysis circuitry. The 'tag alias set should be zero if ...' idea above seems logical to me. I still may well not yet see a number of other options.
Re: Any plan to support Windows/x86-64?
Hi H. J. Is there any plan to support Windows/x86-64? No and yes. I think that we would like to support this target, but we just need contributers to work on it. (I am pretty sure that some people are working on it, but they may not be ready to contribute yet). What are needed for the port? Support for the 64-bit PE file format I guess. Cheers Nick
[gomp] build problem
Hi, I just checked out gomp-20050608-branch from the CVS and tried to compile it. This is the error I got: gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -Icp -I../.././gcc -I../.././gcc/cp -I../.././gcc/../include -I../.././gcc/../libcpp/include ../.././gcc/cp/cp-lang.c -o cp/cp-lang.o In file included from ../../gcc/cp/cp-tree.h:33, from ../../gcc/cp/cp-lang.c:27: ../../gcc/cp/name-lookup.h:315: conflicting types for `lookup_name' ../../gcc/c-common.h:783: previous declaration of `lookup_name' I tried to take look, but it doesn't seem to be a simple typo. both declarations of 'lookup_name' have coresponding definitions. Do you have any idea what is wrong? Best regards Marcin
Re: GCC 4.0.2 Released
Mark Mitchell wrote: > No, that's very weird; that was PR 23993, which I fixed. Or, thought I > did. It's definitely fixed for me on x86_64-unknown-linux-gnu. But, > the nature of the bug didn't seem at all system-dependent. I've checked > that I have no local patches in my GCC 4.0.x tree. So, I'm pretty > mystified... Well, current 4_0 branch fixes the problem for me too. It appears that the test case made it into the release, but the fix didn't ... Comparing the cp/ChangeLog files from 4.0.2 and the 4_0 branch, it looks like the fix is in the release according to the current ChangeLog, but in fact it wasn't: [EMAIL PROTECTED] fsf]$ diff -u gcc-4.0.2/gcc/cp/ChangeLog gcc-4_0/gcc/cp/ChangeLog --- gcc-4.0.2/gcc/cp/ChangeLog 2005-09-21 05:56:51.0 +0200 +++ gcc-4_0/gcc/cp/ChangeLog2005-09-30 12:40:52.0 +0200 @@ -1,7 +1,19 @@ -2005-09-20 Release Manager +2005-09-29 Jakub Jelinek <[EMAIL PROTECTED]> + + PR c++/21983 + * class.c (find_final_overrider): Move diagnostic about no unique final + overrider to... + (update_vtable_entry_for_fn): ... here. + +2005-09-27 Release Manager * GCC 4.0.2 released. +2005-09-21 Mark Mitchell <[EMAIL PROTECTED]> + + PR c++/23993 + * init.c (integral_constant_value): Use DECL_INTEGRAL_CONSTANT_VAR_P. + 2005-09-16 Mark Mitchell <[EMAIL PROTECTED]> PR c++/23914 -- Dr. Ulrich Weigand Linux on zSeries Development [EMAIL PROTECTED]
Re: [gomp] build problem
On September 30, 2005 09:15, [EMAIL PROTECTED] wrote: > ../../gcc/cp/name-lookup.h:315: conflicting types for `lookup_name' > ../../gcc/c-common.h:783: previous declaration of `lookup_name' > There are two conflicting definitions for lookup_name between C and C++. For now the best approach is to configure with C++ disabled (--enable-languages=fortran,c) until Richard has had a chance to fix the double declaration.
Re: Aliasing violation generated by fold_builtin_memcmp?
On Fri, 2005-09-30 at 11:23 +0200, Olivier Hainque wrote: > Richard Henderson wrote: > > Try > > > > cst_uchar_ptr_node > > = build_pointer_type_for_mode (cst_uchar_node, ptr_mode, true); > > > > which is apparently in use by the Ada front end, but only if a > > certain pragma is given. Dunno how reliably that's likely to work. > > We are seeing regressions in our local testsuite on cases exercising > that pragma. > > Passing 'true' as CAN_ALIAS_ALL sets TYPE_REF_CAN_ALIAS_ALL (t), but > this apparently has no influence on what tree-ssa-alias computes. > > Out of a preliminary look into this code (new to me), a possible place > to address that appears to be 'get_tmt_for', which presumably should assign > a zero alias set to tags for pointer types with that bit set. Actually, you just want it to assign the same tag, not change the alias set of every tag it assigns.
Re: Aliasing violation generated by fold_builtin_memcmp?
Daniel Berlin wrote: > > Out of a preliminary look into this code (new to me), a possible > > place to address that appears to be 'get_tmt_for', which > > presumably should assign a zero alias set to tags for pointer > > types with that bit set. > Actually, you just want it to assign the same tag, not change the alias > set of every tag it assigns. Humm, and still have the corresponding alias set zero to ensure it conflicts with everything, right ? In which case almost all the bits are in already, since get_tmt_for already reuses a previously created tag if it assigned the same alias set. I tried this on a couple of testcases yesterday, and it worked fine. I am still unclear on one point: is it fine to reuse the same tag for possibly different designated types ?
Re: Aliasing violation generated by fold_builtin_memcmp?
On Fri, 2005-09-30 at 15:54 +0200, Olivier Hainque wrote: > Daniel Berlin wrote: > > > Out of a preliminary look into this code (new to me), a possible > > > place to address that appears to be 'get_tmt_for', which > > > presumably should assign a zero alias set to tags for pointer > > > types with that bit set. > > > Actually, you just want it to assign the same tag, not change the alias > > set of every tag it assigns. > > Humm, and still have the corresponding alias set zero to ensure it conflicts > with everything, right ? Yes. :) > > In which case almost all the bits are in already, since get_tmt_for > already reuses a previously created tag if it assigned the same alias set. > > I tried this on a couple of testcases yesterday, and it worked fine. > > I am still unclear on one point: is it fine to reuse the same tag for > possibly different designated types ? Yes, as long as they have the same alias set. > > > > > > > > >
Re: Aliasing violation generated by fold_builtin_memcmp?
Daniel Berlin wrote: > > I am still unclear on one point: is it fine to reuse the same tag for > > possibly different designated types ? > > Yes, as long as they have the same alias set. OK. A last detail: On the first tag_set 0 creation, we get into: if (var_ann (ptr)->type_mem_tag == NULL_TREE) tag = create_memory_tag (tag_type, true); and, if doing nothing special, trip on /* Make sure that the type tag has the same alias set as the pointed-to type. */ gcc_assert (tag_set == get_alias_set (tag)); I've relaxed the assert expression for experimentation purposes, but this is probably not the best thing to do. How would you prefer to see this addressed ?
Re: Aliasing violation generated by fold_builtin_memcmp?
On Fri, 2005-09-30 at 16:29 +0200, Olivier Hainque wrote: > Daniel Berlin wrote: > > > I am still unclear on one point: is it fine to reuse the same tag for > > > possibly different designated types ? > > > > Yes, as long as they have the same alias set. > > OK. A last detail: > > On the first tag_set 0 creation, we get into: > > if (var_ann (ptr)->type_mem_tag == NULL_TREE) > tag = create_memory_tag (tag_type, true); > > and, if doing nothing special, trip on > > /* Make sure that the type tag has the same alias set as the > pointed-to type. */ > gcc_assert (tag_set == get_alias_set (tag)); Well, doesn't the pointed-to type have set 0 because of TYPE_REF_CAN_ALIAS_ALL (or whatever it's named :P)? I'm a bit confused.
TYPE_MAIN_VARIANT(bitsizetype) one-liner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Sep 29, 2005 at 09:35:22AM -0700, Richard Henderson wrote:
> On Thu, Sep 29, 2005 at 07:32:46AM -0400, Richard Kenner wrote:
> > The real fix is below, though I haven't run it throuh a testing
> > cycle yet. I was wondering how this ever worked:
>
> Indeed this is clearly correct. And one does wonder how this missing
> line has managed to not cause problems elsewhere...
At first I thought that my half-hearted effort at writing a port (16-bit
x86) was failing only due to my uber GCC cluelessness, then I saw just
the right number of statistically unlikely phrases in the patch to pique
my interest.
Since a few weeks ago, during the building of my target libgcc, I get:
/mnt/disk2/src/gcc/gcc/libgcc2.h:378: error: size of array '__popcount_tab' is
too large 1
(The '1' refers to the first of two identical warnings.)
So I learned about dump_node() and applied this patch:
- --- c-decl.c.borigFri Sep 16 14:51:38 2005
+++ c-decl.cThu Sep 29 17:05:49 2005
@@ -4109,20 +4109,25 @@ grokdeclarator (const struct c_declarato
{
tree itype = NULL_TREE;
tree size = declarator->u.array.dimen;
/* The index is a signed object `sizetype' bits wide. */
tree index_type = c_common_signed_type (sizetype);
array_ptr_quals = declarator->u.array.quals;
array_ptr_attrs = declarator->u.array.attrs;
array_parm_static = declarator->u.array.static_p;
+ fprintf(stderr, " sizetype: \n");
+ dump_node(sizetype, 0, stderr);
+ fprintf(stderr, " index_type: \n");
+ dump_node(index_type, 0, stderr);
+
declarator = declarator->declarator;
/* Check for some types that there cannot be arrays of. */
if (VOID_TYPE_P (type))
{
error ("declaration of %qs as array of voids", name);
type = error_mark_node;
}
The result is this:
sizetype:
@1 integer_type name: @2 size: @3 algn: 8
prec: 8sign: unsigned min : @4
max : @5
@2 type_declname: @6 type: @7 srcp:
:0
@3 integer_cst type: @8 low : 8
@4 integer_cst type: @7 low : 0
@5 integer_cst type: @7 low : 255
@6 identifier_node strg: short unsigned int lngt: 18
@7 integer_type name: @2 size: @3 algn: 8
prec: 8sign: unsigned min : @4
max : @5
@8 integer_type name: @9 size: @10 algn: 16
prec: 12 sign: unsigned min : @11
max : @12
@9 identifier_node strg: bit_size_type lngt: 13
@10 integer_cst type: @8 low : 16
@11 integer_cst type: @8 low : 0
@12 integer_cst type: @8 low : 4095
index_type:
@1 integer_type name: @2 size: @3 algn: 8
prec: 8sign: signed min : @4
max : @5
@2 type_declname: @6 type: @1 srcp:
:0
@3 integer_cst type: @7 low : 8
@4 integer_cst type: @1 high: -1 low : -128
@5 integer_cst type: @1 low : 127
@6 identifier_node strg: signed char lngt: 11
@7 integer_type name: @8 size: @9 algn: 16
prec: 12 sign: unsigned min : @10
max : @11
@8 identifier_node strg: bit_size_type lngt: 13
@9 integer_cst type: @7 low : 16
@10 integer_cst type: @7 low : 0
@11 integer_cst type: @7 low : 4095
Does anyone know why index_type seems to be "signed char", which of
course cannot hold indices into __popcount_tab[256]?
[Sorry, no paperwork filed, therefore no show-and-tell to the list.]
- --
/"\ ASCII Ribbon Campaign - against html email
\ /- against microsoft office attachments
X - against text above fullquote below
/ \- against lines longer than 79 characters
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/
Comment: My current key expires in two weeks, please ask for ID checks now.
iD8DBQFDPU6R/FmLrNfLpjMRAmVoAJ9d1vHM4tcYAw+dMSuHJt/Pa6TGuwCfeAJs
K6VF/6OS+QnbdRcvGXZZSn4=
=F2Lc
-END PGP SIGNATURE-
Re: Aliasing violation generated by fold_builtin_memcmp?
Daniel Berlin wrote: > Well, doesn't the pointed-to type have set 0 because of > TYPE_REF_CAN_ALIAS_ALL (or whatever it's named :P)? Not quite: the pointer type has TYPE_REF_CAN_ALIAS_ALL, not the pointed-to type: /* Nonzero in a pointer or reference type means the data pointed to by this type can alias anything. */ #define TYPE_REF_CAN_ALIAS_ALL(NODE) \ (PTR_OR_REF_CHECK (NODE)->common.static_flag) It seems to me that get_tmt does not do the right thing today because it assigns the tag alias set from the alias set of the pointed-to type, even if CAN_ALIAS_ALL is set on the pointer type. Here is an example input tree out of an Ada testcase: sizes-gimplified public SI user align 32 symtab 0 alias set 3 sizes-gimplified public static unsigned SI ^^ user align 32 symtab 0 alias set -1> This is a pointer to integer which is declared "can actually alias anything".
Re: Aliasing violation generated by fold_builtin_memcmp?
On Fri, 2005-09-30 at 16:53 +0200, Olivier Hainque wrote: > Daniel Berlin wrote: > > Well, doesn't the pointed-to type have set 0 because of > > TYPE_REF_CAN_ALIAS_ALL (or whatever it's named :P)? > > Not quite: the pointer type has TYPE_REF_CAN_ALIAS_ALL, not the > pointed-to type: > >/* Nonzero in a pointer or reference type means the data pointed to > by this type can alias anything. */ >#define TYPE_REF_CAN_ALIAS_ALL(NODE) \ > (PTR_OR_REF_CHECK (NODE)->common.static_flag) > > It seems to me that get_tmt does not do the right thing today > because it assigns the tag alias set from the alias set of the > pointed-to type, even if CAN_ALIAS_ALL is set on the pointer type. Uh, CAN_ALIAS_ALL seems like a very bad hack then. You should simply be creating a pointed-to type that aliases set 0, and using that for the pointed to type. That is, after all, what alias set 0 is for.
Re: Aliasing violation generated by fold_builtin_memcmp?
Uh, CAN_ALIAS_ALL seems like a very bad hack then. You should simply be creating a pointed-to type that aliases set 0, and using that for the pointed to type. That is, after all, what alias set 0 is for. That's easy enough for integer types, but creating multiple record types means duplicating lots of fields and layouts and is, in general, a mess. What's special here is the pointer type, not the underlying type.
Re: Aliasing violation generated by fold_builtin_memcmp?
On Fri, 2005-09-30 at 11:20 -0400, Richard Kenner wrote: > Uh, CAN_ALIAS_ALL seems like a very bad hack then. > You should simply be creating a pointed-to type that aliases set 0, and > using that for the pointed to type. > That is, after all, what alias set 0 is for. > > That's easy enough for integer types, but creating multiple record types > means duplicating lots of fields and layouts and is, in general, a mess. But of course, it's the right thing to do when you've got one type that can be aliased to anything through a pointer, and the other cannot. > What's special here is the pointer type, not the underlying type. Which means that everywhere that handles pointer types and aliasing has to be modified to check this magic. I still claim it is a hack, and a very bad one. At the absolute least, it should be encapsulated in a function, maybe "get_alias_set_of_pointed_to_type" or something. --Dan
Question on bad counters.
I'm not entirely sure how gcc's CFG structure all fits together yet, so I'll ask for some input on this one: While looking through some dumps from a compile using -fprofile-use, I noticed the following in the "jump" dump file: Basic block 164 prev 163, next -2, loop_depth 0, count 1672, freq 1482. Predecessors: 163 [100.0%] count:836 (fallthru) Successors: EXIT [100.0%] count:1672 (fallthru) Invalid sum of incoming frequencies 741, should be 1482 Invalid sum of incoming counts 836, should be 1672 I decided to try and figure out why the sum of incoming frequencies was invalid. I've found where the mistake is introduced, and think I know what needs to be done to fix it, but perhaps someone can confirm or suggest an alternative. Here are the last few blocks dumped just before cfgbuild.find_bb_boundaries. The counts look good at this point (note especially block 162). Basic block 153 prev 152, next 154, loop_depth 0, count 836, freq 741. Predecessors: 0 [27.8%] count:232 12 151 [100.0%] count:604 152 [100.0%] (fallthru) Successors: 162 [100.0%] count:836 Basic block 154 prev 153, next 155, loop_depth 1, count 195, freq 173, probably never executed. Predecessors: 72 [8.1%] count:36 74 [39.0%] count:159 73 159 [100.0%] Successors: 78 [66.7%] count:130 155 [33.3%] count:65 (fallthru) Basic block 155 prev 154, next 162, loop_depth 0, count 65, freq 58, probably never executed. Predecessors: 154 [33.3%] count:65 (fallthru) Successors: 79 [100.0%] count:65 Basic block 162 prev 155, next -2, loop_depth 0, count 836, freq 741. Predecessors: 153 [100.0%] count:836 Successors: EXIT [100.0%] count:836 (fallthru) - After cfgbuild.find_bb_boundaries, there are a few new blocks, and block 162 has been disconnected from the graph. Block 162 has no predecessors, yet it's count remains at 836 and it's frequency at 741 which are invalid. I believe blocks 163 and 164 were created while splitting block 162, and thus inherited the same count and frequency. Basic block 153 prev 152, next 154, loop_depth 0, count 836, freq 741. Predecessors: 0 [27.8%] count:232 12 151 [100.0%] count:604 152 [100.0%] (fallthru) Successors: Basic block 154 prev 153, next 155, loop_depth 1, count 195, freq 173, probably never executed. Predecessors: 72 [8.1%] count:36 74 [39.0%] count:159 73 159 [100.0%] Successors: 78 [66.7%] count:130 155 [33.3%] count:65 (fallthru) Basic block 155 prev 154, next 162, loop_depth 0, count 65, freq 58, probably never executed. Predecessors: 154 [33.3%] count:65 (fallthru) Successors: 79 [100.0%] count:65 Basic block 162 prev 155, next 163, loop_depth 0, count 836, freq 741. Predecessors: Successors: Invalid sum of incoming frequencies 0, should be 741 Invalid sum of incoming counts 0, should be 836 Basic block 163 prev 162, next 164, loop_depth 0, count 836, freq 741. Predecessors: Successors: Invalid sum of incoming frequencies 0, should be 741 Invalid sum of incoming counts 0, should be 836 Basic block 164 prev 163, next -2, loop_depth 0, count 836, freq 741. Predecessors: Successors: EXIT [100.0%] count:836 (fallthru) Invalid sum of incoming frequencies 0, should be 741 Invalid sum of incoming counts 0, should be 836 - Later on, the cfg has apparently been rebuilt. Some of the blocks with bad counts were reattached to the graph and their counts propagated. The result is the invalid block count I initially observed. Note here that the count and frequency for block 164 are exactly double what they should be. Basic block 159 prev 158, next 160, loop_depth 0, count 836, freq 741. Predecessors: 1 [27.8%] count:232 13 157 [100.0%] count:604 158 [100.0%] (fallthru) Successors: 163 [100.0%] count:836 Basic block 160 prev 159, next 161, loop_depth 1, count 195, freq 173, probably never executed. Predecessors: 75 [8.1%] count:36 77 [39.0%] count:159 76 79 [100.0%] Successors: 82 [66.7%] count:130 161 [33.3%] count:65 (fallthru) Basic block 161 prev 160, next 163, loop_depth 0, count 65, freq 58, probably never executed. Predecessors: 160 [33.3%] count:65 (fallthru) Successors: 83 [100.0%] count:65 Basic block 163 prev 161, next 164, loop_depth 0, count 836, freq 741. Predecessors: 159 [100.0%] count:836 Successors: 164 [100.0%] count:836 (fallthru) Basic block 164 prev 163, next -2, loop_depth 0, count 1672, freq 1482. Predecessors: 163 [100.0%] count:836 (fallthru) Successors: EXIT [100.0%] count:1672 (fallthru) Invalid sum of incoming frequencies 741, should be 1482 Invalid sum of incoming counts 836, should be 1672 The problem appears to be in the function cfgrtl.purge_dead_edges which is called by find_bb_boundaries. There are a couple of cases where "remove_edge" is called to remove an edge from the graph. In the above example, the edge being removed is the only predecessor edge of the destination block(162). The edge is removed, but the count and frequency of the now orphaned destinati
Re: Question about updating CFG block counters in purge_dead_edges [was "Question on bad counters."]
Added a better subject line.. Pete. [EMAIL PROTECTED] wrote on 09/30/2005 11:03:59 AM: > > I'm not entirely sure how gcc's CFG structure all fits together yet, so > I'll ask for some input on this one: > > While looking through some dumps from a compile using -fprofile-use, I > noticed the following in the "jump" dump file: > > Basic block 164 prev 163, next -2, loop_depth 0, count 1672, freq 1482. > Predecessors: 163 [100.0%] count:836 (fallthru) > Successors: EXIT [100.0%] count:1672 (fallthru) > Invalid sum of incoming frequencies 741, should be 1482 > Invalid sum of incoming counts 836, should be 1672 > > I decided to try and figure out why the sum of incoming frequencies was > invalid. I've found where the mistake is introduced, and think I know what > needs to be done to fix it, but perhaps someone can confirm or suggest an > alternative. > > > > Here are the last few blocks dumped just before > cfgbuild.find_bb_boundaries. The counts look good at this point (note > especially block 162). > > Basic block 153 prev 152, next 154, loop_depth 0, count 836, freq 741. > Predecessors: 0 [27.8%] count:232 12 151 [100.0%] count:604 152 [100.0%] > (fallthru) > Successors: 162 [100.0%] count:836 > > Basic block 154 prev 153, next 155, loop_depth 1, count 195, freq 173, > probably never executed. > Predecessors: 72 [8.1%] count:36 74 [39.0%] count:159 73 159 [100.0%] > Successors: 78 [66.7%] count:130 155 [33.3%] count:65 (fallthru) > > Basic block 155 prev 154, next 162, loop_depth 0, count 65, freq 58, > probably never executed. > Predecessors: 154 [33.3%] count:65 (fallthru) > Successors: 79 [100.0%] count:65 > > Basic block 162 prev 155, next -2, loop_depth 0, count 836, freq 741. > Predecessors: 153 [100.0%] count:836 > Successors: EXIT [100.0%] count:836 (fallthru) > > > - > After cfgbuild.find_bb_boundaries, there are a few new blocks, and block > 162 has been disconnected from the graph. Block 162 has no predecessors, > yet it's count remains at 836 and it's frequency at 741 which are invalid. > I believe blocks 163 and 164 were created while splitting block 162, and > thus inherited the same count and frequency. > > > Basic block 153 prev 152, next 154, loop_depth 0, count 836, freq 741. > Predecessors: 0 [27.8%] count:232 12 151 [100.0%] count:604 152 [100.0%] > (fallthru) > Successors: > > Basic block 154 prev 153, next 155, loop_depth 1, count 195, freq 173, > probably never executed. > Predecessors: 72 [8.1%] count:36 74 [39.0%] count:159 73 159 [100.0%] > Successors: 78 [66.7%] count:130 155 [33.3%] count:65 (fallthru) > > Basic block 155 prev 154, next 162, loop_depth 0, count 65, freq 58, > probably never executed. > Predecessors: 154 [33.3%] count:65 (fallthru) > Successors: 79 [100.0%] count:65 > > Basic block 162 prev 155, next 163, loop_depth 0, count 836, freq 741. > Predecessors: > Successors: > Invalid sum of incoming frequencies 0, should be 741 > Invalid sum of incoming counts 0, should be 836 > > Basic block 163 prev 162, next 164, loop_depth 0, count 836, freq 741. > Predecessors: > Successors: > Invalid sum of incoming frequencies 0, should be 741 > Invalid sum of incoming counts 0, should be 836 > > Basic block 164 prev 163, next -2, loop_depth 0, count 836, freq 741. > Predecessors: > Successors: EXIT [100.0%] count:836 (fallthru) > Invalid sum of incoming frequencies 0, should be 741 > Invalid sum of incoming counts 0, should be 836 > > > - > Later on, the cfg has apparently been rebuilt. Some of the blocks with bad > counts were reattached to the graph and their counts propagated. The > result is the invalid block count I initially observed. Note here that the > count and frequency for block 164 are exactly double what they should be. > > Basic block 159 prev 158, next 160, loop_depth 0, count 836, freq 741. > Predecessors: 1 [27.8%] count:232 13 157 [100.0%] count:604 158 [100.0%] > (fallthru) > Successors: 163 [100.0%] count:836 > > Basic block 160 prev 159, next 161, loop_depth 1, count 195, freq 173, > probably never executed. > Predecessors: 75 [8.1%] count:36 77 [39.0%] count:159 76 79 [100.0%] > Successors: 82 [66.7%] count:130 161 [33.3%] count:65 (fallthru) > > Basic block 161 prev 160, next 163, loop_depth 0, count 65, freq 58, > probably never executed. > Predecessors: 160 [33.3%] count:65 (fallthru) > Successors: 83 [100.0%] count:65 > > Basic block 163 prev 161, next 164, loop_depth 0, count 836, freq 741. > Predecessors: 159 [100.0%] count:836 > Successors: 164 [100.0%] count:836 (fallthru) > > Basic block 164 prev 163, next -2, loop_depth 0, count 1672, freq 1482. > Predecessors: 163 [100.0%] count:836 (fallthru) > Successors: EXIT [100.0%] count:1672 (fallthru) > Invalid sum of incoming frequencies 741, should be 1482 > Invalid sum of incoming counts 836, should be 1672 > > > > > The problem appears to be in the function cfgrtl.purge_dead_edges which is > call
Re: Aliasing violation generated by fold_builtin_memcmp?
But of course, it's the right thing to do when you've got one type that can be aliased to anything through a pointer, and the other cannot. Sure, if that's what were going on, but it's not. What we have are two *pointer types*, both pointing at the same underlying type. Access via one of those pointer types is assumed to be aliasing anything and the other is not. The case in Ada is type r1 is record ... end record; type ar1 is access all r1; type r2 is record ... end record; type ar2 is access all r2; type ar2p is access all r2; function uc is new unchecked_conversion (ar1, ar2p); In this case, both ar2.all and ar2p.all are accessing r2. But accesses through ar2p must be presumed to access anything since we know that the underlying object might be an ar1. > What's special here is the pointer type, not the underlying type. Which means that everywhere that handles pointer types and aliasing has to be modified to check this magic. At the RTL level, there's just one place that computes the alias set of an expression and it knows about that flag. It was the only place that had to be modified to support it, as I recall. One would hope that knowlege of this semantics can be similarly localized at the tree level. Why can't it?
Re: GCC 4.0.2 Released
--- Ulrich Weigand wrote: > Comparing the cp/ChangeLog files from 4.0.2 and the > 4_0 branch, it looks > like the fix is in the release according to the > current ChangeLog, but > in fact it wasn't: Indeed, http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.412.2.9&r2=1.412.2.10 (the fix) applies cleanly onto the release package. ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: GCC 4.0.2 Released
Ulrich Weigand wrote:
> Comparing the cp/ChangeLog files from 4.0.2 and the 4_0 branch, it looks
> like the fix is in the release according to the current ChangeLog, but
> in fact it wasn't:
Indeed, cvs log confirms that the revision was made to cp/init.c on
September 22.
It appears that the release automation failed, and that, in fact, the
allegedly final GCC 4.0.2 bits are in fact the early version of GCC
4.0.2 that I never uploaded because of the last-minute changes for
Solaris and such.
I'm incredibly depressed.
I suspect that the reason for this is that gcc_release does:
inform "Tagging sources as ${TAG}"
# The -F option to CVS is intentionally not used below. If you
# need to retry a release, you will have to manually remove any
# existing tag.
${CVS} rtag -r ${CVSBRANCH} ${TAG} gcc || \
error "Could not tag sources"
EXPORTTAG="-r${TAG}"
and then:
${CVS} export -d "`basename ${SOURCE_DIRECTORY}`" \
"${EXPORTTAG}" gcc || \
I didn't realize that I had to manually remove the old tag.
Furthermore, I guess that "cvs rtag" did not fail (so the error case did
not occur), even though it did not move the tag. So, even though all
the right bits were checked in, they didn't end up in the exported
source directory.
I'm not sure what to do.
The bits that appear to be missing are the Solaris change to libstdc++:
2005-09-25 Benjamin Kosnik <[EMAIL PROTECTED]>
Eric Botcazou <[EMAIL PROTECTED]>
* include/ext/mt_allocator.h
(__per_type_pool<...true>::_S_initialize_once): Always call
_M_initialize_once.
(__common_pool<...true>::_S_initialize_once): Same.
and my change to C++:
2005-09-21 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/23993
* init.c (integral_constant_value): Use
DECL_INTEGRAL_CONSTANT_VAR_P.
and Andreas' change:
2005-09-21 Andreas Schwab <[EMAIL PROTECTED]>
PR rtl-optimization/23043
* postreload-gcse.c (eliminate_partially_redundant_load): Fix typo
when allocating a struct unoccr.
The key question is whether to do an immediate 4.0.3 to catch up to what
we intended. (That's not entirely trivial, in that things have now been
checked in on the 4.0 branch, so we would have to temporarily back out
some patches, or apply tags very carefully.) Or, we could do a 4.0.3
based on current bits.
My inclination is to do nothing (other than correct the target
milestones on these bugs in bugzilla) and move on. The Solaris problem
is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
a crisis meriting another release cycle. The C++ change fixed a
regression relative to 3.4.x, but not 4.0.x. Andreas' change is only
known to affect m68k.
I'd appreciate feedback. (I don't promise to be bound by the majority
view, though.)
I'd also appreciate suggestions for making the release script more
robust in this situation; clearly, depending on cvs rtag to fail is
clearly not sufficiently reliable.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: Aliasing violation generated by fold_builtin_memcmp?
On Fri, 2005-09-30 at 12:45 -0400, Richard Kenner wrote: > > What's special here is the pointer type, not the underlying type. > > Which means that everywhere that handles pointer types and aliasing has > to be modified to check this magic. > > At the RTL level, there's just one place that computes the alias set of an > expression and it knows about that flag. It was the only place that had > to be modified to support it, as I recall. One would hope that knowlege > of this semantics can be similarly localized at the tree level. Why can't it? Because the RTL level only supports type based aliasing, and very simple TBAA at that. You are saying that an access through this pointer can point to anything, regardless of what we think it points to. This leaves 3 or 4 places at the tree level that need to be changed, and possibly more later as more aliasing techniques are added.
Re: Aliasing violation generated by fold_builtin_memcmp?
Because the RTL level only supports type based aliasing, and very simple TBAA at that. But we're just talking about type-based aliasing. You are saying that an access through this pointer can point to anything, regardless of what we think it points to. No. If you know what it points to by value-based information, that can safely be used. The only thing is that you must use alias set 0 for any type-based information. This leaves 3 or 4 places at the tree level that need to be changed, and possibly more later as more aliasing techniques are added. I don't see why. Why is there more than one place that computes the alias set of what a pointer might point to?
Re: GCC 4.0.2 Released
On Fri, Sep 30, 2005 at 10:06:07AM -0700, Mark Mitchell wrote: > The key question is whether to do an immediate 4.0.3 to catch up to what > we intended. (That's not entirely trivial, in that things have now been > checked in on the 4.0 branch, so we would have to temporarily back out > some patches, or apply tags very carefully.) Or, we could do a 4.0.3 > based on current bits. > > My inclination is to do nothing (other than correct the target > milestones on these bugs in bugzilla) and move on. The Solaris problem > is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's > a crisis meriting another release cycle. The C++ change fixed a > regression relative to 3.4.x, but not 4.0.x. Andreas' change is only > known to affect m68k. ... but IIRC it cripples GCC for m68k; Debian turned up hundreds of build failures because of this bug and it set builds back several weeks. Personally, I'd do a 4.0.3 based on current bits. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Aliasing violation generated by fold_builtin_memcmp?
On Sep 29, 2005, at 8:32 PM, Daniel Berlin wrote:
Any suggestions how to fix this?
The easiest thing is to store a version of unsigned_char_type_node
somewhere that has it's TYPE_ALIAS_SET set to 0, and use it there.
Whether this is the best solution, i'll leave to others :)
Something like this will fix the issue with TYPE_REF_CAN_ALIAS_ALL
by removing the use. Maybe we could move may_alias to a bit in the
types and move TYPE_REF_CAN_ALIAS_ALL from the pointer type to the
type which is being accessed instead of this mess.
-- Pinski
Index: c-common.c
===
RCS file: /cvs/gcc/gcc/gcc/c-common.c,v
retrieving revision 1.653
diff -u -p -r1.653 c-common.c
--- c-common.c 27 Sep 2005 16:04:06 - 1.653
+++ c-common.c 30 Sep 2005 17:46:42 -
@@ -2668,9 +2668,6 @@ c_common_get_alias_set (tree t)
|| t == unsigned_char_type_node)
return 0;
- /* If it has the may_alias attribute, it can alias anything. */
- if (lookup_attribute ("may_alias", TYPE_ATTRIBUTES (t)))
-return 0;
/* The C standard specifically allows aliasing between signed and
unsigned variants of the same type. We treat the signed
Index: alias.c
===
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.254
diff -u -p -r1.254 alias.c
--- alias.c 21 Jul 2005 22:34:33 - 1.254
+++ alias.c 30 Sep 2005 17:46:42 -
@@ -587,6 +587,10 @@ get_alias_set (tree t)
/* Now all we care about is the type. */
t = TREE_TYPE (t);
}
+
+ /* If it has the may_alias attribute, it can alias anything. */
+ if (lookup_attribute ("may_alias", TYPE_ATTRIBUTES (t)))
+return 0;
/* Variant qualifiers don't affect the alias set, so get the main
variant. If this is a type with a known alias set, return it. */
Index: tree.c
===
RCS file: /cvs/gcc/gcc/gcc/tree.c,v
retrieving revision 1.505
diff -u -p -r1.505 tree.c
--- tree.c 14 Sep 2005 15:04:56 - 1.505
+++ tree.c 30 Sep 2005 17:46:42 -
@@ -4705,6 +4705,17 @@ build_pointer_type_for_mode (tree to_typ
if (to_type == error_mark_node)
return error_mark_node;
+
+ if (can_alias_all)
+{
+ to_type =
+ build_type_attribute_variant (ttype,
+ merge_attributes
+ (TYPE_ATTRIBUTES (to_type),
+tree_cons (get_identifier
("may_alias"),
+ NULL_TREE, NULL_TREE)));
+
+}
/* In some cases, languages will have things that aren't a POINTER_TYPE
(such as a RECORD_TYPE for fat pointers in Ada) as TYPE_POINTER_TO.
@@ -4721,14 +4732,13 @@ build_pointer_type_for_mode (tree to_typ
/* First, if we already have a type for pointers to TO_TYPE and it's
the proper mode, use it. */
for (t = TYPE_POINTER_TO (to_type); t; t = TYPE_NEXT_PTR_TO (t))
-if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all)
+if (TYPE_MODE (t) == mode)
return t;
t = make_node (POINTER_TYPE);
TREE_TYPE (t) = to_type;
TYPE_MODE (t) = mode;
- TYPE_REF_CAN_ALIAS_ALL (t) = can_alias_all;
TYPE_NEXT_PTR_TO (t) = TYPE_POINTER_TO (to_type);
TYPE_POINTER_TO (to_type) = t;
@@ -4754,6 +4764,18 @@ build_reference_type_for_mode (tree to_t
bool can_alias_all)
{
tree t;
+
+
+ if (can_alias_all)
+{
+ to_type =
+ build_type_attribute_variant (ttype,
+ merge_attributes
+ (TYPE_ATTRIBUTES (to_type),
+tree_cons (get_identifier
("may_alias"),
+ NULL_TREE, NULL_TREE)));
+
+}
/* In some cases, languages will have things that aren't a REFERENCE_TYPE
(such as a RECORD_TYPE for fat pointers in Ada) as TYPE_REFERENCE_TO.
@@ -4770,14 +4792,13 @@ build_reference_type_for_mode (tree to_t
/* First, if we already have a type for pointers to TO_TYPE and it's
the proper mode, use it. */
for (t = TYPE_REFERENCE_TO (to_type); t; t = TYPE_NEXT_REF_TO (t))
-if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all)
+if (TYPE_MODE (t) == mode)
return t;
t = make_node (REFERENCE_TYPE);
TREE_TYPE (t) = to_type;
TYPE_MODE (t) = mode;
- TYPE_REF_CAN_ALIAS_ALL (t) = can_alias_all;
TYPE_NEXT_REF_TO (t) = TYPE_REFERENCE_TO (to_type);
TYPE_REFERENCE_TO (to_type) = t;
@@ -4809,12 +4830,12 @@ build_type_no_quals (tree t)
case POINTER_TYPE:
return build_pointer_type_for_mode (build_type_no_quals (TREE_TYPE (t)),
TYPE
Re: GCC 4.0.2 Released
Daniel Jacobowitz wrote: >>My inclination is to do nothing (other than correct the target >>milestones on these bugs in bugzilla) and move on. The Solaris problem >>is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's >>a crisis meriting another release cycle. The C++ change fixed a >>regression relative to 3.4.x, but not 4.0.x. Andreas' change is only >>known to affect m68k. > > ... but IIRC it cripples GCC for m68k; Debian turned up hundreds of > build failures because of this bug and it set builds back several > weeks. Was this a regression from 4.0.0 or 4.0.1? > Personally, I'd do a 4.0.3 based on current bits. The problem is that it's not just me banging on the release button (which does itself take quite a lot of time, since there's all the secondary upload and web-site work to do); it's also going to mean freezing the release branch and doing a release candidate with current changes, which will further distract from 4.1. And, m68k is not a primary platform. I think the right metric is: if we hadn't known about this bug before 4.0.2 would we be rushing out 4.0.3 right now? I think in this case the answer is clearly no. I think the Solaris problem is the only one which might merit that kind of recation. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0.2 Released
Mark Mitchell <[EMAIL PROTECTED]> writes: > The key question is whether to do an immediate 4.0.3 to catch up to what > we intended. (That's not entirely trivial, in that things have now been > checked in on the 4.0 branch, so we would have to temporarily back out > some patches, or apply tags very carefully.) Or, we could do a 4.0.3 > based on current bits. > > My inclination is to do nothing (other than correct the target > milestones on these bugs in bugzilla) and move on. The Solaris problem > is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's > a crisis meriting another release cycle. The C++ change fixed a > regression relative to 3.4.x, but not 4.0.x. Andreas' change is only > known to affect m68k. > > I'd appreciate feedback. (I don't promise to be bound by the majority > view, though.) I think it's OK to let it go. It doesn't seem like a crisis to me. Chalk it up to experience. > I'd also appreciate suggestions for making the release script more > robust in this situation; clearly, depending on cvs rtag to fail is > clearly not sufficiently reliable. One obvious idea would be to first see if the tag exists, and to fail if it does. You can see if it exists by doing a checkout using that tag. If the tag does not exist, the checkout will fail. Note that this is a slow process, as CVS pokes around trying to find the tag, but presumably the script takes a while to run anyhow. I guess this will have to be rewritten to use SVN soon anyhow. Ian
Re: GCC 4.0.2 Released
On Fri, Sep 30, 2005 at 10:54:22AM -0700, Mark Mitchell wrote: > Daniel Jacobowitz wrote: > > >>My inclination is to do nothing (other than correct the target > >>milestones on these bugs in bugzilla) and move on. The Solaris problem > >>is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's > >>a crisis meriting another release cycle. The C++ change fixed a > >>regression relative to 3.4.x, but not 4.0.x. Andreas' change is only > >>known to affect m68k. > > > > ... but IIRC it cripples GCC for m68k; Debian turned up hundreds of > > build failures because of this bug and it set builds back several > > weeks. > > Was this a regression from 4.0.0 or 4.0.1? > > > Personally, I'd do a 4.0.3 based on current bits. > > The problem is that it's not just me banging on the release button > (which does itself take quite a lot of time, since there's all the > secondary upload and web-site work to do); it's also going to mean > freezing the release branch and doing a release candidate with current > changes, which will further distract from 4.1. > It doesn't have to a formal release. I would just make a snapshot from the 4.0 branch and point the affected people to it. If there isn't enough, you can always make another snapshot. You can update 4.0.2 release web page and mention the snapshot for those people. H.J.
Re: GCC 4.0.2 Released
On Fri, Sep 30, 2005 at 10:06:07AM -0700, Mark Mitchell wrote: > Ulrich Weigand wrote: > > > Comparing the cp/ChangeLog files from 4.0.2 and the 4_0 branch, it looks > > like the fix is in the release according to the current ChangeLog, but > > in fact it wasn't: > > Indeed, cvs log confirms that the revision was made to cp/init.c on > September 22. > > It appears that the release automation failed, and that, in fact, the > allegedly final GCC 4.0.2 bits are in fact the early version of GCC > 4.0.2 that I never uploaded because of the last-minute changes for > Solaris and such. > > I'm incredibly depressed. In the past, when mistakes like this occurred (though it has been a long time), we put out a correction release, which in this case might be named 4.0.2a or 4.0.2.1. I suggest 4.0.2.1.
Re: GCC 4.0.2 Released
On Fri, Sep 30, 2005 at 10:54:22AM -0700, Mark Mitchell wrote: > Was this a regression from 4.0.0 or 4.0.1? I doubt it. > > Personally, I'd do a 4.0.3 based on current bits. > > The problem is that it's not just me banging on the release button > (which does itself take quite a lot of time, since there's all the > secondary upload and web-site work to do); it's also going to mean > freezing the release branch and doing a release candidate with current > changes, which will further distract from 4.1. > > And, m68k is not a primary platform. > > I think the right metric is: if we hadn't known about this bug before > 4.0.2 would we be rushing out 4.0.3 right now? I think in this case the > answer is clearly no. I think the Solaris problem is the only one which > might merit that kind of recation. *shrug* Let's let it go then. I have less faith in the value of the primary/secondary platform distinction, and no immediate stake in whether the bug is fixed in 4.0.2, since Debian has long since given up using releases rather than the tip of the release branches. It's still a platform that people use. -- Daniel Jacobowitz CodeSourcery, LLC
Re: GCC 4.0.2 Released
On Fri, Sep 30, 2005 at 11:03:31AM -0700, Joe Buck wrote: > On Fri, Sep 30, 2005 at 10:06:07AM -0700, Mark Mitchell wrote: > > Ulrich Weigand wrote: > > > > > Comparing the cp/ChangeLog files from 4.0.2 and the 4_0 branch, it looks > > > like the fix is in the release according to the current ChangeLog, but > > > in fact it wasn't: > > > > Indeed, cvs log confirms that the revision was made to cp/init.c on > > September 22. > > > > It appears that the release automation failed, and that, in fact, the > > allegedly final GCC 4.0.2 bits are in fact the early version of GCC > > 4.0.2 that I never uploaded because of the last-minute changes for > > Solaris and such. > > > > I'm incredibly depressed. > > In the past, when mistakes like this occurred (though it has been a long > time), we put out a correction release, which in this case might be named > 4.0.2a or 4.0.2.1. > > I suggest 4.0.2.1. Rather, if we decide to immediately just put out the version you had intended to release (without other changes) it could be called 4.0.2.1.
Re: GCC 4.0.2 Released
On Fri, Sep 30, 2005 at 10:59:45AM -0700, H. J. Lu wrote: > It doesn't have to a formal release. I would just make a snapshot from > the 4.0 branch and point the affected people to it. If there isn't > enough, you can always make another snapshot. You can update 4.0.2 > release web page and mention the snapshot for those people. If we were going to do such a thing, it would be better to give this "snapshot" a name. It would be an embarrassment to be in the position of telling people that our release isn't recommended for use on some platforms, and to use some snapshot instead.
Re: GCC 4.0.2 Released
Mark Mitchell writes: > Daniel Jacobowitz wrote: > > >>My inclination is to do nothing (other than correct the target > >>milestones on these bugs in bugzilla) and move on. The Solaris problem > >>is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's > >>a crisis meriting another release cycle. The C++ change fixed a > >>regression relative to 3.4.x, but not 4.0.x. Andreas' change is only > >>known to affect m68k. > > > > ... but IIRC it cripples GCC for m68k; Debian turned up hundreds of > > build failures because of this bug and it set builds back several > > weeks. > > Was this a regression from 4.0.0 or 4.0.1? I don't know. We noticed when we did switch the compiler from 3.3 to 4.0. IMO, we (Debian) can make sure that the patch is applied in the compiler. Matthias
Re: GCC 4.0.2 Released
Matthias Klose wrote: Mark Mitchell writes: Daniel Jacobowitz wrote: My inclination is to do nothing (other than correct the target milestones on these bugs in bugzilla) and move on. The Solaris problem is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's a crisis meriting another release cycle. The C++ change fixed a regression relative to 3.4.x, but not 4.0.x. Andreas' change is only known to affect m68k. ... but IIRC it cripples GCC for m68k; Debian turned up hundreds of build failures because of this bug and it set builds back several weeks. Was this a regression from 4.0.0 or 4.0.1? I don't know. We noticed when we did switch the compiler from 3.3 to 4.0. IMO, we (Debian) can make sure that the patch is applied in the compiler. RTEMS will have to use the same patch as will anyone else interested. So make sure the patch is easily accessible. In spite of the pain, a dot release is probably the safest thing all around. Sorry this happened. I can sympathize with your pain. :( Matthias -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC 4.0.2 Released
I'd appreciate feedback. (I don't promise to be bound by the majority view, though.) I seem to recall in the past that they did patch releases. From both a tagging purity point of view and reproducability point ov view, why not create a branch off 4.0.2, apply the fixes that were missed, tag it as 4.0.2.1 and release that? Kean
Re: Aliasing violation generated by fold_builtin_memcmp?
On Fri, Sep 30, 2005 at 11:23:23AM +0200, Olivier Hainque wrote: > We are seeing regressions in our local testsuite on cases exercising > that pragma. Hmm. > The 'tag alias set should be zero if ...' idea above seems logical to me. > I still may well not yet see a number of other options. Perhaps we should instead get rid of this flag and instead represent this as a variant of the pointed-to type with the alias set forced to zero. It does seem odd that there are two ways to represent this... r~
x86 SSE constants
The C constraint on x86 is defined, in both the doc and the comments, as "constant that can be easily constructed in SSE register without loading from memory". Currently the only one handled is 0, but there is at least one more, all 1 bits, which is constructed by pcmpeqd %xmm, %xmm Unfortunately there are quite a few places in the patterns that assume C means zero, and generate pxor or something like that. What would be the preferred way to fix this, new constraint or change the existing patterns?
Ada question about PR 18434
Rainer tracing seems to show that strange thing happen to Osint.Running_Program during elaboration of 4.0.x. We have: package body Osint is Running_Program : Program_Type := Unspecified; ... procedure Set_Program (P : Program_Type) is begin ... Running_Program := P; end Set_Program; ... package body Osint.M is ... begin Set_Program (Make); end Osint.M; However I see no reason why Osint body elaboration must be done before Osint.M body elaboration, it seems to me that the binder could perfectly choose to elaborate Osint.M body before Osint body, and this would leave Running_Program with the "wrong" value Rainer observes when gnatmake is running. If I'm guessing correctly there are two solutions: 1/ Remove the default initialization in ada/osint.adb - Running_Program : Program_Type := Unspecified; + pragma Warnings (Off); + Running_Program : Program_Type; + pragma Warnings (On); This is not a long term solution, but local and should fix the problem if my hypothesis is correct, Rainer could you try this one? 2/ Use elaboration pragma, like may be a pragma Elaborate_Body in ada/osint.ads but this requires a more global knowledge of what happens during compiler tools elaboration. Arnaud, Robert? Thanks in advance, Laurent
Re: [PATCH, ping] Cray Pointers
On Friday 30 September 2005 21:36, Asher Langton wrote: > On Thu, 29 Sep 2005, Jack Howarth wrote: > > Asher, > >Any progress on the paperwork? > > None. I haven't received anything from the FSF. I just pinged them > again. The FSF does have a disclaimer from LLNL, which seems like it > should be sufficient, according to: > > http://gcc.gnu.org/contribute.html#legal Can someone with access to these FSF lists check if this is correct? This is taking far longer than necessary, and it's annoying both for our users and (especially) our contributor here that it's taking such a long time :-( Gr. Steven
Re: [PATCH, ping] Cray Pointers
On Fri, Sep 30, 2005 at 11:01:53PM +0200, Steven Bosscher wrote: > On Friday 30 September 2005 21:36, Asher Langton wrote: > > On Thu, 29 Sep 2005, Jack Howarth wrote: > > > Asher, > > >Any progress on the paperwork? > > > > None. I haven't received anything from the FSF. I just pinged them > > again. The FSF does have a disclaimer from LLNL, which seems like it > > should be sufficient, according to: > > > > http://gcc.gnu.org/contribute.html#legal > > Can someone with access to these FSF lists check if this is correct? > > This is taking far longer than necessary, and it's annoying both for > our users and (especially) our contributor here that it's taking such > a long time :-( This does not seem to be true. The only reference to LLNL in the copyright assignments is a disclaimer of changes (by someone else, not by Asher); they'd need a blanket assignment, or a disclaimer for Asher in which case he would need an individual assignment. Beyond that you'll have to contact the assignments clerk directly. -- Daniel Jacobowitz CodeSourcery, LLC
Re: [PATCH, ping] Cray Pointers
> Steven Bosscher writes: Steven> On Friday 30 September 2005 21:36, Asher Langton wrote: >> On Thu, 29 Sep 2005, Jack Howarth wrote: >> > Asher, >> >Any progress on the paperwork? >> >> None. I haven't received anything from the FSF. I just pinged them >> again. The FSF does have a disclaimer from LLNL, which seems like it >> should be sufficient, according to: >> >> http://gcc.gnu.org/contribute.html#legal Steven> Can someone with access to these FSF lists check if this is correct? The disclaimer specifically is for Christoper Michael Chambreau. It cannot be applied to anyone else. Steven> This is taking far longer than necessary, and it's annoying both for Steven> our users and (especially) our contributor here that it's taking such Steven> a long time :-( The FSF is trying to contact Mike Kumbera directly to track down the paperwork. David
Re: GCC 4.0.2 Released
Kean Johnston wrote: >> I'd appreciate feedback. (I don't promise to be bound by the majority >> view, though.) > > I seem to recall in the past that they did patch releases. > From both a tagging purity point of view and reproducability > point ov view, why not create a branch off 4.0.2, apply the > fixes that were missed, tag it as 4.0.2.1 and release that? Thanks to all who provided feedback. Here's what I'm going to do: 1. Move the ChangeLog entries on the 4.0 branch to accurately reflect the released bits. 2. Modify Bugzilla to reset the target milestone for the three PRs in question. 3. Modify gcc_release to prevent this situation in future. I've decided not to do another release. I think it's too much effort for too little gain. The C++ and m68k patches are things that might just as easily not have been applied in the first place; we certainly wouldn't have considered either PR a showstopper. The Solaris problem is unfortunate, but I think not fatal. However, I will try to do a 4.0.3 release in the relatively near future. I had previously indicated that I would focus exclusively on 4.1, and I still plan to do that primarily, but I'll work in a 4.0.3 at some point. I very much apologize for the mistake. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [PATCH, ping] Cray Pointers
On Fri, Sep 30, 2005 at 05:10:01PM -0400, David Edelsohn wrote: > > Steven Bosscher writes: > > Steven> On Friday 30 September 2005 21:36, Asher Langton wrote: > >> On Thu, 29 Sep 2005, Jack Howarth wrote: > >> > Asher, > >> >Any progress on the paperwork? > >> > >> None. I haven't received anything from the FSF. I just pinged them > >> again. The FSF does have a disclaimer from LLNL, which seems like it > >> should be sufficient, according to: > >> > >> http://gcc.gnu.org/contribute.html#legal > > Steven> Can someone with access to these FSF lists check if this is correct? > > The disclaimer specifically is for Christoper Michael Chambreau. > It cannot be applied to anyone else. If you review the emails in fortran@ for the few months, you'll find that the copyright clerk has acknowledged receiving a disclaimer from Asher. This clerk probably discarded it because it was not a FSF approved assignment. In addition, several of us on fortran@ have tried to get the copyright issues resolved in this matter. It is amazing to see the level of incompetency displayed by [EMAIL PROTECTED] -- Steve
Error: Local symbol '.LTHUNK0' can't be equated to ......
Hi,
Recently I've been getting strange errors on ill-formed code. It looks
as if the compiler is not stopping after an error, but running the
assembler anyway:
dp-matrix.H:110: error: extra qualification 'DPmatrix::' on member
'DPmatrix' ignored
dp-matrix.H:132: error: extra qualification 'DPmatrixNoEmit::' on member
'DPmatrixNoEmit' ignored
dp-matrix.H:184: error: extra qualification 'DPmatrixEmit::' on member
'DPmatrixEmit' ignored
{standard input}: Assembler messages:
{standard input}:115: Error: Local symbol `.LTHUNK0' can't be equated to
undefined symbol `_ZN8DPmatrixD0Ev'
{standard input}:115: Error: Local symbol `.LTHUNK1' can't be equated to
undefined symbol `_ZN14DPmatrixNoEmitD0Ev'
{standard input}:115: Error: Local symbol `.LTHUNK2' can't be equated to
undefined symbol `_ZN14DPmatrixNoEmitD1Ev'
{standard input}:115: Error: Local symbol `.LTHUNK3' can't be equated to
undefined symbol `_ZN12DPmatrixEmitD0Ev'
{standard input}:115: Error: Local symbol `.LTHUNK4' can't be equated to
undefined symbol `_ZN14DPmatrixSimpleD0Ev'
{standard input}:115: Error: Local symbol `.LTHUNK5' can't be equated to
undefined symbol `_ZN14DPmatrixSimpleD1Ev'
{standard input}:115: Error: Local symbol `.LTHUNK6' can't be equated to
undefined symbol `_ZN19DPmatrixConstrainedD0Ev'
{standard input}:115: Error: Local symbol `.LTHUNK7' can't be equated to
undefined symbol `_ZN12DPmatrixEmitD1Ev'
{standard input}:115: Error: Local symbol `.LTHUNK8' can't be equated to
undefined symbol `_ZN19DPmatrixConstrainedD1Ev'
{standard input}:115: Error: Local symbol `.LTHUNK9' can't be equated to
undefined symbol `_ZN8DPmatrixD1Ev'
The error messages are fine, but seems that the assembler messages are
superfluous.
Is this a known bug?
-BenRI
Re: [PATCH, ping] Cray Pointers
> Steve Kargl writes: Steve> If you review the emails in fortran@ for the few months, you'll find Steve> that the copyright clerk has acknowledged receiving a disclaimer from Steve> Asher. This clerk probably discarded it because it was not a FSF approved Steve> assignment. In addition, several of us on fortran@ have tried to get Steve> the copyright issues resolved in this matter. It is amazing to see the Steve> level of incompetency displayed by [EMAIL PROTECTED] It would help if the people at LLNL would follow the correct procedures. David
Re: GCC 4.0.2 Released
> I've decided not to do another release. I think it's too much effort > for too little gain. The C++ and m68k patches are things that might > just as easily not have been applied in the first place; we certainly > wouldn't have considered either PR a showstopper. The Solaris problem > is unfortunate, but I think not fatal. Agreed. But I'm requesting a "caveat" note about the Solaris regression here: http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2 mentioning the workaround (g++ -pthreads) and the link: http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html -- Eric Botcazou
Confusion with tree_ssa_useless_type_conversion_1
At one point, that function used to pretty much just call lang_hooks.types_compatible_p. Now it does more. Specifically, it can return TRUE even if the lang hook returns FALSE. That's a problem for the optimizers and causes performance regressions. For example, I noticed that trivial trail recursion elimination isn't being done for Ada. I used the simple example: function Fact (I: Integer) return Integer is begin if I = 1 then return 1; else return I * Fact (I - 1); end if; end Fact; The problem is the operand "I - 1". The type "Integer" is really a subtype (of Integer'Base). So "I" is of that type. "I - 1", being an operand, is of type Integer'Base. So the call above actually has a conversion from the base type to the subtype. However, those two types look the same to tree_ssa_useless_type_conversion_1 even though the langhook uses the default and says they aren't. That means that gimplification omits the conversion which, in turn, means that the actual and formal aren't the same type if you just use the lang hook. Tail recursion declines to optimize it because of that. The following fixes it: *** tree-tailcall.c 28 Jul 2005 16:29:56 - 2.47 --- tree-tailcall.c 30 Sep 2005 18:39:38 - *** find_tail_calls (basic_block bb, struct *** 447,452 we emitted a suitable type conversion statement. */ if (!is_gimple_reg_type (TREE_TYPE (param)) ! || !lang_hooks.types_compatible_p (TREE_TYPE (param), !TREE_TYPE (arg))) break; --- 447,452 we emitted a suitable type conversion statement. */ if (!is_gimple_reg_type (TREE_TYPE (param)) ! || !tree_ssa_useless_type_conversion_1 (TREE_TYPE (param), ! TREE_TYPE (arg))) break; However, I think that *every* call to lang_hooks.types_compatible_p in the tree-*.c files (and possibly gimplify.c) except for the one in tree_ssa_useless_type_conversion_1 (there are 20 of them) ought to be handled the same as above. Comments?
Re: x86 SSE constants
> The C constraint on x86 is defined, in both the doc and the comments, as > "constant that can be easily constructed in SSE register without loading > from memory". Currently the only one handled is 0, but there is at > least > one more, all 1 bits, which is constructed by >pcmpeqd %xmm, %xmm > Unfortunately there are quite a few places in the patterns that assume > C > means zero, and generate pxor or something like that. What would be > the preferred way to fix this, new constraint or change the existing > patterns? My original plan was to add pcmpeqd by extending the 'C' constraint and the patterns where pxor/xorp? is currently generated unconditionally. This is pretty similar to what we do to i387 constants as well. I never actually got to realizing this (for the scalar FP work I was mostly interested in that time it was not at all that interesting), but I think there is nothing in md file preventing it (or I just missed it when it was added :)... Honza
Re: x86 SSE constants
On Sep 30, 2005, at 4:17 PM, Jan Hubicka wrote: The C constraint on x86 is defined, in both the doc and the comments, as "constant that can be easily constructed in SSE register without loading from memory". Currently the only one handled is 0, but there is at least one more, all 1 bits, which is constructed by pcmpeqd %xmm, %xmm Unfortunately there are quite a few places in the patterns that assume C means zero, and generate pxor or something like that. What would be the preferred way to fix this, new constraint or change the existing patterns? My original plan was to add pcmpeqd by extending the 'C' constraint and the patterns where pxor/xorp? is currently generated unconditionally. This is pretty similar to what we do to i387 constants as well. I never actually got to realizing this (for the scalar FP work I was mostly interested in that time it was not at all that interesting), but I think there is nothing in md file preventing it (or I just missed it when it was added :)... No, there isn't, but it might be a smaller change to add a new constraint having constraints tied to specific constants is pretty ugly, and so is having (if (constant value==0)) in a lot of patterns..,,
incompatible 'improvements'
Hello, I would like to suggest that in the future you pay more attention to backwards computability. There have been at least 4 instances where you broke the compiler with regard to being able to compile legacy code. I have > 500K lines of older code which works perfectly well and should not be impacted by what I regard as cosmetic changes to the allowed syntax. The main reason I choose to use gcc was that I didn't have to worry about different compilers doing different things and allowing or disallowing different syntax options. Many of these incompatibilities have had to do with the treatment of static subroutines. The latest break down (whose inability to be backwards compatible is apparently due to unit-at-a-time-mode) is not allowing static declarations of functions within the module where the function is used. I have no objection to making things like this result in new warnings, as long as I can turn the warning off if I want, but making them result in errors is absolutely wrong. This is the third time you have done this with static functions, each time making the most expedient path to a solution stop working. Another instance had to do with disallowing extra text in # directives. Frankly, I don't care what standards say is no longer acceptable syntax. If I have something that works, I expect it to continue to work. What's next? Are you going to start imposing your source code formatting standards? Stop emulating Microsoft, who has little regard for maintaining backwards computability and start emulating Sun who is generally very good at this. Regards, George White
Re: GCC 4.0.2 Released
Eric Botcazou wrote: >>I've decided not to do another release. I think it's too much effort >>for too little gain. The C++ and m68k patches are things that might >>just as easily not have been applied in the first place; we certainly >>wouldn't have considered either PR a showstopper. The Solaris problem >>is unfortunate, but I think not fatal. > > > Agreed. But I'm requesting a "caveat" note about the Solaris regression here: > http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2 > mentioning the workaround (g++ -pthreads) and the link: > http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html Roger that. I'll take care of it as soon as I can. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: incompatible 'improvements'
George White wrote: Frankly, I don't care what standards say is no longer acceptable syntax. Well it is a goal of gcc to be compatible with the standard. Really it should be a goal of yours to make sure your code is correct, i.e. that it conforms with the standard, and if you write incorrect code, you cannot expect it to be accepted by the compiler in the first place. It is certainly not the case that you can assume that because the compiler accepts your code, that it is correct. If I have something that works, I expect it to continue to work. THat's a wrong expectation. If you write incorrect code, you cannot expect it to keep working. If you have a requirement for old incorrect legacy code to keep working, that's reasonable, but you are going to need to find someone (and presumably pay them) to maintain the old incorrect legacy compilers that go along with your old incorrect legacy code. Sure, it would be good if the compiler never accepted the bad code in the first place, but if a bug is found, it has to be fixed. What's next? Are you going to start imposing your source code formatting standards? Non sequitur, since this has nothing to do with language standards Stop emulating Microsoft, who has little regard for maintaining backwards computability backwards compatibility is of course important, but fixing clear bugs has higher priority ultimately if we expect gcc to achieve its goal of full implementation of the relevant standards. and start emulating Sun who is generally very good at this. Here I think you are primarily talking about the OS, where things are a bit different since there is no external standard that has to be followed. Regards, George White
Re: Aliasing violation generated by fold_builtin_memcmp?
On Fri, Sep 30, 2005 at 01:49:59PM -0400, Andrew Pinski wrote:
> Something like this will fix the issue with TYPE_REF_CAN_ALIAS_ALL
> by removing the use. Maybe we could move may_alias to a bit in the
> types and move TYPE_REF_CAN_ALIAS_ALL from the pointer type to the
> type which is being accessed instead of this mess.
Close.
> + build_type_attribute_variant (ttype,
> + merge_attributes
> + (TYPE_ATTRIBUTES (to_type),
> + tree_cons (get_identifier
> ("may_alias"),
> + NULL_TREE, NULL_TREE)));
If ALIAS_SET had been computed on ttype, this will leave it set.
You'd need to force set it to zero here. You can also avoid
creating a new type for C for the case in question by checking
that the original type has alias set zero.
>return build_pointer_type_for_mode (build_type_no_quals (TREE_TYPE
> (t)),
> TYPE_MODE (t),
> - TYPE_REF_CAN_ALIAS_ALL (t));
> + false);
You'd also want to delete all traces of TYPE_REF_CAN_ALIAS_ALL.
r~
Re: Aliasing violation generated by fold_builtin_memcmp?
On Fri, Sep 30, 2005 at 11:20:53AM -0400, Richard Kenner wrote: > That's easy enough for integer types, but creating multiple record types > means duplicating lots of fields and layouts and is, in general, a mess. Yeah, so? How often do you think this feature is used, anyway? r~
Re: x86 SSE constants
On Fri, Sep 30, 2005 at 04:31:59PM -0700, Dale Johannesen wrote: > No, there isn't, but it might be a smaller change to add a new > constraint > having constraints tied to specific constants is pretty ugly, and so is > having (if (constant value==0)) in a lot of patterns..,, That's why you'd centralize this into a few functions. There are several things that need changing: * Match different forms of constant for C. * Update vector_move_operand to use that same routine. * A routine to determine which of several instructions we want to emit. E.g. xorps instead of pxor for -Os. It should return a ATTR_MODE result so that we can call it from the mode attribute of various instructions. * A routine that uses the previous to return a const char* template to return from the insn output patterns. For bonus points, handle MMX too. r~
Re: gcc -I- feature
nmake Technical Support wrote:- > This is to request reinstatement of the -I- command line directory > search option. Sorry for the late request, we only recently became > aware that -I- is deprecated in gcc 4.0. I agree this should not be removed (have been removed?). It is now provided by a large number of compilers and people have found good uses for it. I am not sure why it was slated for removal. Neil.
Re: gcc -I- feature
On Sep 30, 2005, at 8:46 PM, Neil Booth wrote: nmake Technical Support wrote:- This is to request reinstatement of the -I- command line directory search option. Sorry for the late request, we only recently became aware that -I- is deprecated in gcc 4.0. I agree this should not be removed (have been removed?). It is now provided by a large number of compilers and people have found good uses for it. I don't see why you could not use -iquote for 4.0 and above and -I - in 3.4 and below. -iquote=DIR -iquote=DIR2 -I a == -I DIR -I DIR2 -I - but without turning off searching in the contained directory. In fact -iquote gives better control than -I - did. -- Pinski
Re: Aliasing violation generated by fold_builtin_memcmp?
Yeah, so? How often do you think this feature is used, anyway? Quite a lot in legacy Ada code. But how often it's used doesn't matter: if it's used *at all*, we still have to create the mechanism for duplicating record types.
Re: incompatible 'improvements'
On Fri, Sep 30, 2005 at 04:02:07PM -0700, George White wrote: > I would like to suggest that in the future you pay more attention > to backwards computability. There have been at least 4 instances > where you broke the compiler with regard to being able to compile > legacy code. The C standard that gcc implements by default has not changed since 1990. The C++ standard was final in 1998. You've had 15 years (if you're a C programmer) or 7 years (if you're a C++ programmer) to get used to the standard. Apparently you've learned the language by typing stuff at the compiler and finding out what worked. > Frankly, I don't care what standards say is no longer acceptable > syntax. If I have something that works, I expect it to continue to > work. What's next? Are you going to start imposing your source code > formatting standards? Stop emulating Microsoft, who has little regard > for maintaining backwards computability and start emulating Sun who is > generally very good at this. Sun has been so good at backwards compatibility that they've been prevented from implementing the C++ language correctly, and for years this has created huge porting headaches, and examples from standard textbooks have until recently not worked with Sun compilers. gcc focuses on implementing the documented standard. If you write code that is correct according to the ISO standard, and gcc miscompiles it, your bug report will be taken seriously. Otherwise, sorry. In many cases, fixing a failure to implement the standard correctly breaks some invalid program (such as yours) that happened to work before. The GCC developers properly give priority to getting standard-conforming programs correctly.
