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: Network Services Alert#489707
> Maybe if you spent less time worried about inconsequential things > like people's "offensive" language, and more time worried about how > your country (you live in the Western world, correct?) We are all responsible for our choice of words. We aren't responsible for the actions or policies of the country we happen to live in.
Re: "file name" vs "filename"
> A "file name" is the file's name. It is a property of a file, like the > inode or size. The name exists (or not) regardless of whether we know > what it is. > > A "filename" is a syntactic element, the thing itself, a string of > characters. It is supplied as input or rendered as output. For what it's worth, I agree.
Re: rust non-free-compatible trademark
> A Certification Mark is the proper way to formally and legally enforce such > requirements. BTW, nobody is or was at all confident that the Ada mark was legally enforcable. I'm in the camp that it isn't. > telling people they cannot patch the source code without permission Nobody is telling people that. What they're saying is the same thing as the GPL does: it you distribute modified code, you need to be clear that what you're distributing is a modification.
Re: rust non-free-compatible trademark
> In order to be a validated Ada compiler, a compiler must pass > an extensive suite of programs called the Ada Compiler Validation > Capability (ACVC). FYI: the current name for this is ACATS: Ada Conformity Assessment Test Suite. >"to be able to use the word rust in a distributed compiler your > modifications must 100% pass the test suite without modifying > the test suite" What does "in" mean here? Is "rust" modifying "language" or "compiler" in this case? As was stated, that's a significant difference. > a thorough investigation of how it was done for ADA should reveal > how it can be properly done for gccrs and rustc. It's a very different situation. Ada was a standardized language via a very formal process. And it was a very different time.
Re: rust non-free-compatible trademark
> Normal use of a word isn't something that Trademarks prevent. In general, no, but what it prevents is using the word in a way that would produce confusion with an "official" use of that mark. If the word that constitutes the mark is too general, then the trademark shouldn't have been granted. But let's assume that somebody has trademarked a common adjective, which we'll call "adjective", when applied to noun "noun". If I write "I have an adjective noun", that's supposed to refer to the trademarked it. If it instead refers to some other item (e.g., in our case a compiler with patches), that's a trademark violatio.
Re: Inquiry: Country of Origin for gfortran
> If these bureaucratic parasites (but I repeat myself) don't want to > use GCC, or Clang, then they can write their own compiler suite from > scratch. Doubt that's going to happen, so this "investigation" is > simply yet another frivilous waste of taxpayer dollars. I won't blame this on bureaucrats. Congress is who passed the law (in 1933). These folks are just checking the boxes.
Re: rust non-free-compatible trademark
> I think you are misinterpreting when you need a trademark license for > usage a word mark in an implementation of a compiler for a programming > language. Note that gcc used to come with a full implementation of the > Java programming language, compiler, runtime and core library > implementation (for which I was the GNU maintainer). None of that > required a trademark license because the usage of the word java was > just for compatibility with the java programming language. Was "Java" a trademark for both the language and compiler or just the language? What about "rust"? That would seem to make a difference. If the trademark is just for the language, then when you say you have a "compiler for the XYZ language", you're refering to the trademarked entity (the language) and you can always use a trademark to refer to the trademark owner's product. But if the trademark is also for the compiler and you have a different compiler (even if it differs just by patches), you need the permission of the trademark owner to call you compiler by the trademarked name.
Re: rust non-free-compatible trademark
> just as with the Java Trademark, you as developers can say "gust is > compatible with the rust language" but you *cannot* say "gust is > compatible with rust". Note that trademarks are adjectives, not nouns (and only apply to specific nouns, so I'm not sure what you mean here.
Re: Inquiry: Country of Origin for gfortran
> Should this question be posed to the Linux distribution that NASA is using? Yes, most likely. But exactly how Free Software fits into the Buy America Act (what she's talking about) is less than clear.
Re: Update to GCC copyright assignment policy
> > What about the parts of GCC with FSF copyrights that are not covered by > > the GPL, but the GPL with exceptions? How is it possible to move code > > between the parts if a contributor previously used DCO and thus gave > > only permission to license under the open source license "indicated in > > the file"? > > Depends on which DCO you uses. Various project use the following DCO, > which makes clear you assign permissions under all applicable licenses > (this helps if the project uses more than one, possibly incompatible, > license and/or is dual licensed): See above. The issue is if the project wants to change the status of a file from GPL to GPL plus exception. It can't do that if there was a change to the file made by somebody who did't assign the copyright. What's said in the DCO you cite doesn't help.
Re: removing toxic emailers
> That would surely only be relevant if people wanted to use their > telephones to compile code? That's not completely clear. It would certainly be true if the compiler were included on the phone, whether or not the compiler was actually used. But I was more addressing the general comment that Google doesn't care about GPLv3 than the specific issue of GCC. If the kernel were GPLv3, for example, there would be an issue with what Samsung is doing.
Re: removing toxic emailers
> Just for the record, Google has no problem with the GPLv3. Google stopped
> working on GCC because they made a company decision to use clang instead.
> That decision was made for technical reasons, not licensing reasons.
But note that some cellphone manufacturers (e.g, Samsung) have taken
steps to prevent non-signed binaries from being loaded in their phones.
This would have been problematic ("Tivoisation") if GPLv3 code was
included in Android.
Re: On US corporate influence over Free Software and the GCC Steering Committee
> Troubling indeed, but this might just be an overzealous manager. > IBM, like other corporations, has made significant technical > contributions to GCC over the years, for example the scheduler and > the vectorizer, and thus has assigned the copyright of these > contributions to the FSF. Yes, as long as the employee is doing it as part of their work for IBM, which was the case in your examples. What's never been OK for IBM are their employees doing software development "on their own time" because they've taken the position that such doesn't exist.
Re: On US corporate influence over Free Software and the GCC Steering Committee
> You are an IBM employee 100% of the time. For those who aren't aware of it, this has been IBM's position for many decades. It's not a new position. But they are unique in the extremeness of their position on this, so generalizing this would be a mistake.
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?
Re: A suggestion for going forward from the RMS/FSF debate
> It is an argument against the idea that LLVM is the default way that > people choose. I don't think that anybody made the argument that LLVM is the "default" in any sense. What's being given here are reasons why some people prefer LLVM over GCC. > In those places, they don't trust Microsoft or anybody that provides > software products that are difficult or impossible to review. Free > software is not prohibited, since the government has access to the > source code. Any tool that comes compiled is not acceptable there. For a compiler, of course, you need a compiled version of it to start with. If you use that same compiler to build itself, having the source code does *not* protect you from malware, as Ken Thompson showed back in 1984. Even if you take the stance that you'll compile GCC with LLVM and vice versa, you still have the risk that both of the binaries have been compromised in this way.
Re: identifying toxic emailers (was: removing toxic emailers)
> So I think it's quite reasonable to expect that their employers could > read the SC's secret exchanges (since they technically CAN read them). I'm a bit lost here. What do you think is the content of "the SC's secret exchanges"?
Re: A suggestion for going forward from the RMS/FSF debate
> Depends on the use cases. Not in military surveillance. And certainly not > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > I'm not sure. Before 2011, rather than building things from scratch, > washington bureaucrats simply picked from among existing technology. But > things had really been going berserk around 2008. From 2017 onwards, > I'm somewhat in the dark. They could have started allowing some ownership > rights, but ownership rights under government contracts are very different > than ownership rights under commercial contracts. I can't understand your point with this version either. Sorry.
Re: A suggestion for going forward from the RMS/FSF debate
> You will not get funding grants in the US if you mention free software, > because the US Department of Commerce does not allow it. This is not correct and I suspect is a misunderstanding of what "government data rights" means.
Re: A suggestion for going forward from the RMS/FSF debate
> >> It would be usefull to clarify with the FSF and GNU what the > >> actual relations are, > > Why? What would that gain? I go back to my analogy of the British Queen. > > What would be gained by "clarifying" that if she actually intervenes > > non-trivially in the government of any Commonwealth nation, she'd lose > > that power? > > There are differences between the queen and RMS, even if the image > has some merit. I was refering more to the FSF and GNU project here than to RMS.
Re: A suggestion for going forward from the RMS/FSF debate
> The authority of the FSF, GNU and RMS over GCC is and has been a > fiction for decades, For the most part, I agree. > It would be usefull to clarify with the FSF and GNU what the > actual relations are, Why? What would that gain? I go back to my analogy of the British Queen. What would be gained by "clarifying" that if she actually intervenes non-trivially in the government of any Commonwealth nation, she'd lose that power?
Re: removing toxic emailers
> The choice to /not/ have a policy for ejecting jerks has serious costs. > One of those costs is the kind of rancorous dispute that has been > burning like a brushfire on this list the last few weeks. Although I agree with the sentiment, there's a real risk that if we were heading in that direction, we'd be replacing part of that rancorous dispute with another rancorous dispute, this time about whether to eject people.
Re: removing toxic emailers
> The choice to have a policy for ejecting jerks has serious costs. > One of those costs is the kind of rancorous dispute that has been > burning like a brushfire on this list the last few weeks. I agree. Look at the huge ongoing debate about Section 230 in the US that's been going on for at least months. This is something that seems like it ought to have a simple solution, but it doesn't.
Re: GCC association with the FSF
> For developers, I think the GPL matters very much. It introduces > fairness in the contribution process - companies and individuals > can contribute code knowing that it can't be taken away and locked > up, to be modified, sold and distributed as binary packages > (eg. Nvidia). Note that this discussion (part of which occurred off-list) didn't resolve the question of whether Nvidia did or didn't do that: nobody's been able to figure out what the Nvidia package in question does.
Re: GCC association with the FSF
> I guess my point is that the direction in which a project *does* go is not > always the direction in which it *should* go. I agree. And depending on people's "political" views, that can either be an advantage or disadvantage of the free software development model. > To give just one small practical example, I'm told (by people who are more > familiar with GCC internals than I) that it is not feasible with today's > GCC to port to backends which have a small number of registers. [Finally, a technical discussion in this thread!] It never really has been. Maybe it's not even possible now (I don't know), but if you tried it in the past the results would never have been very good. Almost all multi-backend systems operate by having very large numbers of expressions at all levels, which you gradually lower to actual registers. This works quite well if you have enough registers to hold the high-usage expressions in them, but when you have high register pressure, the model breaks down completely. Although the situation may well have gotten worse in recent versions that I'm not familiar with, I'd say that GCC was probably doing a *better* job with a small number of registers in more recent versions than in older ones: "reload" was particularly bad when there was high register pressure. When your main constraint is register pressure, in order to get high-quality results, I think you almost have to change the entire philosophy of compilation, to the point I think where you have an almost entirely different compilation chain for such machines.
Re: GCC association with the FSF
> Then it would not longer be GCC. It would be something different. > The whole point of GCC is to provide a free software compiler for the > GNU system and systems based on GNU, and not to be pragmatic at the > cost of software freedom. Certainly that was its initial intent, but I'd argue that at this point, the main value of GCC to the Free Software movement is that its extensive use outside of the GNU system makes people aware of the movement and of the quality of its software. > Commercial interessts are often at odds with software freedom as > well. This is one of the many reasons why the GNU project is > entierly volunteer based. Although that's true, I strongly suspect that the majority of actual work done on GCC is commercially funded. > But I'd hope that we can avoid words like "fanaticism", "childish", > "cultish" simply because of disagreement in philosophies or continuing > to spread obvious misunderstandings of what someone wrote, it is not > constructive and only causes unnsesescary agitation. Agreed!
Re: GCC association with the FSF
> I feel like this should be even more evident when dealing with > something like a compiler toolchain. GCC's user is likely to be > another free software project's contributor (as is my case). I suspect that's not true. It certainly wasn't true when more major large companies used GCC to compile their products and I doubt it's even true now when many have switched to other compilers.
Re: GCC association with the FSF
> > When it comes to deciding the direction of a project like GCC - technical > > and otherwise - in my mind it primarily should be those actually involved > > and contributing. > > GNU follows the general principle of the Free Software movement, that > freedom for *users* is the priority. Assigning *higher* importance to > developers' preferences is *not* a position I share. I think there's a difference between philosophy and practicality here. Sure, the importance of work done by different developers, measured on the scale of advancing the goals of the Free Software movement, is different for each. But what actually advances a project (which can be viewed as "deciding [its] direction") is what work developers choose to do, not the importance of each piece of work on that metric. So I certainly agree with what you said above, but don't think that changes the reality that it's ultimately what developers choose to work on that most affects the direction of a project.
Re: GCC association with the FSF
> The principle by which high level decisions in all GNU projects have > always been made is how it best helps the GNU system as a whole. > Contributors are exactly that. They offer *contributions* - the > very meaning of the word implies there is no expectation of anything > in return. Obviously I hope all contributors *do* get some > satisfaction and maybe even some tangible benefit. But > contributions are not to be seen as a means to gain control of the > project at a high level. I agree with most of that, but all *actual* changes to a project are done by contributors. If somebody makes a "high level decision" to do a certain thing to GCC, but no contributor steps up to do that thing, it won't get done. Conversely, if some contributor decided to do some thing (e.g., add an optimization) that nobody made a "high level decision" to do, that thing *will* get done, since it's unusual to reject such contributions, assuming they're technically sound. So I think that the bulk of the "power", from a practical standpoint, is in the hands of the contributors, not some high-level group.
Re: GCC association with the FSF
> When it comes to deciding the direction of a project like GCC - technical > and otherwise - in my mind it primarily should be those actually involved > and contributing. I agree, but I'm not clear if you're claiming that that is or is not currently the case. I believe it is.
Re: GCC association with the FSF
> > > So, that's a solid 'no' on the likelihood of you contributing > > > anything of value to the discussion of GCC governance then? > > > > I really think that most of the people replying on this thread have a > > much more encompassing view of "GCC governance" than actually exists. > > If the community makes it too hard by demanding too much (which > seems to me that it is bending towards the merely bureaucratic), > people would be discouraged to serve on it. I'm sorry, what is it that you think that the "community" (whatever that is) is demanding too much of?
Re: GCC association with the FSF
> But it's quite obvious, after you removed RMS's oversight on SC's decisions. The SC is the "GNU maintainer" for GCC. The GNU project has oversight on the maintainers of every GNU project, including GCC. The change to the web page didn't affect that: RMS still has oversight on the SC's decisions to some extent, just like he does over all GNU projects.
Re: GCC association with the FSF
> So, that's a solid 'no' on the likelihood of you contributing > anything of value to the discussion of GCC governance then? I really think that most of the people replying on this thread have a much more encompassing view of "GCC governance" than actually exists.
Re: GCC association with the FSF
> Just for the record, I was not talking about developers but about > the leadership of the project, Ian. > > 8 out of 13 members of the Steering Committee are from US-corporations. I don't think I'd consider the Steering Committee "the leadership of the project". In what sense do they "lead" the project? To me, when you talk about "leading" a software project, you're talking about deciding what work gets done and when and by whom it gets done. The SC has *absolutely zero* influence on any of those things. All the "maintainers" they appoint (which is already indirect) do is approve changes, not make the changes or decide what changes to make. And their approval is supposed to be on technical or style grounds. The people who make the "leadership" decisions (what to work on and when) are the companies that employ the *developers*, not the SC or the companies the employ the members of the SC.
Re: GCC association with the FSF
> Having one guy at the top from whom all power flows. > > Power does not "flow" from RMS. Since you have used a political analogy: > I think it is more akin to a constitutional monarchy. I think it's like the Queen of England. As a British person I used to know said: "The Queen of England has the power to veto anything passed by the Parliament in any Commonwealth country until she actually does it; at that point she'll lose that power". I see it as the same here: if RMS tried to exert an inappropriate level of control over some GNU project, it would soon be made clear that that something he can't do.
Re: RMS removed from the GCC Steering Committee
> Yet enough to slow down certain developments such as Nathan's libcody > or the plugin framework. The SC had no role in that, as was discussed here. > You can also put trustworthy and credible observers to protect the > interests of the global Free Software movement. How is an "observer" going to influence which people are willing to spend their time developing software and how much time they're willing spend? As a practical matter, the direction of any Free Software project is dictated by those who actually work on it from day to day and who pays for their time, not by groups like the SC or the maintainers. > > > Except that the President of FSF (and Chief GNUissance himself) was > > > receiving copy of all the communications of the Steering Committee. > > > > Do we know this as a fact? > > Ian wrote so in his response to Nathan. > https://gcc.gnu.org/pipermail/gcc/2021-April/235269.html That says he was "involved in SC discussions", which to me, means that he *didn't* get a copy of all their communications. If somebody says they're a member of the XYZ committee and "involved Bob in our discussions", to me, that means that Bob is *not* in the committee and doesn't get all committee communications, but that they chose to involve him in some of their discussions. > The removal of Stallman revealed a huge issue in GCC. > Maybe you can't see it. Maybe you don't want to see it. > But it's evident to any seasoned programmer outside the US. I just don't see it as a "removal". RMS is still in charge of the GNU project. That means that he, at some level, is involved in every GNU project, including GCC. As a practical matter, that involvement was very slight and still is. I don't see any change whatsoever in the day-to-day operations of GCC.
Re: RMS removed from the GCC Steering Committee
> I'm scared by the dangerous influence that dangeours US corporations > and a dangerous military nation with a long history of human rights > violations (see Snowden's and Assange's revelations and the ongoing > Assange's trial) HAVE over the GCC development. I agree that that's a concern, but the point being made is that the SC is not relevant to this because they, as a practial matter, have almost no influence on GCC development. GCC development is mostly influenced by those companies that pay people to work on GCC. It is a fact that most of these are US corporations. But the only way to change that is to encourage companies that are *not* in the US to contribute too. > Except that the President of FSF (and Chief GNUissance himself) was > receiving copy of all the communications of the Steering Committee. Do we know this as a fact? I don't know whether that's the case or not, but I've read this entire thread and have seen no evidence either way on that issue. In any event, I suspect that the "all communications" may be less than a few dozen emails a year, although that's only a guess on my part. > Thus, I'm not naive enough to ignore the thousands way your employee > can get huge advantages by having you in the GCC's Steering Committee. Thousands? Given how little the SC actually *does*, I find it hard to come up with any meaningful advantages at all, let alone "huge" ones. > As a small example among many many others, you are using a @google.com > mail address while serving in the Steering Committee. So? How many emails per year do SC members send on behalf of the SC? As far as I see, it averages maybe two per year, all of which are announcements of new or changed maintainers of components of GCC. > On the contrary, it explains WHY you are debating against an urgent > fix to the GCC Steering Committee on my request, while you had no > problem to promptly remove Stallman on Nathan's request. Again, the position taken was that RMS was never *on* the SC to begin with. > You said you involved him in SC discussions. > You said you treated him as a member of the Steering Committee. You're missing the point here. The role of the SC is to act as the official maintainer of GCC. The official maintainer of a GNU project coordinates things with the GNU project (a tautology). RMS is indeed involved in those communications (which I suspect are quite rare), but as a representative of the GNU project, *not* of the GCC SC.
Re: Remove RMS from the GCC Steering Committee
> If RMS had ever done the same (pretty unlikely, Fortran isnt't his > thing), I would have done the same without thinking twice about it. I agree with that sentiment. The fact that somebody has a certain role doesn't necessarily mean that the question is asked with that hat on: it may be nothing more than curiousity.
Re: Having trouble getting my school to sign the copyright disclaimer
> They claim that university owns copyright to my code if I wrote it > for a school-related research project. That's potentially correct. And the purpose of them signing the disclaimer is to release that interest so that only you need to sign the assignment. The other way of doing it would be for them to sign the assignment and you sign the disclaimer, which would essentially acknowlege that they own the copright. But because of of you have a potential interest in the copyright, both of you need to sign something. > However, since I'm an undergraduate and thus do not have an advisor, > nobody in the campus knows me well enough to prove that it's not the case. The purpose of having both of you sign is so that there's no potential issue going forward where they might later assert that claim. That way, we don't ever need to decide who currently owns the copyright.
Re: Remove RMS from the GCC Steering Committee
> 3. Most of claims about Stallman are not true (to be more precise - > they are deliberately misrepresent what Stallman said to make his > views to look immoral). I would like to suggest that this discussion will go better without making accusations that people are "deliberately" doing something. In my opinion, there are many different ways both of interpreting what somebody writes and in making value judgements on the appropriateness of saying something in a certain way. Just because you and somebody else interpret a statement in different ways or have different moral views of the propriety of saying something in a certain way doesn't mean that either of you are "deliberately misrepresting" anything.
Re: Remove RMS from the GCC Steering Committee
> I respect that you want stay out of the discussion, but I think that to > present this as some larger societal issue which is somewhat academic > is wrong. Sorry, I didn't mean to say or imply that. What I meant to say is that the very specific discussion we're having in this forum *mirrors* the similar discussion that society is having in that the same issues that are being discussed here are also being discussed there. > And I hate to point to others, because I know these people, who > worked closely with RMS, will get harassed to "proof" their > allegations or will be told that since they were not physically > attacked it doesn't count as harassment. This is exactly what I mean by the need to draw a line. At what point does somebody's behavior rise to the level where it's necessary to take action? In other words, I think the question is less in understanding what RMS's behavior has been (I suspect most people would agree on that), but what the appropriate consequences of that behavior should be.
Re: Remove RMS from the GCC Steering Committee
> For a leadership position, which serves as an example for > the community and to some extent demonstrates the values shared by the > community, I think it is reasonable that there is a decreased > expectation of privacy. .. and libel and defamation laws in the US reflect that, for example.
Re: Remove RMS from the GCC Steering Committee
> I think I will leave this discussion up to those who have more > familiarity with the guy than I do. There's no doubt that some of the > stuff Stallman has written creeps me the hell out, and I think it was > more the tone of the OP I objected to. I mostly want to stay out of this and will leave much of this discussion to others (though I have met RMS personally on a number of occaisions), but I want to mostly say that I agree with Jeff that it's important that this discussion stay civil. I believe that to a large extent, the discussion here is reflective of a much larger discussion in society of to what extent, if at all, an entity associated with an person must or should take action based on things that that person does while not associated with that entity. I think all of us understand that, on the one extreme, there are some things so eggregious that entities must take action and on the other, we don't want companies taking actions against employees that express unpopular political positions or are members of marginalized minorities. There's the famous Supreme Court Justice who said "I can't define pornography, but I know it when I see it", but I think it's worse here: I suspect that many more of us would agree on whether a particular piece of media is pornography or not than would agree on whether a particular behavior does or doesn't cross the line in terms of the obligations of an entity associated with that person.
Re: The far past of GCC
> I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. Your memory agrees with mine.
Re: License compliance on updating gcc runtime libraries
> That depends on your local copyright law. Some, like the US, have > language saying that copies necessary for usual operation are *not* > covered under copyright. I'm refering to US law. Where, precisely, is the language you are referring to? Note that there are two separate issues: (1) Whether executing a program is considered making a copy under copyright law. (2) Whether somebody has an implicit right to make such a copy. Which of these two are you addressing? Note that there are cases where copyright law acknowleges that something is a copy, but permits making that copy. "Fair use" is probably the best known of those.
Re: License compliance on updating gcc runtime libraries
> Remember that, from the perspective of copyright law, executing a > program is making a "copy" > of that program. > > Has that (rather extreme) view been litigated? That's actually not extreme, but pretty accepted. And yes, that has been litigated. And you can see that in the GPL in the definition of "propagate": the exclusion of executing it on a computer wouldn't be necessary if that weren't considered a copy under copyright law. Much more extreme positions have been in course rulings. I'm aware of a case where a jury ruled that linking a program with a library made the library a derivative work of the program in all cases (it clearly is in some). That case was never appealed, so it (luckily) doesn't establish a precedent.
Re: License compliance on updating gcc runtime libraries
> I have questions about the GCC Runtime Library Exception. Note that nobody can give you definitive answers to questions like this since they haven't been litigated. So any answer is an "educated guess". Having said that ... > When an equipment vendor distributes an update of shared gcc runtime > libraries (e.g. libgcc_s.so, libstdc++.so) to the shipped equipment > and when the equipment has applications which are dynamically linked to > older release of the shared libraries and which are being linked to > newer ones, in this case, is the exception applied to the newer ones? > > I wonder if an update of the shared libraries are regarded as a part of > the "work of Target Code" or "independent library" in the above case. My view is that it's both, depending on the context. Remember that, from the perspective of copyright law, executing a program is making a "copy" of that program. The GPL (or the Runtime Exception) don't include those copies in their specific restrictions and limitations, but when you try to define terms, I think you need to reach the fact that these are copies. So: When the new version of the library is distributed, it's an "independent library" and (assuming it's GPL, not LGPL), the GPL rules apply to it: the vendor needs to provide the ability to get source under the usual GPL rules. But when an application dynamically links with the (new) library, that application remains a "work of Target Code" and the GPL+Exception rules apply to any situation where that work is copied.
Re: GCC missing -flto optimizations? SPEC lbm benchmark
> Hasn't GNAT sorted Ada elements in records (e.g. structures) by size > since near its initial addition to GCC in the mid-90s? No, it wasn't done early on and it was never done in that major a way now. Most reordering (possibly all; I'm not sure) is done between objects of variable and fixed size, not between objects of differing fixed sizes. > I know Ada is traditionally more strongly typed than C/C++, but tf it can > be done for Ada programs reliably, why could it not be reliable in C? I don't see it as a reliability issue, but one of expectations. One might be using a struct to map some hardware layout or records in a file so that reordering fields could break things.
Re: gcc license violation?
> binaries was provided for my company with toolchain for cortus mcu > development. They are proprietary and compiled for windows. I can't send > those for you, because I signed NDA > this is (1) violation. Although the GPL doesn't specifically allow it, there are cases where GPL'ed software can be covered by an NDA. This occurs when it's one of a number of items under NDA, the intent of the NDA is not to protect the software itself but information about something else (e.g., microprocessor architecture) that could be derived from the GPL'ed software, and where this information is expected to be made public (thus releasing you from the NDA) in a reasonable amount of time (months, not years). This has been relatively common practice to facilitate the porting of GCC and related tools to new microprocessors and although it's a technical violation of the GPL, nobody is likely to enforce it if all three of those things above are the case. > No sources was provided in package, this is (2) violation. I will ask for > sources, and if they will refuse to send sources, That *is* a violation, even if you're receiving it under NDA.
Re: gcc license violation?
> But I can't find nir Cortus architecture on gcc official support page, > nor sources on Cortus site. > > Manufacturer is producing billions MCU worldwide and toolchain is > closed-sources, but based on gcc. How is this possible? Can you show us where the binary download is located? What makes you say that it's closed-source? The GPL does not (and could not) require that somebody distribute their software to anybody or everybody. A company is permitted to only distribute GPL'ed software to those they choose or to nobody at all. The GPL is only relevant when a company *does* choose to distribute their software to an entity. What that happens, it imposes (to oversimplify) two requirements: (1) They may not prevent that entity from further distributing the software (2) They must make the source code available Do you have any evidence that Cortus is violating either of those provisions?
Re: ChangeLog's: do we have to?
> But this is against GNU policy for ChangeLog entries. Explanations of > the change should go into the source code, as comments. No, explanation of the *code* should go into the source code, as comments. The source code is not the place for a history of the form: "In 1999, this code did XYZ, but in August of that year, we changed it to do ABC. And then in 2001, we decided to do DEF. But, as part of a major change in 2005, it now does PQR and then in 2014, we changed the names of the macros called". That doesn't belong in code, at least not in my opinion. That's what ChangeLogs are for. The code should say what it does and perhaps why. If there's some non-obvious reason why it can't do it some other way, it may be useful to note that we used to do it some way and that we no longer do because of some subtle reason, but that's very different from the sort of chronology above.
Re: ChangeLog's: do we have to?
> GCC ChangeLogs don't record the purpose of the change. They say what changed, > but not why. That depends on how you define "purpose". Let's take a random entry, from a 1999 change of mine: * expr.c (expand_expr): If ignoring reference operations, just expand the operands. (expand_expr, case COMPONENT_REF): Refine test for when need to use bitfield operations or pointer punning. This indeed doesn't say why the change was made (though later policy did tend to at least suggest adding PR numbers), but does say, in some detail, what was changed. You can't get that informtion from the current state of the code. You could indeed derive it from the diff itself, but that's work and having a short summary is very helpful. In other words, there are three levels here: (1) What the code currently does (2) How we changed the code from what it did to what it does (3) Why we made the change #1 is always in the code and #2 is always in the ChangeLog. #3 *should* be in the ChangeLog, but isn't always. However #2 is very useful information. This is especially valuable because it gives the intent of the change in the case where an error was made (say, some part of the change was missed). It's much harder to figure out intent from even the diff and certainly impossible from the code itself.
Re: ChangeLog's: do we have to?
> After 20 years of hacking on GCC I feel like I have literally wasted > days of my life typing out ChangeLog entries that could have easily been > generated programmatically. > > Can someone refresh my memory here, what are the remaining arguments for > requiring ChangeLog entries? I take the position that any ChangeLog entry that could have been generated automatically is not a good one. Yes, the list of functions changed could be generated automatically. (Isn't there actually a way to do that in emacs? I could have sworn I saw it, though I never used it much.) But the *purpose* of the change to that function can't be generated automatically because the ChangeLog entry is the only place that should have that information. The comments should say what a function currently does, but isn't the place for a history lesson. That data belongs only in ChangeLog In other words, I believe that these three things: - code - comments - ChangeLog entry should all contain unique information (to be clear, not *all* of it is unique, but *some* should be) that can't be derived from the other item. Therefore each serves a critical purpose.
Re: GCC contribution
> > GCC steering community I count on you and speaking behalf other > > developers to keep GCC as close to C as possible for at least the next > > 1000 years. > > We've already made a decision to use C++ when it makes sense. That ship > sailed years ago. I don't see "keeping GCC as close to C as possible" and "using C++ when it makes sense" as contradictory. In fact, they sound pretty close to the same thing to me.
Re: How far should we trust ChangeLog attribution dates?
> My secret desire is that once we get this done we would drop these > silly ChangeLogs. Although I'm not a kernel developer, I kind of like > the Linux kernel style, where the commit msg contains a reasonably > in-depth motivation for the change, sort of like the email message one > sends to gcc-patches when introducing a patch (in fact, if one uses > git format-patch + git send-email this kind of workflow is supported > out-of-the-box). I find that a lot more useful than a screenful of > "Likewise". YMMV. The point of the "likewise" is to show which functions changed. I think that's at least as important as the detailed motivation for the change.
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] [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
> 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
> 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
> 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
> 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
> 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: 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: 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: [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 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 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: Adoption of C subset standards
> It looks like MISRA should adjust its rules if it wants to support > open source. I can think of no reason why MISRA would want to do that given their goals. Can you?
Re: Adoption of C subset standards
> I suppose that would be true if you refer to MISRA in the messages. > If you don't then you're not using the trademark. The issue isn't the messages. but how you describe what you've done in, say, documentation or ChangeLog entries. If you claim, in any way, that you're checking for "MISRA compatibility", you violate the trademark. > But still, I'm back to my previous comment. People who try to > extract license fees for stuff like this should just be rejected. > It's bad enough we have ISO doing this; we should not put up with > random others trying to do the same. The politics of IP are off-topic here, but I believe that it's not just a license fee, but that there's also some (mild, but nonzero) verification that you are actually doing checking against those rules.
Re: Adoption of C subset standards
> But as for a license, it's hard to see why that might be. You can't > copyright rules (only a particular expression of same, and only to > the extend that the "sweat of the brow" rule doesn't apply). And it > doesn't sound like patentable matter either. That said, if some > outfit thinks it can ask for licensing on matter of this kind, that > in itself is in my mind sufficient to exclude them from any > consideration. The issue is trademark. When you can use the term "MISRA" to describe something. It's my understanding that you can't use the term to describe something that checks rules without paying the license fee for the trademark, but this is a complex issue and needs to be doublechecked.
Re: Adoption of C subset standards
> Regardless of that sort of issue, I think on previous occasions when the > topic of MISRA (or other coding standard) checking came up, there has > been a general opinion from the gcc developers that the compiler itself > is not the best place for this sort of checking - they recommend an > external tool, and don't want the main code base cluttered with such > specific warnings for the dozens of coding standards in common use. Note that there's also a legal issue here: when one has to obtain a license from MISRA.
Re: History of GCC
> I don't think that employer interests have led to any significant > conflicts between employer interests and project interests. It's sort > of hard to say, though, because in effect employer interests have > become project interests. And indeed many people who've been working on GCC for a long time (including you and me) have moved from one organization to another during that time (sometimes more than once). > That said, from a certain perspective it would be reasonable to call > the EGCS split a conflict between employer interests and project > interests. Although many people supported the EGCS split, it was > driven initially by Cygnus. But that could also have been viewed as a conflict between FSF interests and GCC project interests. As you say, it's hard to point to a specific conflict because, for the most part, all the interests aligned: everybody wanted the best compiler we could product.
Re: History of GCC
> The Ada frontend was developed at AdaCore. The Ada frontend was developed at NYU, as an Air Force-funded project to show that Ada95 (then called Ada9X) was implementable. AdaCore was later formed once that was complete to provide commercial support for the Ada compiler. The members of that NYU project were the initial team at AdaCore.
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: [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: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> And hell, GCC already includes a lot of really really obscure > builtin functions which are one hell of a lot less common & useful > than multiply-hi Which exactly proves the point that people are making: whether something is "common & useful" is rarely the criteria that's used in deciding whether a language should include that thing. > And that isn't because I failed to "learn basic principles about > language design." Sorry, but it precisely is.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> It *isn't* "putting every possible feature into every language." > Did I ever advocate that? Yes. When you say "X is a useful feature, therefore we should put it into language Y", you are indeed implicitly advocating that. Because if that were *not* the case, then saying that X is *useful* says nothing whatever about whether it should be put into Y: there will be dozens, if not hundreds, of useful feature that will not be in Y. > Am I making syntax more complicated? No. I am if anything > suggesting making it simpler by removing arbitrary rules that only > complicated situation. Am I making compiler more complicated? No, > the code to do this was already written (just with different numbers), > and by doing what I say the compiler could actually be simplified > in some ways. You are making the *language* more complicated because you cannot look at each feature in isolation, but rather must look at how they interact with the other features of the language, among other issues. As I said, please study language design concepts before continuing this discussion.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> OK, you just said you've used packed nybble arrays a couple of times. > Multiplying you by 100,000 that proves if you put it in GCC, > you'd save 200,000 programmer hours, which is equivalent to saving > over 2 lives. I would suggest that you spend time learning basic principles about language design and better understand the concept that not all languages are meant to be used in the same way and for the same purpose before you make any more postings in this thread. Then you'll understand that the above statement is completely meaningless. You very specifically *do not* want to put every possible feature into every language.
Re: internal_reference_types
> Yes, the address space stuff is posterior, but the Pmode thing is verbatim. Doesn't ring a bell. Sorry. I don't even remember what the other option would be other than Pmode. > REFERENCE_TYPEs and POINTER_TYPEs are (should be) treated almost equally in > the compiler, the difference matters only for the debug info. We use the > former much more now than we used to in gigi, because of the debug info. Right. The transition to using REFERENCE_TYPEs more started back in my time.
Re: internal_reference_types
> The commit from 2001 has your name on it. It's called from gigi: > > /* Show that REFERENCE_TYPEs are internal and should be Pmode. */ > internal_reference_types (); Hmm... what else would REFERENCE_TYPEs be? I remember none of this and it's clear that it was later changed because of the reference to address spaces.
Re: internal_reference_types
> Only Richard K. might remember the details. Possibly for > IA-64/HP-UX -milp32. In any case, having a different representation > for pointers and references is a recipe for annoying issues like > this, so removing the kludge is OK with me. I don't think I added that. In fact, I'm not sure what the term "address spaces' address_mode" means: I think that was added after I stopped working on GCC. So I don't know either. Is it ever called?
Re: 33 unknowns left
As such, you'll need the passwd file from there. I don't think we had any such thing as a maintainers file in those days. Correct.
Re: 33 unknowns left
wood = wood wood Likely Tom Wood (w...@dg-rtp.dg.com)
Re: set_src_cost lying comment
These are good examples of things the costing model simply wasn't ever designed to consider -- because they weren't significant issues on the m68k, vax and other ports in the gcc-1 era. So I don't really know how to tell you to proceed -- I've considered the costing models fundamentally flawed for many years, but haven't ever tried to come up with something that works better. I'm not sure I'd call it fundamentally flawed or that it wasn't designed to consider these things. I see the costing model as meant as a *heuristic* for making choices, not as a precise metric for anything. Certainly, a lot of people worked on that model, including both of us, during the gcc-2 RISC porting days. I see the flaw as trying to use it for too much. There's a limit to the amount of decisions you can make with purely local data. When trying to decide whether a source should be a constant or a register, you have to look at: - the chances the reg-reg copy can be eliminated - register pressure - whether there's room to insn schedule around any conflicts Unless you look at the whole picture, you're just guessing, which is, of course, what a heuristic is all about!
Re: Compilers and RCU readers: Once more unto the breach!
(Assuming it's a goal of this standard to be human parseable to more than a few dozen people on the planet.) Unfortunately, that's rarely a goal of most standards. ;-)
Re: WPP capabilities in gcc
Is gcc meant to only be used to compile FOSS? If that's your agenda, you're right - I don't see how you can use a feature like WPP. But is that really what gcc aims for? Not to allow people working on close-source software to enjoy it? It's one thing to say that we're building a compiler or adding a feature to a compiler that will benefit both the open- and closed-source communities. Everybody understands and supports that goal. However, adding something to gcc that *only* is of value to the closed-source community is something entirely different and a lot of us (including me) are uncomfortable with that.
Re: WPP capabilities in gcc
What WPP does, is it runs during pre-compilation, and replaces the string in each call to a trace macro, with an obfuscated string. And why would a writer of Free Software want to do such a thing?
Re: Tags out of gcc
I reckon it's a bad idea to make source browsing info with a separate program like cscope or etags. I reckon it's the compiler's job. One of the issues with soure browsing is that you want to be able to do it in the presence of syntax errors. That can make it harder for the compiler to do it since it's usually not doing a robust parse in the presense of errors.
Re: Tags out of gcc
Well it seems to be able to report a lot of syntax errors even if
they're close together, so it must be getting back on its feet fairly
quickly. I don't know how that works. Maybe it just scoots along to
the next semicolon or maybe you explicitly have productions like if
(syntax error) { ... }.
What I also don't know is what the parser outputs if there's an error.
Can it say he tried to define bool foo() at line 123 but the body was
erroneous, or does it just stdout the error message and forget there
was ever an attempt to define foo?
You're missing my point by getting too deep into details. I'm making a
more general point, which is that a parser of a compiler and a source
browser have two different purposes.
The purpose of the former is primarily to produce a parse tree of a correct
program and secondarily to produce as many error messages as possible for
an incorrect program. The purpose of the latter is to try to figure out as
much as it can about the semantic meaning of what may be program fragments
and be completely uncaring about the presence or absence of errors.
Although there is indeed significant commonality between these two
purposes, there are very significant difference as well. For example, a
compiler usually won't look at things such as indentation and whitespace at
all (except maybe when deciding what message to give for errors, but I
think only the Ada front end does this), but high-quality source file
browser would rely more on indentation than the exact parse because the
indentation of a program in the process of being written will usually be
more likely to be able to identify semantic constructs than a parse based
on the tokens in the file.
Re: combine_simplify_rtx (doesn't) commute XOR and ASHIFTRT ???
and wondering if anyone can explain to me what's wrong with this transformation. Having worked through all four cases of A and C1 positive and negative, it seems to me that the extra bits 'fed in' to the most-significant end of the result are the same either way (i.e. the XOR of the sign bits of A and C1). I haven't heard from Kenner in a while, but you could always try to contact him directly and see if he can recall the issue. It was a long time ago though... I haven't gone anywhere ... But indeed ten years is a long time and I don't have any recollection of this at all. The above analysis seems right, but this isn't the sort of thing I'd have done if there weren't some sort of bug. Perhaps it's only relevant if result_mode != shift_mode?
Re: Should we be updating copyright years on branches?
If a release is made, then the copyright dates ought to be updated in files that have changed, at least that's always been my understanding. Yes, but that update should have been done *when the file was changed*. Or am I missing something here? Because anybody can take any of the files at any time, they always have to have an up-to-date copyright notice, reflecting when changes were made.
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: Don't shoot the messenger
To the extent that clang/LLVM and GCC are fighting, which is not really the case, then I think it makes sense for GCC to focus on its strengths, not its weaknesses. Objective C is not a strength. I'm not sure it makes sense for the GCC project to encourage its limited volunteer resources to work on it. I agree. Competition is a good thing. But it's best when it's not head to head. Instead each should have what it's best at.
Re: clang and FSF's strategy
The *political* aspects are dictating the *technical* aspects. Perhaps. So... like it or not, that makes this list exactly the right place to have this discussion. No because the *people* that decide the political and technical aspects are different and this list is for the latter, not the former.
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: Update the c++1y/c++14 support page
This has nothing to do with Oracle v. Google, but with GCC policy of not requiring a copyright assignment for small patches from the first-time contributors (which Paolo knows as a long-time GCC hacker). I think it's a valid reminder that that policy needs to be interpreted carefully and that there may well be some small patches that *do* need an assignment.
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: 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: Question on building a variably modified type at parameter scope
I believe this should be possible. I believe that Ada has constructs like this. I think you will need to use a PLACEHOLDER_EXPR to get the right thing to happen. Yes, that's correct.
