[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #43 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-13 12:33 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > I think I now understand: I thought the problem we were discussing was > how to obtain correctness (which seems to be easy using local checks) > while in fact you were talking about how to optimize away unnecessary > validity checks (as compared to normal checks). Yes, I was talking about both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #41 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-10 00:17 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > It is not possible for a pointer value to be uninitialized. The language > requires all pointers to be default initialized to null. I mean the thing that pointer points to! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #39 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 23:13 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > I don't see that pointer dereferences are a problem - I'm pretty sure that > the RM places you firmly in the erroneous zone if you do something that can > give a pointer a bogus value. No. Referencing an uninitialized variable is a bounded error, not erroneous. That fact is basically what causes most of this trouble ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #36 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 14:29 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > I don't think this is a very serious problem. My understanding is > that the checks can be divided into two classes: normal checks and > validity checks. A normal check, such as when you do a type > conversion, does not use a V_C_E, it just does: > > if (y < new_type_lb || y > new_type_ub) > abort; > new_var = (new_type) y; Not clear. Consider the range check for a subscript on the LHS, for example. These issues are *very* subtle ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #35 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 14:18 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > All the mess would be way easier if the FE would not expose the subtypes to > the middle-end... I don't see how giving *additional* information could be bad: the middle-end is certainly free to ignore the bounds if it wants to! The point is that the bounds *do* say something and provide useful information to optimizers. The problem is that they don't say what the middle-end *wants* them to say! What they *do* mean is that it's a "bounded error" for a variable to have a value outside of the given bounds. What the middle-end *wants* them to mean is that it's *erroneous* for a variable to have a value outside of the given bounds. We need to reconcile those two concepts. >From a pragmatic point of view, they aren't that different, but there are a couple of important exceptions. The array bound on the LHS is one of them. A full solution to this is complex, but is indeed something that I'd like to happen some day. It involves work in various places. One thing that would help is that many variables can be proven to have the property that the only way they can have an invalid value is if erroneous behavior has occurred. For such variables, the meaning of the bounds is precisely what the middle-end expects it to mean. The most common case where you can't do this is for component references or pointer dereferences. In that case, we have to address this by distinguishing between two types of tests, those that will just propagate the bounded error condition and those that would convert a bounded error to erroneous behavior. We are allowed to use the bounds information in reasoning about the former, but not the latter. Note that there are similarities to the signed-overflow case here: there are some tests that we can safely eliminate with knowlege that signed-overflow is undefined, but others that we don't want to. So I think the "final" solution here will be to have the Ada front end provide the flag information on variables and tests mentioned above and extend VRP to use them. One of the two front-end issues (the latter) is quite easy and I think the other is moderately-easy. I don't know how much work the required VRP changes would be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #34 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 13:59 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > You may well respond that you are only supposed to forget > information you deduced from the range of the type, not information > you worked out by some other means. But these cannot really be > distinguished, c.f. VRP. Exactly. That's indeed the problem. It's similar to the whole signed-overflow issue: what you're able to safely do with with VRP-derived information depends on how you derived it and there's no way of tracking that. > Surely you only have to prove that it is in the range of Y, since if it > is not in the range of X then you have a bounded error, and doing a NOP_EXPR > should be perfectly legal. Think of a range check being done in a subscript reference in the LHS of an assignment. A bounded error is not allowed to cause a memory store outside the bounds of an array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #28 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-08 16:52 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > I don't see what the problem is - you don't have to convert to the base > type, you can always convert to some standard type of that precision, > eg int32, before calling the builtin. Sure, but it's extra tree nodes and more to do. See below. > Sure, it's just that overloading V_C_E like this feels somehow wrong to me. Why? It's not "overloading". V_C_E of an expression E of type X to type Y means "interpret the bits of E as if it were type Y and not type X". If Y is X'Base, then interpreting E as being Y means that it can now have all the values of Y. In other words, we could only change a V_C_E to a NOP_EXPR if we can prove that the value of E is in range of *both* X and Y. Of course, we still have a bit of a mess here in that the real point is a confusion between what in Ada is called a Bounded Error and C's notion of "undefined" (Ada's "erroneous"). But I think we can do better in this area: we just haven't gotten to take a really good look at it. > However I haven't been able to put my finger on any technical obstacle to > this use of V_C_E. Nor can I ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #26 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-08 12:54 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > y = __builtin_nop(x); valid = (y>=lower_bound && y <=upper_bound); > The point is that the intrinsic would be opaque to the optimizers, > and would only be lowered to the identity function *after* the tree > optimizers have run. One annoyance is that presumably intrinsics > would be needed for all integer and float precisions, eg > __builtin_nop8, __builtin_nop16, etc. More than each precision. The VIEW_CONVERT_EXPR is to the base type and there can be an unlimited number of them for each precision. Because it has to work with arbitrary types, a builtin won't do it. We could certainly add a new tree expression that says "don't look through this for VRP purposes", but we already have V_C_E. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 fail
--- Comment #20 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-06-27 03:03 --- Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 fail > > > Looks like the same bug that Gigi doesn't currently use VIEW_CONVERT_EXPR > > > for this type of Unchecked_Conversion. So already on my plate. > > Was a patch written for that at AdaCore? Yes, but only on Friday and it hasn't been tested yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #13 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-03-30 12:13 --- Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures Richard, I know Robert and you have come up with a plan to address the 'Valid problem. Is there an implementation sketch available somewhere? No, because it's just a matter of having the unchecked conversion converted to a VIEW_CONVERT_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #8 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-03-28 03:56 --- Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures I don't know how it goes through gigi and the BE but the check system__unsigned_types__unsigned!(A) in 4 .. 5 must not go away. May be the front-end is wrong in using function c35507m__char as input type for the parameter though. Looks like the same bug that Gigi doesn't currently use VIEW_CONVERT_EXPR for this type of Unchecked_Conversion. So already on my plate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/18819] [4.2 Regression] ACATS cdd2a02 fail at runtime
--- Comment #31 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-02-15 17:14 --- Subject: Re: [4.2 Regression] ACATS cdd2a02 fail at runtime Yes, that's it. Is a front-end specialist working on that or...? Nope. I spoke to Ed S. about it a while ago and he wasn't too enthusiastic about the idea. Why don't you make a small test case and let's take it from there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/18819] [4.2 Regression] ACATS cdd2a02 fail at runtime
--- Comment #29 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-02-15 12:57 --- Subject: Re: [4.2 Regression] ACATS cdd2a02 fail at runtime Richard, it's the only remaining failure in ACATS on most platforms: the bad interaction between SRA and aggregates under certain circumstances. Do you know what amount of work would be required to properly get rid of it? Is this the one with extension records that rename a discriminant? If so, the fix involves the front end materializing fields that don't semantically exist for the purposes of listing all fields in the record. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug tree-optimization/22336] [4.1 Regression] ICE Segfault in record_block_change at function.c:5498
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-07-10 19:09 --- Subject: Re: [4.1 Regression] ICE Segfault in record_block_change at function.c:5498 The following patch suggested by Richard Kenner messages "fixes" the bootstrap problem. To be precise, I said that it worked around the problem, but I don't consider that the proper fix. I don't, however, know what the proper fix is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22336
[Bug tree-optimization/22212] [4.1 Regression] SEGV in is_gimple_variable during loop-ivopts while building Ada RTS
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-07-02 16:04 --- Subject: Re: [4.1 Regression] SEGV in is_gimple_variable during loop-ivopts while building Ada RTS cxa4006 and cxa4017 fail the same way (STORAGE_ERROR) as vms_conv.adb. See the email I sent to the GCC list about cxa4006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22212
[Bug ada/20593] [4.0/4.1 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-06-22 01:51 --- Subject: Re: [4.0/4.1 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC Kenner may I ask what happened to this patch, it never went in, I still have it in my tree, but never got around to doing anything with it. may I test it and apply it? Sure. It's an obviously-correct change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20593
[Bug c++/21135] [4.0/4.1 Regression] &a[-2] ICE at the top level
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-05-30 18:36 --- Subject: Re: [4.0/4.1 Regression] &a[-2] ICE at the top level The difference in the handling of these two expressions is that get_inner_reference sets the "offset" out-parameter for &a[-2], but not for a[2]. That's at odds with its documentation, which says that offset is only set if the offset is not a constant. Is this because the value doesn't fit in some type? I don't understand why it's doing that. Furthermore, the out-parameter "bitpos" is signed, which suggests that negative values should be acceptable. I think this is just consistency: bitpos is signed all over the place. But, actually, I think there are some cases where the are negative bit positions: the object a thin pointer in Ada points to comes to mind. Changing get_inner_reference to use ssizetype and sbitsizetype throughout fixes the problems -- but I'm not sure if that's 100% correct. Nor am I, but I can't offhand think of anything it would breajk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-04-07 18:03 --- Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned)) And the middle end should be able to expect that the size of the elements is at least as large as their alignments. Are you suggesting that this be true just for *array* elements, for all elements (including record components), or for all decls? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-04-07 17:54 --- Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned)) For the record, this has come up on the lists before in some slightly other context and Mark has advocated (1). I'm of a mind to agree. I should add that I understand both arguments and don't have a very strong feeling either way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-04-07 14:41 --- Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned)) With user defined alignment, size certainly is not necessarily a multiple of the alignment and with the exception of arrays it shouldn't cause any problems. Well, I always thought that was invalid. Indeed for Ada, I make a new type with the larger size. We've never actually *documented* anywhere that the size is a multiple of the alignment, but I think lots of stuff all over the place silently assumes it. In arrays I agree this is a problem. Now, the question is what to do: 1) issue error whenever a type with alignment bigger than size is used in an array 2) align the whole array and change the element type silently to a type with alignment equal to the element size I think (2) is best. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-04-07 14:13 --- Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned)) This is caused by the big Ada patch that introduced the extra 2 ARRAY_REF arguments. Unfortunately, I couldn't find the reason why is the last ARRAY_REF's argument measured in aligment units and not in bytes (and what was the reason for adding this argument). It has to do with the way MEM_ALIGN is computed. What happens is that when we compute the address of the MEM, we do it by multiplying the index by the size in some units. The second operand of that multiply is the only way that RTL generation can know what the alignment is. If the units were in bytes, the multiplication wouldn't show the alignment. We have the same issue with DECL_FIELD_OFFSET. There most definitely needs to be a better way to do this, but this goes back years and I haven't found one. The element type has TYPE_ALIGN_UNIT 16, but TYPE_SIZE_UNIT 4, That's wrong. The size always needs to be a multiple of the alignment. That's fundamental. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-03-24 12:33 --- Subject: Re: [PR middle-end/20491] combine generates bad subregs Combine doesn't ensure the subregs it generates are valid. In most cases, insn recog will reject the invalid subregs, or reload will some how make them fit, but if the constraint of the insn or the asm operand is "X", this won't work, so I think we're better off ensuring we don't ever introduce subregs of non-REGs. Aside from calling recog combine doesn't check that *anything* it generates is valid. Why should subregs be different? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug ada/20593] [4.0/4.1 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-03-22 22:45 --- Subject: Re: [4.0/4.1 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC Here's the fix. Will check in shortly. Note that the handling of 'Unrestricted_Access in Gigi isn't what the front end expects. That's a simple fix that will also fix this problem, but the below is also a good idea ... *** varasm.c22 Mar 2005 01:10:54 - 1.485 --- varasm.c22 Mar 2005 22:04:45 - *** compute_reloc_for_constant (tree exp) *** 3363,3366 --- 3363,3367 case CONVERT_EXPR: case NON_LVALUE_EXPR: + case VIEW_CONVERT_EXPR: reloc = compute_reloc_for_constant (TREE_OPERAND (exp, 0)); break; *** output_addressed_constants (tree exp) *** 3419,3422 --- 3420,3424 case CONVERT_EXPR: case NON_LVALUE_EXPR: + case VIEW_CONVERT_EXPR: output_addressed_constants (TREE_OPERAND (exp, 0)); break; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20593
[Bug ada/19900] [4.0/4.1 Regression] ACATS c391002 c432002 ICE categorize_ctor_elements_1
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-03-06 04:06 --- Subject: Re: [4.0/4.1 Regression] ACATS c391002 c432002 ICE categorize_ctor_elements_1 Note that there is a fix for this "in the pipe" waiting for Arno's next tree synchronization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19900
[Bug middle-end/19956] [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-02-25 20:44 --- Subject: Re: [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code Richard, any idea? This is not ACATS but has been reported to affect real Ada code. Not yet. I'm caught deep in the bowels of PR19900 right now ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19956
[Bug ada/19900] [4.0 Regression] ACATS c391002 c432002 ICE categorize_ctor_elements_1
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-02-16 04:08 --- Subject: Re: [4.0 Regression] ACATS c391002 c432002 ICE categorize_ctor_elements_1 Thanks for looking into this. I hadn't gotten a chance yet, but was very close to getting to it. Just for the record UNION TYPE is defined in tree.def as something different than what the Ada front- end is using it for, From tree.def: /* Union in C. Like a struct, except that the offsets of the fields will all be zero. */ /* See the comment above, before ENUMERAL_TYPE, for how forward references to union tags are handled in C. */ DEFTREECODE (UNION_TYPE, "union_type", tcc_type, 0) /* C union type */ Ugh! This is a mess. I didn't notice the assumption about UNION_TYPE, concentrating just on the non-overlapping assumption. I'm not sure anybody actually relies on the assumption that all field offsets are zero, but that would need to be checked. The initializer issue is more serious, of course. Record subtypes in general can have overlapping fields (consider variants), but you can't validly reference two overlapping fields at the same time. Records with _Parent fields are an exception, but they can't be easily transformed into being non-overlapping (via nesting) as I understand it without a lot of surgery to the Ada part of the front end. This will require considerable investigation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19900
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-02-10 18:12 --- Subject: Re: [4.0 Regression] Poor quality code after loop unrolling. It's been about a decade since I looked at cse vs autoincrements, so the details have faded from memory. [The original context I found the problem was in an attempt to run cse after reload. ] My recollection is that we never used to allow autoincrements before CSE with the exception of autoinc on SP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug middle-end/16237] [3.5 Regression] ICE caused by Kenner's big untested (regression causing) patch
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2004-07-17 14:00 --- Subject: Re: [3.5 Regression] ICE caused by Kenner's big untested (regression causing) patch This regression causing patch has been in there for more than two weeks now. When do you plan to look into it? Please have a look at the PR 16594 I made that is reported duplicate of this. More than two weeks is more than what our usual policy tolerates. I can't reproduce these errors, so I'm very much limited in what I can do., Did this go away with the fold-const.c patch I posted on the GCC list a couple of days ago? If not, I'm going to need some help in how to reproduce this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16237
