Re: [RFC] expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg [target/111466]
> At that particular time I think Kenner was mostly focused on the alpha > and ppc ports, but I think he was also still poking around with romp and > a29k. I think romp is an unlikely target for this because it didn't > promote modes and it wasn't even building for several months > (April->late July). Obviously, I have no recollection of that change at all. In July of 1994, I don't believe I was actively working on much in the way of ports, though I could be misremembering. My guess is that this change was to fix some bug, but I'm a bit mystified why I'd have batched so many different changes together in one ChangeLog entry like that. I think you're correct that it was most likely the Alpha that showed the bug.
Re: [RFC] Add conditional compare support
> That doesn't sound like the right place to me. We want the same code to > be generated whether users write && and || directly or write corresponding > sequences of if conditions. In general we want to move away from > optimizing complicated expressions in fold-const, towards having GIMPLE > passes that detect the relevant patterns however they were written (and > without needing to combine GIMPLE back into trees for passing through the > old folder). I'm not convinced that it's an "either or". Certainly the optimization needs to be in one of the GIMPLE passes for exactly the reason you give. Theoretically, fold-const need do nothing, but I think that's only in "theory". Giving later-pass optimizers better code when possible at least speeds up the process and at best produces better generated code. Obviously, one can't do everything everywhere, but I wouldn't reject doing something earlier just because it's also done later.
Re: gcc's obvious patch policy
> The thing about written policy is that it sets the tone for a project. > A restrictive policy tends to authoritarian rule by maintainers, it > seems to me. And a too little restrictive policy runs the risk of creating a feeling that the rules aren't necessarily to be taken too seriously. Neither outcome is good.
Re: RFC: stack/heap collision vulnerability and mitigation with GCC
Out of curiousity, does the old Alpha/VMS stack-checking API meet the requirements? From what I recall, I think it does.
Re: RFC: stack/heap collision vulnerability and mitigation with GCC
> > Out of curiousity, does the old Alpha/VMS stack-checking API meet the > > requirements? From what I recall, I think it does. > Unsure. Is this documented somewhere? It seems to be in http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04621389 starting at page 3-54.
Re: [PATCH] [Aarch64] Optimize subtract in shift counts
> This patch improves code generation for shifts with subtract > instructions where the first operand to the subtract is equal to the > bit-size of the operation. I would suspect that this will work on lots of targets. Is doing it in combine an option?
Re: [PATCH] [Aarch64] Optimize subtract in shift counts
> That is simplify: > (SHIFT A (32 - B)) -> (SHIFT A (AND (NEG B) 31)) > etc. I think you need SHIFT_COUNT_TRUNCATED to be true for this to be valid, but this is exactly what I was getting at in my last message.
RE: [PATCH] [Aarch64] Optimize subtract in shift counts
> On Aarc64 SHIFT_COUNT_TRUNCATED is only true if SIMD code generation > is disabled. This is because the simd instructions can be used for > shifting but they do not truncate the shift count. In that case, the change isn't safe! Consider if the value was negative, for example. Yes, it's technically undefined, but I'm not sure I'd want to rely on that.
RE: [PATCH] [Aarch64] Optimize subtract in shift counts
> The pattern will only be matched if the value is positive. More > specifically if the constant value is 32 (SImode) or 64 (DImode). I don't mean the constant, but the value subtracted from it. If that's negative, then we have a shift count larger than the wordsize.
RE: [PATCH] [Aarch64] Optimize subtract in shift counts
> This case is covered by Wilco's previous reply:
>
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00575.html
Which I don't understand:
> No it's perfectly safe - it becomes an integer-only shift after the
> split since it keeps the masking as part of the pattern.
Let say we have your first example:
long f1(long x, int i)
{
return x >> (64 - i);
}
If "i" is -2, this should be a shift of 66 (which is indeed, technically
undefined), but becomes a shift of 62. What am I missing?
RE: [PATCH] [Aarch64] Optimize subtract in shift counts
> Because for integer shift instructions the shift count is > truncated. We ensure that we only use integer shift instructions by > emitting a shift with a mask. This only matches integer shift > instructions in the md file. That's why I asked about SHIFT_COUNT_TRUNCATED. So it's truncated for some shifts, but not all?
RE: [PATCH] [Aarch64] Optimize subtract in shift counts
> Correct. It is truncated for integer shift, but not simd shift > instructions. We generate a pattern in the split that only generates > the integer shift instructions. That's unfortunate, because it would be nice to do this in simplify_rtx, since it's machine-independent, but that has to be conditioned on SHIFT_COUNT_TRUNCATED, so you wouldn't get the benefit of it.
Re: [PATCH doc] use "cannot" consistently
> The GCC manual uses "cannot" in most places (280 lines) but there > are a few instances of "can't" (33 lines). > > The attached patch replaces the informal "can't" with the former > for consistency. In my opinion, this is the wrong direction. Contractions are becoming more acceptable in even more formal writing and there's even a current US Supreme Court justice who uses them in her opinions. I certainly don't think it's worth a change to use "can't" throughout, but I'm not in favor of eliminating it either.
Re: [PATCH doc] use "cannot" consistently
> First, I agree that the less formal language is becoming more > acceptable. Some style guides explicitly allow contractions, > but others advise against them. The technical specifications > that significant parts of GCC aim to conform to, and those I > happen to work with the most closely (the C, C++, and POSIX > standards), avoid them. The IEEE Editorial Style Manual > recommends against using them. The author of Engineer's Guide > to Technical Writing, Kenneth Budinski, equates them with slang. How old are those documents? More recently, see http://www.plainlanguage.gov/howto/guidelines/bigdoc/writeContract.cfm https://lawyerist.com/61487/is-it-time-for-contractions-in-legal-writing/ The latter references other documents, which advocate for more use of contractions even in formal writing. > I personally don't feel too strongly about it, but the change > seems like an opportunity to improve not just the style of > the manual but also increase its consistency. I could see > one being indifferent to such changes but I have trouble > understanding how they could be viewed as the wrong direction. > What is your rationale against it and what would you consider > the right direction for the manual? I think it's the wrong direction because I'd be in favor of gradually *introducing* contractions into to the manual instead of a change that eliminates them. I wouldn't be against a change that went in the other direction (used contractions consistently), but it would be good a large change, so I'm not advocating for doing that, but just instead using contractions in all new material and when modifying old material for other reasons.
Re: [PATCH doc] use "cannot" consistently
> > The latter references other documents, which advocate for more use of > > contractions even in formal writing. > > These are legal guides, not obviously relevant in the context > of technical writing. Yes and no. The argument for them is that legal writing is the most formal of all and has been the slowest to adopt contractions.
Re: [PATCH 1/3] Put a TARGET_LRA_P into every target
> "returns always true" -> "always returns true" ? > > (The former is how we'd say it in German, and hence might be common in > Dutch as well? In English, both probably are fine, the latter feeling > more natural to me. But then, I'm not a native speaker. ;-) The former is unusual in English and borders on being "wrong". It would be parsed as saying that it returns something called "always true", as if that were a construct.
Re: Change license of filenames.h to LGPL
> Sorry, I don't understand. Surely anything released under the LGPL by > the FSF can be upgraded to the current GPLv3? First upgrade to the > latest LGPL, then switch over to the GPLv3? That seems correct to me.
Re: msp430 port
> register int a; > extern volatile int b; > > a = b; > a |= 0x54; > b = a; > > The ISO spec seems to allow gcc to perform those operations in a > single physical insn, as long as the operations on 'b' are all > performed, and in the correct sequence. And I believe it's also consistent with the "traditional" view of volatile if that were done with a single read-modify-write insn.
Re: [DOC PATCH] Rewrite docs for inline asm
> >>> any symbols it references. This may result in those symbols getting > >>> discarded by GCC as unreferenced. > > > > We can omit "by GCC" here. > > We can, but we should not. We should avoid the passive voice like the > plague in technical documentation, even if doing so leads to some > slight redundancy. I agree, but that's still passive voice (you need not omit the actor to be using passive voice)! Active voice (which is indeed preferred) is "This may result in GCC discarding those symbols as unreferenced." (For those who don't know, a good test of whether something is the passive voice is that you *could* remove the actor and the sentence would still be grammatically correct. That's the case above.) Writing in the passive voice with the actor present is indeed better than the passive voice with the actor removed, but the active voice is still the preferred style.
Re: [Patch,AVR] Print no-return functions as JMP
> +@item -mjump-to-noreturn > +@opindex mjump-to-noreturn > +Use a jump instruction instead of a call instruction when calling a > +no-return functions. This option is active if optimization is turned > +on and just affects the way a call instruction is printed out. > > Would "emit" be better here than "printed out"? Maybe "generated"?
Re: [PATCH] Remove bogus TYPE_IS_SIZETYPE special-casing in extract_muldiv_1
Let me jump in on this a little bit, since much of the code in this area was originally written by me. > Are all sizetype (sub-)expressions always of value in that range? > What do we do about the fact that sizetype is unsigned, so -x always > overflows for x != 0? Thus, do we need to disable all a - b -> a + > -b kind of foldings for sizetypes? (we don't) The basic idea is that an overflow of sizetype is either: (1) Detected at a higher level (e.g., testing for maximum sizes of objects) or; (2) Is an undetected error and hence the result of such overflow is undefined. What this means from a practical point of view (but indeed a bit hard to define from a formal point of view) is that the normal addition and subtraction operations (on a 2's complement machines, which all are now) will "do the right thing" in all cases so we can perform all those sorts of folding operations.
Re: [PATCH] Remove bogus TYPE_IS_SIZETYPE special-casing in extract_muldiv_1
> So what's your opinion on the "bug" that triggered the patch in question? > Namely extract_muldiv_1 folding > > (((10240 - (sizetype) first) + 1) * 8) /[cl] 8 > > to > > ((sizetype) first * 0x0fff8 + 81928) /[cl] 8 > > to > > ((sizetype) first * 2305843009213693951 + 10241) > > thus, folding A - B to -B + A, which is valid for unsigned types only > if overflow wraps. I think the tricky part is the optimization of (-X) * 8 to (-8 * X), especially if you then try to compute the -8 as unsigned. I don't think that's valid no matter what overflow does, but I still have a hard time reasoning about these things. > Can you give a formal definition of sizetype behavior that can be > used to prove that both transforms are valid? No, that's what I said before: I don't now have and never did have a formal definition. Which was not good.
Re: [PATCH] Remove bogus TYPE_IS_SIZETYPE special-casing in extract_muldiv_1
> And as you are here now, can you shed some light on the weird > decision to make sizetype TYPE_UNSIGNED but sign-extended > at the same time? ;) Basically, to make division work properly given that the type is unsigned.
Re: [PATCH] Remove bogus TYPE_IS_SIZETYPE special-casing in extract_muldiv_1
> So what's your opinion on the "bug" that triggered the patch in question?\ > Namely extract_muldiv_1 folding > > (((10240 - (sizetype) first) + 1) * 8) /[cl] 8 > > to > > ((sizetype) first * 0x0fff8 + 81928) /[cl] 8 > > to > > ((sizetype) first * 2305843009213693951 + 10241) I think this optimization "works" if you sign-extend the constant when you do division by 8.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> X86 backend doesn't accept the new expression as valid address while > (zero_extend:DI) works just fine. This patches keeps ZERO_EXTEND > when zero-extending address to Pmode. It reduces number of lea from > 24173 to 21428 in x32 libgfortran.so. Does it make any senses? I'd be inclined to have the x86 backend accept combine's canonicalized form rather than doing a patch such as this.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> 1. The placement of subreg in > > (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ]) > (const_int 4 [0x4])) 0) > (subreg:DI (reg:SI 106) 0)) > > isn't supported by x86 backend. That's easy to fix. > 2. The biggest problem is optimizing mask 0x to > 0xfffc by keeping track of non-zero bits in registers. > X86 backend doesn't have such information to know > ADDR & 0xfffc == ADDR & 0x. But this indeed isn't. I withdraw my comment. I still don't like the patch, but I'm no longer as familiar with the code as I used to be so can't suggest a replacement. Let's see what others think about it.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> Same here, I don't like it but I hardly see any alternative. The only > possibility could be to prevent calling expand_compound_operation > completely for addresses. Richard, what do you think? Don't worry, > combine hasn't changed much since your days. :) The problem wasn't potential changes to combine, but my memory ... But now I refreshed it and understand the issue. expand_compound_operation and make_compond_operation were meant to be used as a pair. You first do the former, then see if the result can be simplified, then call the latter in case it couldn't. In the SET case, we call the latter in simplify_set. But there's also this code in combine_simplify_rtx: case MEM: /* Ensure that our address has any ASHIFTs converted to MULT in case address-recognizing predicates are called later. */ temp = make_compound_operation (XEXP (x, 0), MEM); SUBST (XEXP (x, 0), temp); break; THAT'S the code that should do the transformation that this patch contains. So I'd suggest doing some debugging and seeing why it isn't. This could just be a bug in make_compound_operation not handling the SUBREG.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> Or being fooled by the 0xfffc masking, perhaps. No, I'm pretty sure that's NOT the case. The *whole point* of the routine is to deal with that masking.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> at the end. make_compound_operation doesn't know how to > restore ZERO_EXTEND. It does in general. See make_extraction, which it calls. The question is why it doesn't in this case. That's the bug.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> It never calls make_extraction. There are several cases handled > for AND operation. But > > (and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ]) >(const_int 4 [0x4])) 0) >(subreg:DI (reg:SI 106) 0)) >(const_int 4294967292 [0xfffc])) > > isn't one of them. Yes, clearly. Otherwise it would work! The correct fix for this problem is to make it to do that. That's where this needs to be fixed: in make_compound_operation.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> An and:DI is cheaper than a zero_extend:DI of an and:SI. That depends strongly on the constants and whether the machine is 32-bit or 64-bit. But that's irrelevant in this case since the and:SI will be removed (it reflects what already been done).
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> We first expand zero_extend:DI address to and:DI and then try > to restore zero_extend:DI. Why do we do this transformation > to begin with? Suppose there were an outer AND that duplicated what this one did. Then when you combine those two, you merge it to one AND. Then make_compound_operation puts it back. The net result is to eliminate the outer AND. There are lots of similar sorts of things. As I said, the strategy there was to convert extractions and expansions into the corresponding logical and shift operations, see if they can merge with something outside (which is similarly converted), then convert the result (possibly merged) back. This, for example, is the code that will remove nested SIGN_EXTENDs.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> The answer to H.J.'s "Why do we do it for MEM then?" is simply > "because no one ever thought about not doing it" No, that's false. The same expand_compound_operation / make_compound_operation pair is present in the MEM case as in the SET case. It's just that there's some bug here that's noticable in not making proper MEMs that doesn't show up in the SET case because of the way the insns are structured.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> Does it look OK? No. If I understand your code correctly, there's essentially the same code as you have a bit above that: /* If the constant is one less than a power of two, this might be representable by an extraction even if no shift is present. If it doesn't end up being a ZERO_EXTEND, we will ignore it unless we are in a COMPARE. */ else if ((i = exact_log2 (INTVAL (XEXP (x, 1)) + 1)) >= 0) new_rtx = make_extraction (mode, make_compound_operation (XEXP (x, 0), next_code), 0, NULL_RTX, i, 1, 0, in_code == COMPARE); So you need to understand why your code "fires" and it doesn't.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> It is because mask 0x is optimized to 0xfffc by keeping track > of non-zero bits in registers and the above code doesn't take that > into account. Then I'd suggest modifying that code so that it does rather than essentially duplicating it. But I'd recommend running some performance tests to verify that you're not pessimizing things when you do that: this stuff can be very tricky and you want to make sure that you're not converting something like (and X 3) into a bit extraction unnecessarily.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> But the current code converts (and X 3) into a bit extraction > since ((i = exact_log2 (UINTVAL (XEXP (x, 1)) + 1)) >= 0) is true > when UINTVAL (XEXP (x, 1)) == 3. Should we do it or not? By adding the test for nonzero bits, you'd potentially be doing the conversion more often (which is the point of this patch, after all) and it's therefore necessary to be sure you're not doing it *too* often.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> I am testing this patch. The difference is it checks nonzero > bits of the first operand. I would suggest moving (and expanding) the comments from the existing block into your new block.
Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea
> Like ths? Yes, that's what I meant. Thanks. Again, I'd suggest doing some performance testing on this just to verify that it doesn't pessimize things.
Re: Remove obsolete Solaris 8 support
> One of the nice things about gcc is that gcc usually still works, > long after a vendor has abandoned a machine. I rather like that gcc > will just work, unlike vendor software, which often says, please buy > a new machine. One doesn't have to remove support in gcc for > something, just because a vendor doesn't support it. That said, > truly crufty things, should go. I agree. If it's not causing a serious maintenance issue, I see no reason to remove it.
Re: RFC: allowing fwprop to propagate subregs
> [Richard, combine question at the bottom for you. I've quoted Ulrich's > whole message in order to provide a bit of context.] I don't remember ALL of this, but can perhaps make a few hints. > > The problem appears to be that an RTX expression like > > > > (minus:QI (subreg:QI (reg:SI 64 [ a ]) 0) > > (subreg:QI (reg:SI 66 [ b ]) 0)) > > > > seems to be considered non-canonical by combine, and is instead > > transformed into > > > > (subreg:QI (minus:SI (reg:SI 64 [ a ]) > > (reg:SI 66 [ b ])) 0) > > On the one hand, this seems odd, as SUBREGs with a non-trivial > > expression inside will usually not match any insn pattern. On > > the other hand, I guess this might still be useful behaviour > > for combine on platforms that support only word arithmetic, > > when the SUBREG might be considered a "split" point. No, I think the idea was that the outer SUBREG would be moved to the LHS of the assignment to make a "paradoxical SUBREG". Except, as you point out, there doesn't seem to be an advantage of doing this for arithmetic unless you only have it in SImode (which it could, of course, check). > (Of course, this doesn't work for the compute-result-and-cc type patterns.) Right. > No immediate suggestions, sorry. It looks like the combine case was > added by this pre-egcs patch: > > Wed Mar 18 05:54:25 1998 Richard Kenner > > * combine.c (gen_binary): Don't make AND that does nothing. > (simplify_comparison, case AND): Commute AND and SUBREG. > > so maybe Richard remembers (or has a record of) what this was designed > to handle? I suspect the two halves related to each other: we commute AND and SUBREG in the hope that this will allow us to decide that the AND does nothing and isn't needed. But I don't see how this is related: this is the AND case in a comparison and we have a MINUS.
Re: RFC: allowing fwprop to propagate subregs
> Maybe the best solution would be to remove the SUBREG case from the generic > apply_distributive_law subroutine, and instead add a special check for the > distributed subreg case right at the above place in simplify_set; i.e. to > perform the inverse distribution only if it is already guaranteed that we > will also be able to move the subreg to the LHS ... That could indeed work.
Re: RFC: allowing fwprop to propagate subregs
> I tried to implement that suggestion, but interestingly enough I cannot > really test it since I was unable to find any single case where that > SUBREG case in apply_distributive_law actually causes any difference > whatsoever in generated code. > > Do you have any further suggestion of how to find a testcase (some > particular source code and/or architecture)? No. It may well be irrelevant now and was only relevant in cases where we just had SImode and not the narrower modes on some of the older architectures such as a29k. It may also be that the optimizations that this caught are now done at tree level, though I think the former is the more likely. > Given the current set of results, since I do not have any way to verify > whether my simplify_set changes would actually trigger correctly, I'd > rather propose to just remove the SUBREG case in apply_distributive_law > (i.e. only apply the first patch below). > > Thoughts? I think that's reasonable. But I'd replace it with a comment saying what used to be there and why it was removed.
Re: [patch, libffi] Sync merge libffi
> My personal opinion is that it is better if open source software is not > encumbered by multiple copyright > holders. A copyright holder probably has the right to change the work's > permission notice. Off-topic, but that works both ways: if you want to ensure that a work's license's terms will never change, having a huge number of copyright holders is one of the best ways to do that.
Re: Delete dead (?) code in expand_expr_real_2
> I found a weird piece of code that was added by kenner in a really early > revision. It checks for VAR_DECLs with frame or stack pointers as > DECL_RTL, and the comment in front of it mentions strength reduction. > Presumably this was for the old loop optimizer? I can't think of > anything that would require this in a modern version of gcc. I think such a VAR_DECL would occur in cases of alloca. I don't understand the comment about strength reduction (despite obviously having written it!) because the old loop optimizer ran on RTL and this is talking about trees. My guess is that this isn't dead.
Re: Delete dead (?) code in expand_expr_real_2
> I don't see how a VAR_DECL can ever get a DECL_RTL equal to one of > the mentioned regs. Doesn't that happen when you have a local variable that's a variable-sized object? What would have changed that would cause it to no longer happen? This is tree-level stuff, not RTL. > The patch is ok if a gcc_unreachable () inside the if () passes bootstrap. We have no such in most of the compiler, so I don't think that's a good test. There may be some in Ada, but I'm not sure. I'd suggest running it over all the test suites as well.
Re: Delete dead (?) code in expand_expr_real_2
> VLA VAR_DECLs have just DECL_HAS_VALUE_EXPR_P set and DECL_VALUE_EXPR being > INDIRECT_REF (or MEM_REF now?) dereferencing some DECL_ARTIFICIAL VAR_DECL > that is initialized from alloca builtin.So the VLA VAR_DECLs don't have > any DECL_RTL at all (kept for debug info purposes only), and the artificial > pointer to it will just have as DECL_RTL some pseudo or so. That change may well have killed this code, then.
Re: Fix warnings in build with G++
> > FWIW, elsewhere in gcc we use "continue;" for empty loop bodies. > > I think I've never run into this idiom in about a decade of work on GCC. :-) Nor have I. I'm used to seeing just a ";" on its own line.
Re: [google]: initialize language field for clone function struct
> That's what we should phase out. The eventual aim should be for (a) > folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees) > as an optimization and (b) folding done by front ends only when required > for language semantics (e.g. constant expressions). Why? Isn't it always better to optimize as early as you can when it's easy? Why keep unfolded constants around at all?
Re: [google]: initialize language field for clone function struct
> There are pros and cons about early optimization, actually. > Generating extremely optimized IL very early can actually tie up > subsequent passes. For instance, loop unrolling and vectorization. > There are others in the literature. Sure, in the sorts of examples you mention where there's a level of "globality" to it. But I don't see it in the types of things that fold does. How could it ever be better to leave "a - a" in the tree instead of "0"?
Re: [google]: initialize language field for clone function struct
> I think we may be talking at different levels. It's my impression > that Richard K. was referring to local transformations like "a - a" -> > "0" once we are in the middle end. I agree that doing that > transformation close to the FE is undesirable, but once we are in the > middle end that should be fine. That's exactly what I mean. If the FE cares about no folding taking place, it shouldn't fold. But once we're past the point that it's doing syntax and semantic checking, there's no optimization benefit in deferring the folding until we get to SSA, for example.
Re: GAS GCC FAQ query
> Agreed. Things would have been different twenty years ago, but these > days using linker is a lot more natural and common (as a grep in gcc/doc > confirms, too). Even 20 years ago, I think "linker" would have been the more natural word. I remember "linker" from my IBM days in the early 80's.
RE: [PATCH] COBOL 3/8 gen: GENERIC interface
> Or maybe write a blog post about how to do a new > GCC frontend (there are multiple such for backends). But I know time > is scarce. I made a set of slides a few decades ago on doing that. It's somewhat, but not fully, out of date and I don't know how to find them, but it does exist somewhere.
Re: The COBOL front end, version 3, now in 14 easy pieces (+NIST)
Paul Koning wrote: > >> As I mentioned in other posts, IMO (IANAL) the copyright in > >> unimportant and probably unenforceable. The National Computing > >> Centre no longer exists, and the document was also published by NIST > >> which, as part of the US government, does not copyright its > >> publications. > > > > In the United States. It is generally assumed that the > > U.S. government can claim copyright on its works abroad. > > Really? That's puzzling. It's my understanding that works of the > United States are, by law, in the public domain. Yes, but what are "works of the United States"? 17 USC 105 specifically says that the government "is not precluded from receiving and holding copyrights transferred to it by assignment". If a Federal employee creates a work as part of their duties, that work cannot be copyrighted. But if the government hires a contractor to create a work and that contractor transfers their copyright of the work to the government, that work *is* copyrighted by the US. So the criteria isn't whether it was created in the US or abroad, but whether it was created by employees or contractors and, in the latter case, whether the contractor copyrighted the work or not.
Re: [PATCH] wwwdocs: Do not rewrite the page titles
> I don't see why we should have to "comply with the GNU style" if we're > truly an independent project run by the GCC developers and aided by > the steering committee. I think it critical than any code have *some* style guidelines. If you don't like the GNU coding convention, which do you propose instead and how do you propose to convert the existing code to that style?
