Re: Rescue of prehistoric GCC versions
On 1/9/20 5:28 AM, Eric S. Raymond wrote: > I have been able to rescue or reconstruct from patches the following > prehisoric GCC releases Great job. This is important > > gcc-0.9 > gcc-1.21 > gcc-1.22 > gcc-1.25 > gcc-1.26 > gcc-1.27 > gcc-1.28 > gcc-1.35 > > gcc-1.36 > gcc-1.37.1 > gcc-1.38 > gcc-1.39 > gcc-1.40 > gcc-1.41 > gcc-1.42 > gcc-2.1 > gcc-2.2.2 > gcc-2.3.3 > gcc-2.4.5 > gcc-2.5.8 > gcc-2.6.3 > gcc-2.7.2 > gcc-2.8.0 > > The gap in the sequence represents the beginning of the repository > history; r3 = gcc-1.36. > > The 0.9 to 0.35 tarballs can be glued to the front of the > history, one commit each, with a firewall commit containing a deleteall > to keep the content from leaking forward. This is an issue because > the early parts of the repo don't have complete trees. > > I'm now testing a conversion on the Great Beast that puts these in > place. If all goes well I will push this capability to the public > conversion repository later today. > > You can audit the reconstruction process by reading the script I wrote > to automate it: > > https://gitlab.com/esr/gcc-conversion/blob/master/ancients > > Unfortunately, I was only able to find valid patch chains to three > releases that don't have complete tarballs. > > If anyone else can scrounge up materials that could help complete > the fossil sequence, now would be a really good time for that. We > have only three days at most left to integrate them.
Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?
Andrew Haley wrote: On 01/10/2010 12:39 PM, Andreas Schwab wrote: Andrew Haley a...@redhat.com writes: Why do you say the effective type is different? The object type is uint8_t, but accessed as uint32_t. That is undefined. Unless uint8_t is a character type, as I understand it. That is clearly the assumption on which the code relies. But in the new compilers it's an integer type, not a character type--from the spec: 7.18.1.1 Exact-width integer types 1 The typedef name intN_t designates a signed integer type with width N , no padding bits, and a two’s complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. 2 The typedef name uintN_t designates an unsigned integer type with width N . Thus, uint24_t denotes an unsigned integer type with a width of exactly 24 bits. 3 These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement representation, it shall define the corresponding typedef names. Patrick
Re: GCC aliasing rules: more aggressive than C99?
Nick Stoughton wrote: Herb is C++ ... The C1x timetable has us finishing the draft for an initial ballot this summer (the April Florence meeting being the last chance to submit new material). The best expert I know on the type based aliasing stuff is Clark Nelson at Intel (clark.nel...@intel.com). We did spend a considerable amount of time at the recent Santa Cruz meeting discussing this subject ... see N1409 and N1422 (the minutes including a summary of the discussion on N1409). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1409.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1422.pdf I've read these, and while they deal with the same section of the standard, the issues are quite different. Patrick
Re: GCC aliasing rules: more aggressive than C99?
Erik Trulsson wrote:
Moreover I think you are misinterpreting 6.5 clause 7 (which I concede is
fairly easy since it is not quite as unambiguous as one could wish).
I believe that paragraph should not be interpreted as automatically allowing
all accesses that correspond to one of the sorts listed. Rather it should
be interpreted as saying that if an access is not included in that list then
it is not allowed, but even if it is included in that list there could be
other reasons why it is not allowed. (I.e. just as the attached footnote
suggests it is a list of what types of aliasing are allowed, not of which
pointers may be dereferenced.)
Good point, they're saying that something other than this list is
undefined for sure.
While the C Standard says in this section:
7 An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:78)
with footnote 78 saying:
78) The intent of this list is to specify those circumstances in which
an object may or may not be aliased.
The same section of the C++ standard says:
15 If a program attempts to access the stored value of an object through
an lvalue of other than one of the following types the behavior is
undefined:49)
with footnote 49 saying:
49) The intent of this list is to specify those circumstances in which
an object may or may not be aliased.
The content of the section is almost identical, and both say identically
word for word:
— an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union),
and I think that the intent of the C version is the same as the C++
clearly states. This is a list of all the ways to access a stored value
through an lvalue. Anything else is undefined behavior. So constructing
code to bypass the pointer issues, gcc does allow accessing an int value
through a lvalue that is a union that contains an int like this:
int i;
union u{ int x; };
printf(%d\n,(*((union u*)i)).x);
although it's perverse, it doesn't seem to break any aliasing rules and
neither gcc (nor g++ with an equivalent std::cout line), complain about
it with maximum aliasing bitching turned on. And indeed, the problems
with aliasing are more like the cool part about the structs I elided
above. -fstrict-aliasing is a promise to the compiler that you aren't
going to do weird things like:
void foo(int, float);
union u{
int a;
float b;
}
foo(u.a, u.b);
so that it can do some types of optimizations it couldn't otherwise do.
-Wstrict-aliasing tries to warn you if you break the promise, although
if the definition and call are in different compilation units gcc won't
know.
A funnier example of something that seems not to break the above
aliasing rules, (really equivalent to the printf above), the following
when compiled with -fstrict-aliasing -Wstrict-aliasing=3 doesn't get
complained about by 4.4.1 or 4.5.0 at least.
#include stdio.h
union u { int x; };
void
foo(union u theu)
{
printf(%d\n,theu.x);
}
int main()
{
int i=7;
foo(*((union u*)i));
return 0;
}
Patrick
Re: GCC aliasing rules: more aggressive than C99?
Richard Guenther wrote: On Sun, Jan 3, 2010 at 6:46 AM, Joshua Haberman jhaber...@gmail.com wrote: ... elision by patrick of part of a quote of 6.5 Expressions #7... * an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or Literally interpreting this sentence the way you do removes nearly all advantages of type-based aliasing that you have when dealing with disambiguating a pointer dereference vs. an object reference and thus cannot be the desired interpretation (and thus we do not allow this). Since it would be hard to read this any other way, it seems then you maintain that you found a bug in the standard, has it been brought up to the committee? The latest draft I see still has that wording. Doesn't seem to be on the radar for C1x. This same thing has bitten me, though I agree with your rationale about how it would be a bad idea, still strictly speaking, gcc is not standards compliant on this one point, and rather than change gcc, the defect in the standard could be changed. If you don't have anyone participating on the committee right now, you only have to convince some one who is, e.g. Nick Stoughton or P. J. Plauger or Herb Sutter, right? It basically would force us to treat *ptr vs. Obj as *ptr vs. *(Obj *)ptr2. ...more elision I have seen other articles that interpret the standard in this way. See section Casting through a union (2) from this article, which claims that casts of this sort are legal and that GCC's warnings against them are false positives: http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html Yes, this article contains many mistakes but the author failed to listen. This one thing is, you say, not a mistake of the author but a mistake in the standard, and it's unkind to characterize it like that grin; ...elided a bunch--patrick... Correct. GCC follows its own documentation here, not some random websites and maybe not the strict reading of the standard. There are other corner-cases where it does so, namely with the union type rule (which I fail to come up with a std reference at the moment). I hope in all of these cases it's been brought up as an issue, defects in the standard won't get fixed if there are no squeaky wheels! Patrick
