Re: Moving to git
> On Aug 20, 2015, at 4:09 PM, Jason Merrill wrote: > > On 08/20/2015 02:23 PM, Jeff Law wrote: >> ...As far as the trunk and release branches, are there any best practices >> out there that we can draw from? Obviously doing things like >> push-rebase-push is bad. Presumably there's others. > > Absolutely, a non-fast-forward push is anathema for anything other people > might be working on. The git repository already prohibits this; people that > want to push-rebase-push their own branches need to delete the branch before > pushing again. > > There are many opinions about best practices, but I don't think any of them > are enough better than what we already do to justify a change. Let's make sure the procedures that people are supposed to follow are clearly documented. I recently went looking for the equivalent in the binutils/gdb project and it doesn't seem to be written down there, though if you ask enough questions on the mailing list you do get some answers. paul
Re: Moving to git
> On Aug 20, 2015, at 4:24 PM, Jason Merrill wrote: > > On 08/20/2015 04:22 PM, paul_kon...@dell.com wrote: >> Let's make sure the procedures that people are supposed to follow are >> clearly documented. I recently went looking for the equivalent in the >> binutils/gdb project and it doesn't seem to be written down there, though if >> you ask enough questions on the mailing list you do get some answers. > > Do you have pointers to relevant email threads? It was in a private email exchange. Here's what I wrote and the reply I received: >> I used to know the GDB workflow back in the CVS days, but GIT is of course >> very different. I’m not particularly fluent with GIT. Some of the projects >> in our company that I’m starting to get involved with use it. I’ve seen >> their procedures documents and they mention that GIT supports an amazing >> variety of work flows with very different visible outcomes. For example, it >> seems to make a lot of difference whether you allow branching that’s natural >> to GIT development to remain visible in the history, or rebase (I think >> that’s the right term) everything before it’s pushed to create the >> appearance of a single stream of history. >> >> I gather GDB is one of those single linear history projects, but I haven’t >> yet found any documents that describe the GDB development procedures as far >> as GIT is concerned. Can you point to some? > > Yeah, gdb's git workflow is similar to the CVS days. We rebase patches on > top of master > to maintain a linear history. That is, only fast-forward merges are accepted. > Don't worry, if you get this wrong and try to push a non-linear merge, the > server > will reject it with an error. At which point you just pull/fetch upstream > again, > rebase your patch, and push again. > > I'm afraid I'm not aware of any GDB-specific docs for that. Though, glibc > follows a similar model and they do have a guide. See: > > https://sourceware.org/glibc/wiki/Committer%20checklist > > The git-specifics are the same for gdb. paul
Re: Compiler support for erasure of sensitive data
> On Sep 9, 2015, at 12:36 PM, Zack Weinberg wrote:
>
> ...
> I think the ideal feature addition to address this would be
>
>void safe(void)
>{
>struct key __attribute__((sensitive)) k = get_key();
>use_key(k);
>}
That certainly is a cleaner answer. What is attractive about it is that it
expresses the need for variables (data) to be given different treatment, rather
than expecting the programmer to code that special treatment in every place
where that data becomes dead. It's also likely to be a whole lot harder to
implement, unfortunately.
Then again, suppose all you had is explicit_bzero, and an annotation on the
data saying it's sensitive. Can static code analyzers take care of the rest?
If so, this sort of thing doesn't need to be in the compiler.
paul
Re: Compiler support for erasure of sensitive data
> On Sep 9, 2015, at 1:54 PM, David Edelsohn wrote: > > On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote: > >> The ABI dictates basically everything you see. The call to >> explicit_bzero has forced the compiler to *create* a second copy of >> the variable `k` on the stack, just so it can be erased -- and the >> copy in registers survives (at least for a short time), which is not >> what the programmer wanted. With or without explicit_bzero, we have >> no way of getting rid of the copy in registers. More complicated >> scenarios of course exist. > >> Comments? Please note that I do not have anything like the time >> required to implement any of this myself (and I'm ten years out of >> practice on GCC and have no experience whatsoever with Clang, >> anyway). I'm hoping this catches someone's interest. > > What level of erasure of sensitive data are you trying to ensure? > Assuming that overwriting values in the ISA registers actually > completely clears and destroys the values is delusionally naive. Could you point to some references about that? > Most modern hardware architectures have hardware capabilities to > encrypt and protect sensitive data. I'm not sure about "most". I haven't worked on any that could do this. I agree it would be good to specify the threat model. Reading between the lines, I believe it is: capture of the software-visible process state after the code is finished with the sensitive data, either via a process dump file, or a debugger. With an explicitly stated list of goals and non-goals we can see whether a proposed solution addresses all, part, or none of the problem space, and whether it is a small solution or one much more powerful than is actually requested. If the threat is indeed delayed process state examination in software, then I think your "dangerously naive" does not apply. If you're talking excavating the chip and doing quantum forensics, that's a different matter. Another threat that I don't believe is covered here is disclosure of copies of the process state held in the OS, like saved context from thread switching, copies of stuff in the page file or in now-freed memory pages, or things like that. paul
Re: Git conversion: disposition of old branches and tags
> On Sep 16, 2015, at 4:38 AM, Richard Biener > wrote: > > On Tue, Sep 15, 2015 at 7:09 PM, Florian Weimer wrote: >> ... >> Unlike Subversion branch deletion, Git branch deletion is permanent, >> so this might not be the best option. > > We could have a 2nd git repository just containing deleted branches... Agreed. A correctly designed source control system doesn't lose stuff, and the fact that GIT fails that test in the case of branches is rather disturbing. If the conversion would follow the GIT pattern, then the data it is going to delete should be preserved elsewhere. (I suppose another answer might be to keep the existing SVN server available read-only.) paul
Re: basic asm and memory clobbers
> On Nov 20, 2015, at 1:24 PM, Jeff Law wrote: > > On 11/20/2015 06:05 AM, Richard Henderson wrote: > >> ... >> It seems to me that it would be better to remove the feature, forcing >> what must be an extremely small number of users to audit and update to >> extended asm. > That might be a little drastic. Though if we want to go this direction, the > first step is to deprecate for a major release cycle. It would be > interesting to see how much stuff would complain/break. I would expect: a lot. I've seen plenty of people writing asm statements (in small quantities, admittedly) who have never heard of extended asm. paul
Re: basic asm and memory clobbers
> On Nov 20, 2015, at 3:01 PM, Jeff Law wrote: > > On 11/20/2015 07:56 AM, Segher Boessenkool wrote: > > When basic asm changes, I expect that having a way to "just do what it > used to do" is going to be useful for some people. 24414 says the documented behaviour hasn't been true for at least fourteen years. It isn't likely anyone is relying on that behaviour. >>> >>> ? >> >> 24414 says these things haven't worked since at least 2.95.3, which is >> fourteen years old now. > That's not a good reason to leave things as-is. > > The problem is that optimizers continue to improve. So an old-style asm > that worked in the past may mysteriously start failing as folks move forward > with their compiler -- because we haven't properly implemented the right > semantics of old-style asms, which is in part because certain aspects were > never documented properly and partly because of reload issues :( > > If we keep old style asms, then we need to properly document what their > behaviour is supposed to be, and continue to fix bugs where we do not honor > that behaviour. Yes. I know I've run into cases before where certain documented properties were not honored. I can't find the details right now; I think it was "old style asm always behaves as if marked 'volatile'. " paul
Re: basic asm and memory clobbers
> On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote:
>
> ...
>> The more I think about it, I'm just not keen on forcing all those old-style
>> asms to change.
>
> If you mean you aren't keen to change them to "clobber all," I'm with you.
> If you are worried about changing them from basic to extended, what kinds of
> problems do you foresee? I've been reading a lot of basic asm lately, and it
> seems to me that most of it would be fine with a simple colon. Certainly no
> worse than the current behavior.
I'm not sure. I have some asm("sync") which I think assume that this means
asm("sync"::"memory")
paul
Re: basic asm and memory clobbers
> On Nov 23, 2015, at 8:39 PM, David Wohlferd wrote:
>
> On 11/23/2015 1:44 PM, paul_kon...@dell.com wrote:
>>> On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote:
>>>
>>> ...
The more I think about it, I'm just not keen on forcing all those
old-style asms to change.
>>> If you mean you aren't keen to change them to "clobber all," I'm with you.
>>> If you are worried about changing them from basic to extended, what kinds
>>> of problems do you foresee? I've been reading a lot of basic asm lately,
>>> and it seems to me that most of it would be fine with a simple colon.
>>> Certainly no worse than the current behavior.
>> I'm not sure. I have some asm("sync") which I think assume that this means
>> asm("sync"::"memory")
>
> Another excellent reason to nudge people towards using extended asm. If you
> saw asm("sync":::"memory"), you would *know* what it did, without having to
> read the docs (which don't say anyway).
>
> I'm pretty confident that asm("") doesn't clobber memory on i386, but maybe
> that behavior is platform-specific. Since i386 doesn't have "sync", I assume
> you are on something else?
Yes, MIPS.
>
> If you have a chance to experiment, I'd love confirmation from other
> platforms that asm("blah") is the same as asm("blah":). Feel free to email
> me off list to discuss.
I'm really concerned with loosening the meaning of basic asm. I wish I could
find the documentation that says, or implies, that it is a memory clobber.
And/or that it is implicitly volatile.
The problem is that it's clear from existing code that this assumption was
made, and that defining it otherwise would break such code. For example, the
code I quoted clearly won't work if stores are moved across the asm("sync").
Given the ever improving optimizers, these things are time bombs -- code that
worked for years might suddenly break when the compiler is upgraded.
If such breakage is to be done, it must at least come with a warning (which
must default to ON). But I'd prefer to see the more conservative approach
(more clobbers) taken.
paul
Re: basic asm and memory clobbers
> On Nov 24, 2015, at 12:49 PM, Ian Lance Taylor wrote: > > On Tue, Nov 24, 2015 at 8:58 AM, wrote: >> >> I'm really concerned with loosening the meaning of basic asm. I >> wish I could find the documentation that says, or implies, that it >> is a memory clobber. And/or that it is implicitly volatile. > > The volatile one is right there in the current docs. > > https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm > > "All basic asm blocks are implicitly volatile." Ok, that's what I remembered. I reported finding that this was not implemented correctly, some number of versions ago. paul
Re: C++ order of evaluation of operands, arguments
> On Nov 25, 2015, at 1:25 PM, Martin Sebor wrote: > > On 11/24/2015 02:55 AM, Andrew Haley wrote: >> On 23/11/15 23:01, Jason Merrill wrote: >>> There's a proposal working through the C++ committee to define the order >>> of evaluation of subexpressions that previously had unspecified ordering: >>> >>> http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf >>> >>> I agree with much of this, but was concerned about the proposal to >>> define order of evaluation of function arguments as left-to-right, since >>> GCC does right-to-left on PUSH_ARGS_REVERSED targets, including x86_64. >>> >>> Any thoughts? >> >> Not about PUSH_ARGS_REVERSED targets, but my two-penn'orth: >> >> The proposal seems to be a bit of a minefield. This one: >> >> a(b, c, d) >> >> is a bit counter-intuitive. I wouldn't expect a to be evaluated before >> the arg list. I wonder how many C++ programmers would. > > The motivating example in the paper suggests that many C++ > programmers expect a left to right order of evaluation here > due to the commonality of constructs like chains of calls. > > Incidentally, both GCC and Clang evaluate the first operand > of the function call expression first in C as well in C++ > (the program below prints a b c d when compiled with GCC, > and a d c b with Clang). > > Interestingly, though, not all compilers take that approach. > IBM XLC, for example, evaluates it last (and the program below > prints b c d a). I thought the order depends on target architecture, because of the argument passing rules. I distinctly remember seeing right to left on x86 (because they are pushed on the stack, leftmost argument on top) and left to right on MIPS (because they go into registers, at least the first 4 or 8 arguments). I'm really wondering about this proposal. It seems that it could affect optimization. It also seems to be a precedent that may not be a good one to set. Consider the dozen or so "undefined behavior" examples in https://pdos.csail.mit.edu/papers/ub:apsys12.pdf -- would the committee want to remove ALL of those? If yes, what will that do to performance? If no, what are the criteria by which to decide yes or no for each individual example? And I assume there are probably more "things the beginning programmer wouldn't expect" issues in C and C++. paul
Re: basic asm and memory clobbers - Proposed solution
> On Nov 28, 2015, at 2:02 AM, Bernd Edlinger wrote:
>
> ...
> Well, I start to think that Jeff is right, and we should treat a asm ("") as
> if it
> were asm volatile ("" ::: ) but if the asm ("nonempty with optional %") we
> should
> treat it as asm volatile ("nonempty with optional %%" ::: "memory").
I agree. Even if that goes beyond the letter of what the manual has promised
before, it is the cautious answer, and it matches expectations of a lot of
existing code.
paul
Re: basic asm and memory clobbers - Proposed solution
> On Nov 29, 2015, at 6:53 PM, David Wohlferd wrote:
>
>
>
> On 11/28/2015 10:30 AM, paul_kon...@dell.com wrote:
>>> On Nov 28, 2015, at 2:02 AM, Bernd Edlinger
>>> wrote:
>>>
>>> ...
>>> Well, I start to think that Jeff is right, and we should treat a asm ("")
>>> as if it
>>> were asm volatile ("" ::: ) but if the asm ("nonempty with optional %") we
>>> should
>>> treat it as asm volatile ("nonempty with optional %%" ::: "memory").
>> I agree. Even if that goes beyond the letter of what the manual has
>> promised before, it is the cautious answer, and it matches expectations of a
>> lot of existing code.
>
> Trying to guess what people might have been expecting is a losing game.
> There is a way for people to be clear about what they want to clobber, and
> that's to use extended asm. The way to clear up the ambiguity is to start
> deprecating basic asm, not to add to the confusion by changing its behavior
> after all these years.
>
> And the first step to do that is to provide a means of finding them. That's
> what the patch at https://gcc.gnu.org/ml/gcc/2015-11/msg00198.html does.
>
> Once they are located, people can decide for themselves what to do. If they
> favor the 'cautious' approach, they can change their asms to use :::"memory"
> (or start clobbering registers too, to be *really* safe). For people who
> require maximum backward compatibility and/or minimum impact, they can use
> :::.
>
> Have you tried that patch? How many warnings does it kick out for your
> projects?
The trouble with warnings is that they only help with projects that are
currently maintained.
paul
Re: basic asm and memory clobbers - Proposed solution
> On Dec 3, 2015, at 12:29 AM, Bernd Edlinger wrote:
>
>> ...
>> If the goal is to order things wrt x, why wouldn't you just reference x?
>>
>> x = 1;
>> asm volatile("nop":"+m"(x));
>> x = 0;
>>
>
> Exactly, that is what I mean. Either the asm can use memory clobber
> or it can use output and/or input clobbers or any combination of that.
>
> The problem with basic asm is not that it is basic, but that it does not
> have any outputs nor any inputs and it has no way to specify what it
> might clobber.
>
> Therefore I think the condition for the warning should not be that the
> asm is "basic", but that has zero outputs, zero inputs and zero clobbers.
> That would make more sense to me.
I don't think so.
Basic asm has a somewhat documented specification, in particular it is defined
to be volatile. Some revs of GCC got this wrong, but such cases are obviously
bugs. It does omit any statement about clobbers, true. And the difficulty is
that people have made assumptions, not necessarily supported by documentation.
And those assumptions may have been invalid on some platforms in some revs by
new optimizations. The prevalence of confusion about basic asm is the reason
why warning about it is potentially useful.
On the other hand, asm volatile ("foo":::) has a different meaning. That
specifically says that "foo" doesn't clobber anything (and, implicitly, that it
does not rely on any program variable being up to date in memory). While that
isn't all that common, it is certainly possible. For example, if I want to
turn on an LED on the device front panel, I might use such a statement (on
machines where the instruction set allows me to do this without using
registers). Since I explicitly stated "this doesn't clobber anything" I would
not expect or want a warning.
paul
Re: basic asm and memory clobbers - Proposed solution
> On Dec 12, 2015, at 4:51 AM, Andrew Haley wrote: > > ... > You've missed the most practical solution, which meets most common > usage: clobber memory, but not registers. That allows most of the > effects that people intuitively want and expect, but avoids the > breakage of register clobbers. It allows basic asm to be used in a > sensible way by pushing and popping all used registers. Yes, that is the solution I would like to see. paul
Re: basic asm and memory clobbers - Proposed solution
> On Dec 15, 2015, at 7:52 AM, Bernd Schmidt wrote:
>
> On 12/14/2015 09:10 AM, Segher Boessenkool wrote:
>> That, and adding a memory clobber degrades performance for a lot of
>> existing basic asm that does not expect the clobber, e.g. asm(""),
>> asm("#"), asm("nop"), ...
>
> I wonder about this. People keep bringing up "a lot of existing basic asm" in
> general, but are there any known examples in real software?
In the codebase for the product I work on, I see about 200 of them. Many of
those are the likes of asm("sync") for MIPS, which definitely wants to be
treated as if it were asm ("sync" : : : "memory").
That's not counting the hundreds I see in gdb/stubs -- those are "outside a
function" flavor.
paul
Re: basic asm and memory clobbers - Proposed solution
> On Dec 15, 2015, at 5:22 PM, David Wohlferd wrote: > > On 12/14/2015 1:53 AM, Andrew Haley wrote: >> > This just seems like another argument for deprecating basic asm and >> > pushing people to extended. >> Yes. I am not arguing against deprecation. We should do that. > > You know, there are several people who seem to generally support this > direction. Not enough to call it a consensus, but perhaps the beginning of > one: > > - Andrew Haley > - David Wohlferd > - Richard Henderson > - Segher Boessenkool > - Bernd Schmidt > > Anyone else want to add their name here? No, but I want to speak in opposition. "Deprecate" means two things: warn now, remove later. For reasons stated by others, I object to "remove later". So "warn now, remove never" I would support, but not "deprecate". paul
Re: __builtin_memcpy and alignment assumptions
> On Jan 8, 2016, at 6:32 AM, Jakub Jelinek wrote: > > On Fri, Jan 08, 2016 at 12:24:49PM +0100, Eric Botcazou wrote: >>> See some existing PR. The GCC middle-end cannot assume that pointers >>> are aligned according to their type (while at least the C language would >>> support that notion). >> >> Only on x86. It could (and used to) do it on strict-alignment architectures. > > I think we only assume it if the pointer is actually dereferenced, otherwise > it just breaks too much code in the wild. And while memcpy dereferences, it > dereferences it through a char * cast, and thus only the minimum alignment > is assumed. Is the char* cast actually part of the definition of memcpy? The fact that memcpy doesn't make use of the known alignment is a rather unfortunate issue (I'd call it a defect); it results in clearly inferior code on strict-alignment machines when the alignment is in fact clearly known. If it really is necessary to say that memcpy is defined to behave as if it had a cast to char* in its implementation, it would still be useful -- and obviously valid -- to rely on the greater alignment when there is other code in the block that uses it. And it would be helpful to have a way in the source program to say "I want you to rely on the type alignment". paul
Re: Is test case with 700k lines of code a valid test case?
> On Mar 14, 2016, at 11:31 AM, Andrey Tarasevich > wrote: > > Hi, > > I have a source file with 700k lines of code 99% of which are printf() > statements. Compiling this test case crashes GCC 5.3.0 with segmentation > fault. > Can such test case be considered valid or source files of size 35 MB are too > much for a C compiler and it should crash? It crashes on Ubuntu 14.04 64bit > with 16GB of RAM. I have a rather simple view of this sort of thing. If I feed input to a program and the program crashes, that's always a bug. This is true even if the input was "invalid" in some way. That said, 700k lines in a single source file is a bit extravagant, but I see no way that such a thing could be legitimately called "invalid". If it's all one function (or worse yet, one basic block), I would not be at all surprised if it exceeds a resource limit on how big a function can be, but if so, the expected output would be an error message, not a crash. paul
Re: Is test case with 700k lines of code a valid test case?
> On Mar 14, 2016, at 12:05 PM, C Bergström wrote: > > I don't speak with any community authority - I think your test tool is > misconfigured then. I don't see any pragmatic reason to generate such > a test. It's unlikely to mirror any real world code and artificial > test cases like this, at best only serve as some arbitrary data point. I don't agree. Generated code often produces very large files. Also, proper handling of resource issues is important, because where those issues hit depends on the environment, and for some users might be in perfectly plausible code. An error message that says "I can't handle this" is fine. But a crash gives the user no information what is wrong, no suggestions on how to avoid the problem. paul
Re: Is test case with 700k lines of code a valid test case?
> On Mar 18, 2016, at 12:53 PM, Paulo Matos wrote: > > > > On 18/03/16 15:02, Jonathan Wakely wrote: >> >> It's probably crashing because it's too large, so if you reduce it >> then it won't crash. >> > > Would be curious to see what's the limit though, or if it depends on the > machine he's running GCC on. It presumably depends on the machine, or rather the resource limits currently in effect (ulimit etc.) But the expected outcome when a resource limit is exceeded is a clean error message saying so, not a crash. paul
Re: Spurious register spill with volatile function argument
> On Mar 28, 2016, at 8:11 AM, Florian Weimer wrote: > > ... > The problem is that “reading” is either not defined, or the existing > flatly contradicts existing practice. > > For example, if p is a pointer to a struct, will the expression &p->m > read *p? Presumably the offset of m is substantially larger than 0? If so, my answer would be "it had better not". Does any compiler treat that statement as an access to *p ? paul
Re: Machine constraints list
> On May 8, 2016, at 6:27 PM, David Wohlferd wrote: > > Looking at the v6 release criteria (https://gcc.gnu.org/gcc-6/criteria.html) > there are about a dozen supported platforms. > > Looking at the Machine Constraints docs > (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html), there are 34 > architectures listed. That's a lot of entries to scroll thru. If these > architectures aren't supported anymore, is it time to drop some of these from > this page? > > As a first pass, maybe something like this: > > Keep > AArch64 family—config/aarch64/constraints.md > ARM family—config/arm/constraints.md > MIPS—config/mips/constraints.md > PowerPC and IBM RS6000—config/rs6000/constraints.md > S/390 and zSeries—config/s390/s390.h > SPARC—config/sparc/sparc.h > x86 family—config/i386/constraints.md > > Drop > ... Your theory is quite mistaken. A lot of the ones you labeled "drop" are supported. Quite possibly all of them. paul
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> On Jul 26, 2016, at 12:50 PM, Warren D Smith wrote: > > ... > Sigh. It's really hard to get compiler and language guys to do anything. I find it puzzling that you appear to think that insulting your audience is the best way to influence them. > ... > There is absolutely no good reason why things have to be *legislated* > to be an integer number of bytes. They could be single bits. It > would be fine. PASCAL already provided > it 40 years ago. So what? Pascal is a different language with different goals. The reason there are hundreds of programming languages in the world -- and dozens in current use -- is that each design is a tradeoff of conflicting goals, and each is a different set of choices made for a particular set of reasons. Pascal, Cobol, Lisp, C, and Python all make very different choices. They are all good choices in some situations, and bad choices in another; this is why you sometimes write in C and sometimes in Python. Support for data in sizes different from those native to most modern machine architectures comes at a very substantial cost, in compiler complexity, code size, and execution time. It's clearly doable, and a few languages have done so. But omitting it is a more common tradeoff, and clearly a good choice given the way those languages are received in the marketplace. > If you wanted to make a packed array of 63 bools, > you could pad it up to 64 to fit it in an integer number of bytes. > I'd be ok with that. I'm not ok with gratuitously wasting a factor of > 8 in memory and/or forcing programmers to do lots more work and use > cruddy syntax, merely because the compiler writers were too lazy to > just change a few numbers in their code. Since you clearly don't know much about how compilers work, it would be better to study the subject before expressing an opinion. You might also study the art of communicating persuasively. > And it is an absolute outrage that every processor in the universe > provides "add with carry" but the C language insists on preventing you > from accessing that, while providing a way > to access combined divide & remainder instead. It is simply not a > justifiable decision. You might also study processor architecture some more. If by "every processor" you mean every x86 processor, you might be correct. But of the 15 or so processor architectures I've looked at, I think that only a modest minority have add-carry or add-with-carry instructions. For example, MIPS, which is a very popular architecture in current wide use, does not have such operations. Quite apart from that, it is not the goal of most (if any) high level languages to provide direct access to all CPU facilities. Instead, the more common goal is to provide a clean set of abstractions complete enough to let people write reliable programs for the problem area in question, with minimal effort. So it is with C (and Pascal, for that matter, which doesn't have an add-with-carry primitive either). For those who want to see all the bells and whistles, there's a simple answer: assembly language. paul
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> On Jul 26, 2016, at 2:07 PM, Warren D Smith wrote: > > To the guy who falsely claimed MIPS fails to provide an add with carry > instruction, > a google search in 1 minute finds this: > > stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly > > I defy you to find any processor not providing add with carry, > (And I'm not talking about semantic bullshit. MIPS provides add with > carry, even if they do not call it that, as this answer shows.) Nonsense. What that example shows is the standard assembly language coding for doing multi-precision addition in machines that do NOT have an add-with-carry instruction (or, as in the case of MIPS, even the concept of carry). The algorithm is simple: add low order parts, see if the result is unsigned less than one of the operands; if yes, add one to the sum of the high order parts. Incidentally, note that this coding pattern only works for two's complement integers. > ... > But the thing is, I'm not willing to write that stuff for you unless > you promise to actually add these things to GCC. So, will anybody > make that promise? I very much doubt it. You might as well stop trying. paul
Re: soft-fp functions support without using libgcc
On May 16, 2014, at 12:25 PM, Ian Bolton wrote: >> On Fri, May 16, 2014 at 6:34 AM, Sheheryar Zahoor Qazi >> wrote: >>> >>> I am trying to provide soft-fp support to a an 18-bit soft-core >>> processor architecture at my university. But the problem is that >>> libgcc has not been cross-compiled for my target architecture and >> some >>> functions are missing so i cannot build libgcc.I believe soft-fp is >>> compiled in libgcc so i am usable to invoke soft-fp functions from >>> libgcc. >>> It is possible for me to provide soft-fp support without using >> libgcc. >>> How should i proceed in defining the functions? Any idea? And does >> any >>> archoitecture provide floating point support withoput using libgcc? >> >> I'm sorry, I don't understand the premise of your question. It is not >> necessary to build libgcc before building libgcc. That would not make >> sense. If you have a working compiler that is missing some functions >> provided by libgcc, that should be sufficient to build libgcc. > > If you replace "cross-compiled" with "ported", I think it makes senses. > Can one provide soft-fp support without porting libgcc for their > architecture? By definition, in soft-fp you have to implement the FP operations in software. That’s not quite the same as porting libgcc to the target architecture. It should translate to porting libgcc (the FP emulation part) to the floating point format being used. In other words, if you want soft-fp for IEEE float, the job should be very simple because that has already been done. If you want soft-fp for CDC 6000 float, you have to do a full implementation of that. paul
Re: ViewVC is broken on your web site
On Aug 6, 2014, at 2:38 PM, David Gero wrote: > Accessing https://gcc.gnu.org/viewvc/gcc/trunk/ > > Says it is showing 38 files. But in fact, it shows only the first 25. As an > example, libstdc++-v3 is missing. > > Same thing happens in other parts of the tree. > > I checked the HTML page source, and the files simply aren't there. The same on https://gcc.gnu.org/viewvc/gcc/trunk/gcc/ — except in that case it claims there should be 712 files, and here too is only shows 25 lines. Time to revert whatever change was made that broke this; as it stands the website is completely unuseable. paul
Re: ViewVC is broken on your web site
On Aug 6, 2014, at 2:59 PM, Paolo Carlini wrote: > Hi, > > On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote: >> On Aug 6, 2014, at 2:38 PM, David Gero wrote: >> >>> Accessing https://gcc.gnu.org/viewvc/gcc/trunk/ >>> >>> Says it is showing 38 files. But in fact, it shows only the first 25. As >>> an example, libstdc++-v3 is missing. >>> >>> Same thing happens in other parts of the tree. >>> >>> I checked the HTML page source, and the files simply aren't there. >> The same on https://gcc.gnu.org/viewvc/gcc/trunk/gcc/ — except in that case >> it claims there should be 712 files, and here too is only shows 25 lines. >> >> Time to revert whatever change was made that broke this; as it stands the >> website is completely unuseable. > Thus, the widget on top of the page, meant to select the page the user wants > to see (eg, 30 pages overall for ../gcc/trunk) does *not* work for you?!? It > works perfectly well for me. It doesn’t work because I didn’t see it, and when I looked at it some more I had no clue what it’s for. This is not a good way of designing a UI. It’s cryptic, it’s hard to find, the default is questionable, and it doesn’t offer a “see everything” feature. There is no visual indication (other than the “wrong” value of the files count) that the display is incomplete. At the very least, it needs to say “more entries” or “..." before and/or after the subset that is displayed, if a subset is displayed. But the preferred answer in my mind is to get rid of this thing and go back to displaying the whole page. If you do want to keep the subset thing, at least make it NOT the default. paul
Re: Problems with gcc-bugs
On Sep 29, 2014, at 7:59 PM, George R Goffe wrote: > > Jonathan, > > I'll give it a try. Thanks. > > > What is the problem with the mailing list software? Can't handle rich-text? > What a pain! I don’t know if that is true, but if so, a lot of people would argue that is a feature. (I’m inclined to agree). paul
Re: Instruction scheduler with respect to prefetch instructions.
> On Dec 13, 2014, at 5:22 AM, Ajit Kumar Agarwal > wrote: > > Hello All: > > Since the prefetch instruction have no direct consumers in the code stream, > they provide considerable freedom to the > Instruction scheduler. They are typically assigned lower priorities than most > of the instructions in the code stream. > This tends to cause all the prefetch instructions to be placed together in > the final schedule. This causes the performance > Degradations by placing them in clumps rather than evenly spreading the > prefetch instructions. > > The evenly spreading the prefetch instruction gives better speed up ratios as > compared to be placing in clumps for dirty > Misses. I can believe that’s true for some processors; is it true for all of them? I have the impression that some MIPS processors don’t mind clumped prefetches, so long as you don’t exceed the limit on total number of concurrently pending memory accesses. paul
Re: volatile access optimization (C++ / x86_64)
> On Dec 26, 2014, at 6:19 PM, Andrew Haley wrote: > > On 26/12/14 22:49, Matt Godbolt wrote: >> On Fri, Dec 26, 2014 at 4:26 PM, Andrew Haley wrote: >>> On 26/12/14 20:32, Matt Godbolt wrote: Is there a reason why (in principal) the volatile increment can't be made into a single add? Clang and ICC both emit the same code for the volatile and non-volatile case. >>> >>> Yes. Volatiles use the "as if" rule, where every memory access is as >>> written. a volatile increment is defined as a load, an increment, and >>> a store. >> >> That makes sense to me from a logical point of view. My >> understanding though is the volatile keyword was mainly used when >> working with memory-mapped devices, where memory loads and stores >> could not be elided. A single-instruction load-modify-write like >> "increment [addr]" adheres to these constraints even though it is a >> single instruction. I realise my understanding could be wrong here! >> If not though, both clang and icc are taking a short-cut that may >> puts them into non-compliant state. > > It's hard to be certain. The language used by the standard is very > unhelpful: it requires all accesses to be as written, but does not > define exactly what constitutes an access. I would look at this sort of thing with the mindset of a network protocol designer. If the externally visible actions are correct, the implementation is correct. Details not visible at the external reference interface are irrelevant. In the case of volatile variables, the external interface in question is the one at the point where that address is implemented — a memory cell, or memory mapped I/O device on a bus. So the required behavior is that load and store operations (read and write transactions at that interface) occur as written. If a processor has add instructions that support memory references (as in x86 and vax, but not mips), such an instruction will perform a read cycle followed by a write cycle. So as seen at the critical interface, the behavior is the same as if you were to do an explicit load, register add, store sequence. Therefore the use of a single add-to-memory is a valid implementation. paul
Re: volatile access optimization (C++ / x86_64)
> On Dec 27, 2014, at 1:40 PM, Andrew Haley wrote: > > On 27/12/14 18:04, Matt Godbolt wrote: >> On Sat, Dec 27, 2014 at 11:57 AM, Andrew Haley wrote: > >>> if you don't need an atomic access, why do you care that it uses a >>> read-modify-write instruction instead of three instructions? Is it >>> faster? Have you measured it? Is it so much faster that it's >>> critical for your application? >> >> Good point. No; I've yet to measure it but I will. I'll be honest: my >> instinct is that really it won't make a measurable difference. From a >> microarchitectural point of view it devolves to almost exactly the >> same set of micro-operations (barring the duplicate memory address >> calculation). It does encode to a longer instruction stream (15 bytes >> vs 7 bytes), so there's an argument it puts more pressure than needed >> on the i-cache. But honestly, it's more from an aesthetic point of >> view I prefer the increment. > > Aha! I get it now. > > I know that it's not really necessary to know a questioner's > motivation for a question like this: it makes no difference to the > answer. But you really had me mystified because I was assuming that > there had to be a practical reason for all this. Let’s not forget -Os. Most people optimize for speed, but optimization for size is needed at times and this is the sort of issue that affects it directly. paul
Bootstrap failure on Mac OS Yosemite (10.10)
I would bug this but bugz says to report things under “bootstrap” only if they are long lived failures, and I don’t know if this is. Just tried to build on my Mac OS 10.10 system, plain native build. It fails in libgcc2 due to stdio.h not found. A cross-build from the same source tree (pdp11 target) works fine, though. Here is the config, and the failure: $ head config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ ../gcc/configure --prefix=/usr/local/gcc5 --enable-languages=c,c++,objc,fortran --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-isl=/usr/local --disable-bootstrap make[4]: Entering directory `/Users/pkoning/Documents/svn/buildgcc/x86_64-apple-darwin14.0.0/i386/libgcc' # If this is the top-level multilib, build all the other # multilibs. /bin/sh ../../../../gcc/libgcc/../mkinstalldirs ../../.././gcc/i386 for file in libgcc_s.1.dylib libgcc_ext.10.4.dylib libgcc_ext.10.5.dylib; do \ rm -f ../../.././gcc/i386/$file; \ ln -s ../$file ../../.././gcc/i386/; \ done rm -f ../../.././gcc/i386/libgcc_s_x86_64.1.dylib ln -s libgcc_s.1.dylib \ ../../.././gcc/i386/libgcc_s_x86_64.1.dylib rm -f ../../.././gcc/i386/libgcc_s_ppc64.1.dylib ln -s libgcc_s.1.dylib \ ../../.././gcc/i386/libgcc_s_ppc64.1.dylib /Users/pkoning/Documents/svn/buildgcc/./gcc/xgcc -B/Users/pkoning/Documents/svn/buildgcc/./gcc/ -B/usr/local/gcc5/x86_64-apple-darwin14.0.0/bin/ -B/usr/local/gcc5/x86_64-apple-darwin14.0.0/lib/ -isystem /usr/local/gcc5/x86_64-apple-darwin14.0.0/include -isystem /usr/local/gcc5/x86_64-apple-darwin14.0.0/sys-include-g -O2 -m32 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -pipe -fno-common -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from ../../../../gcc/libgcc/libgcc2.c:27:0: ../../../../gcc/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory compilation terminated. make[4]: *** [_muldi3.o] Error 1 make[4]: Leaving directory `/Users/pkoning/Documents/svn/buildgcc/x86_64-apple-darwin14.0.0/i386/libgcc’ paul
Re: Bootstrap failure on Mac OS Yosemite (10.10)
> On Dec 29, 2014, at 2:01 PM, > wrote: > > I would bug this but bugz says to report things under “bootstrap” only if > they are long lived failures, and I don’t know if this is. > > Just tried to build on my Mac OS 10.10 system, plain native build. It fails > in libgcc2 due to stdio.h not found. A cross-build from the same source tree > (pdp11 target) works fine, though. Never mind. Operator error. Or rather, Apple error with a known workaround that I didn’t know about. :-( paul
Re: volatile access optimization (C++ / x86_64)
> On Dec 30, 2014, at 1:32 PM, Matt Godbolt wrote: > > On Tue, Dec 30, 2014 at 5:05 AM, Torvald Riegel wrote: >> I agree with Andrew. My understanding of volatile is that the generated >> code must do exactly what the abstract machine would do. > > That makes sense. I suppose I don't understand what the difference is > in terms of an abstract machine of "load; add; store" versus the > "load-add-store". At least from on x86, from the perspective of the > memory bus, there's no difference I'm aware of. That was my point. The model needs to treat those two as equivalent, otherwise the model is constructed by theories that I don’t understand. paul
Re: volatile access optimization (C++ / x86_64)
> On Jan 5, 2015, at 1:24 PM, DJ Delorie wrote: > > >> What is involved with the auditing? > > Each pattern that (directly or indirectly) uses general_operand, > memory_operand, or nonimmediate_operand needs to be checked to see if > it's volatile-safe. If so, you need to change the predicate to > something that explicitly accepts volatiles. > > There's been talk about adding direct support for a "volatile-clean" > flag that avoids this for targets where you know it's correct, which > bypasses the volatile check in those functions, but it hasn't happened > yet. I looked in the documentation and didn’t see this described. Is it? Where? A general flag seems useful, because for most targets it would seen applicable. paul
Re: volatile access optimization (C++ / x86_64)
> On Jan 5, 2015, at 1:47 PM, DJ Delorie wrote: > > >> One question: do you have an example of a non-volatile-safe machine so >> I can get a feel for the problems one might encounter? At best I can >> imagine a machine that optimizes "add 0, [mem]" to avoid the >> read/write, but I'm not aware of such an ISA. > > For example, the MSP430 backend uses a macro for movsi, addsipsi3, > subpsi3, and a few others, which aren't volatile-safe. Look for > "general_operand" vs "msp_general_operand”. To try to generalize from that: it looks like the operating principle is that an insn that expands into multiple references to a given operand isn’t volatile-safe, but one where there is only a single reference is safe? That would translate (roughly, at least) into: a general_operand that fits in a machine word is safe, one that doesn’t isn’t safe. It sure is unfortunate that this is not documented, especially since the default behavior is not to allow volatile. (And that default, even though it hurts performance, makes sense — it is the safe choice for correctness.) It sounds like all the back-end maintainers (at least those who have general_operand in their MD files) should plan to do this work, if it hasn’t already been done. It sounds pretty simple and mechanical, at least if the summary I came up with above is accurate, or if someone can produce a description that is. paul
Broken link on homepage
The “news” section first link points to "https://gcc.gnu.org/gcc-5/“ which comes up “forbidden”. The other release links seem to be fine. paul
Re: volatile access optimization (C++ / x86_64)
> On Jan 5, 2015, at 4:11 PM, DJ Delorie wrote: > > >> To try to generalize from that: it looks like the operating >> principle is that an insn that expands into multiple references to a >> given operand isn’t volatile-safe, but one where there is only a >> single reference is safe? > > No, if the expanded list of insns does "what the standard says, no > more, no less" as far as memory accesses go, it's OK. Many of the MSP > macros do not access memory in a volatile-safe way. Some do. > > If you have a single opcode that isn't volatile-safe (for example, a > string operation that's interruptable and restartable), that wouldn't > be OK despite being a single insn. Ok, but the converse — if the general_operand is accessed by more than one instruction, it is not safe — is correct, right? > > So it's kinda mechanical, but not always.
Re: Branch taken rate of Linux kernel compiled with GCC 4.9
> On Jan 13, 2015, at 7:44 AM, Alexander Monakov wrote: > > On Tue, 13 Jan 2015, Pengfei Yuan wrote: >> I use perf with rbf88:k,rff88:k events (Haswell specific) to profile >> the taken rate of conditional branches in the kernel. Here are the >> results: > [...] >> >> The results are very strange because all the taken rates are greater >> than 50%. Why not reverse the basic block reordering heuristics to >> make them under 50%? Is there anything wrong with GCC? > > Your measurement includes the conditional branches at the end of loop bodies. > When loops iterate, those branches are taken, and it doesn't make sense to > reverse them. Depending on what the processor hardware can do, the data you need is the branch mispredict rate. A lot of processors will predict forward branches not taken, reverse branches taken, and I believe GCC optimizes that way. (Some processors are different: MC68040 predicts all branches taken no matter what direction!) If the mispredict rate is unreasonably high, then that might indeed suggest missed optimizations. paul
Re: Android native build of GCC
> On Feb 6, 2015, at 5:28 AM, Andrew Haley wrote: > > On 02/06/2015 10:18 AM, Hans-Peter Nilsson wrote: >> ... >> Not sure what's not understood. IIUC you want to disable LTO >> when building gcc natively on Android? As LTO is considered a >> "language", > > ??? > > LTO is considered a "language"? Who knew? It would be nice if ./configure --help told us what the value arguments to --enable-languages are. paul
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
> On Feb 20, 2015, at 12:01 PM, Jeff Law wrote: > > On 02/20/15 04:43, Jonathan Wakely wrote: >>> ... >> >> I'm inclined to agree. >> >> Most developers aren't aware of the preconditions on memcpy, but GCC >> optimizes aggressively based on those preconditions, so we have a >> large and potentially dangerous gap between what developers expect and >> what actually happens. > But that's always true -- this isn't any different than aliasing, arithmetic > overflow, etc. The standards define the contract between the > compiler/library implementors and the developers. Once the contract is > broken, all bets are off. True. The unfortunate problem with C, and even more so with C++, is that the contract is so large and complex that few, if any, are skilled enough language lawyers to know what exactly it says. For that matter, the contract (the standard) is large and complex enough that it has bugs and ambiguities, so the contract is not in fact precisely defined. There’s a nice paper that drives this home: http://people.csail.mit.edu/akcheung/papers/apsys12.pdf For example, while most people know about the “no overlaps” rule of memcpy, stuff like aliasing are far more obscure. Or the exact meaning (if there is one) of “volatile”. It also doesn’t help that a large fraction of the contract is unenforced. You only find out about it when a new version of the compiler starts using a particular rule to make an optimization that suddenly breaks 10 year old code. I remember some heated debates between Linux folks and compiler builders when such things strike the Linux kernel. paul
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
> On Feb 20, 2015, at 12:01 PM, Jeff Law wrote: > > ... > Regardless, the right thing to do is to disable elimination of NULL pointer > checks on targets where page 0 is mapped and thus a reference to *0 may not > fault. In my mind this is an attribute of both the processor (see H8 above) > and/or the target OS. > > On those targets the C-runtime had better also ensure that its headers aren't > decorated with non-null attributes, particularly for the mem* and str* > functions. pdp11 is an example of such a target, independent of OS (with only 8 pages, clearly no one is going to unmap page 0). Fortunately there one is unlikely to find C program data structures at 0 (instead, vectors if kernel, stack limit if user mode). So no fault is correct there, but no null (0 bits) pointer is also — for practical purposes — a valid assumption.
Re: inline asm clobbers
> On Mar 11, 2015, at 7:19 PM, Ian Lance Taylor wrote:
>
> On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd
> wrote:
>>
>> Why does gcc allow you to specify clobbers using numbers:
>>
>> asm ("" : : "r" (var) : "0"); // i386: clobbers eax
>>
>> How is this better than using register names?
>>
>> This makes even less sense when you realize that (apparently) the indices of
>> registers aren't fixed. Which means there is no way to know which register
>> you have clobbered in order to use it in the template.
>>
>> Having just seen someone trying (unsuccessfully) to use this, it seems like
>> there is no practical way you can.
>>
>> Which makes me wonder why it's there. And whether it still should be.
>
> I don't know why it works. It should be consistent, though. It's
> simply GCC's internal hard register number, which doesn't normally
> change.
>
> I would agree that one should avoid it. I'd be wary of removing it
> from GCC at this point since it might break working code.
It certainly would. It’s not all that common, but I have seen this done in
production code. Come to think of it, this certainly makes sense in machines
where some instructions act on fixed registers.
Register names would be nice as an additional capability.
paul
Re: inline asm clobbers
> On Mar 11, 2015, at 8:53 PM, David Wohlferd wrote: > >>> ... >>> I would agree that one should avoid it. I'd be wary of removing it >>> from GCC at this point since it might break working code. >> It certainly would. It’s not all that common, but I have seen this done in >> production code. Come to think of it, this certainly makes sense in >> machines where some instructions act on fixed registers. > > Really? While I've seen much code that uses clobbers, I have never (until > this week) see anyone attempt to clobber by index. Since I'm basically an > i386 guy, maybe this is a platform thing? Do you have some examples/links? The example I remember was not in open code. It may have been cleaned up by now, but as supplied to us by the vendor, there were some bits of assembly code that needed a scratch register and used a fixed register (t0 == %8) for that purpose rather than having GCC deal with temporaries. So there was a clobber with “8” in it. Obviously there’s a better way in that instance, but if GCC had removed the feature before we found and cleaned up that code, we would have had a failure on our hands. An example of hardwired registers I remember is some VAX instructions (string instructions). You could write those by name, of course, but if you didn’t know that GCC supports names, you might just use numbers. On machines like VAX where the register names are really just numbers (R0, R1, etc.) that isn’t such a strange thing to do. >> Register names would be nice as an additional capability. > > Every example I've ever seen uses register names. Perhaps that what you've > seen before? No; I didn’t know that gcc supports register names. The examples I had seen all use numbers. Or more often, preprocessor symbols. It may be that’s because the most common asm code I run into is MIPS coprocessor references, and while general registers may be known by name, coprocessor registers may not be. Or it may just be a case of lack of awareness. paul
Re: Questions about C as used/implemented in practice
> On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote: > > Dear gcc list, > > we are trying to clarify what behaviour of C implementations is > actually relied upon in modern practice, and what behaviour is > guaranteed by current mainstream implementations (these are quite > different from the ISO standards, and may differ in different > contexts). I’m not sure what you mean by “guaranteed”. I suspect what the GCC team will say is guaranteed is “what the standard says”. If by “guaranteed” you mean the behavior that happens to be implemented in a particular version of the compiler, that may well be different, as you said. But it’s also not particularly meaningful, because it is subject to change at any time subject to the constraints of the standard, and is likely to be different among different versions, and for that matter among different target architectures and of course optimization settings. paul
Re: Is there a way to adjust alignment of DImode and DFmode?
> On May 20, 2015, at 1:00 PM, H.J. Lu wrote: > > By default, alignment of DImode and DFmode is set to 8 bytes. When did that change? I know it was 4 in the past, unless you specifically passed a compile switch to make it 8. paul
Re: Is there a way to adjust alignment of DImode and DFmode?
> On May 20, 2015, at 1:22 PM, Jakub Jelinek wrote: > > On Wed, May 20, 2015 at 05:19:28PM +, paul_kon...@dell.com wrote: >> >>> On May 20, 2015, at 1:00 PM, H.J. Lu wrote: >>> >>> By default, alignment of DImode and DFmode is set to 8 bytes. >> >> When did that change? I know it was 4 in the past, unless you specifically >> passed a compile switch to make it 8. > > For i?86 that is only field alignment (i.e. inside of structs). I missed that. Thanks. paul
RE: Bootstrap with -Wmissing-prototypes doesn't work for C++
I think the point is that the effect of -Wmissing-prototypes is always enabled
in C++, so that switch is rejected. The solution would seem to be to remove
that switch from the command line if C++ is used to build; that will produce
the intended result.
paul
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of H.J. Lu
Sent: Friday, August 19, 2011 3:34 PM
To: Joe Buck
Cc: GCC Development
Subject: Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
[hjl@gnu-33 gcc]$ cat x.c
int
foo (int x)
{
return x;
}
[hjl@gnu-33 gcc]$ ./xgcc -B./ -S -O -Wmissing-prototypes x.c
x.c:2:1: warning: no previous prototype for 'foo' [-Wmissing-prototypes]
[hjl@gnu-33 gcc]$ ./g++ -B./ -S -O -Wmissing-prototypes x.c
cc1plus: warning: command line option '-Wmissing-prototypes' is valid for
Ada/AdaWhy/C/ObjC but not for C++ [enabled by default]
[hjl@gnu-33 gcc]$ ./g++ -B./ -S -O x.c
[hjl@gnu-33 gcc]$
Is this a bug?
On Fri, Aug 19, 2011 at 12:24 PM, Joe Buck wrote:
> I'm confused. Since C++ treats the lack of a prototype as a hard error, what
> does it mean to make -Wmissing-prototypes useless?
>
>
> From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] On Behalf Of H.J.
> Lu [hjl.to...@gmail.com]
> Sent: Friday, August 19, 2011 9:36 AM
> To: GCC Development
> Subject: Bootstrap with -Wmissing-prototypes doesn't work for C++
>
> Since -Wmissing-prototypes doesn't work for C++, using
> C++ to bootstrap GCC makes -Wmissing-prototypes useless.
> You will see the -Wmissing-prototypes message in stage 1, but you
> won't see it in stage3 2/3.
>
> --
> H.J.
--
H.J.
RE: CCmode size
>genmodes.c has the following comment: > > > /* Again, nothing more need be said. For historical reasons, > > > the size of a CC mode is four units. */ > validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET); > > m->bytesize = 4; > > >Now, this is probably ok for _most_ archs but for my arch where a word == byte >== 16 bits, this causes a lot of pain. Is there a way (macro?) to change this >to m->bytesize = 1; in the backend without hardcoding it into genmodes.c? It would seem that making it equal to word size (whatever that is on the platform) or size of the int type would be a way to make this better. Would that have any bad consequences for other platforms? paul
RE: Expanding instructions with condition codes inter-deps
>From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of >Richard Henderson >On 10/17/2011 03:50 AM, Paulo J. Matos wrote: >>... >> (for example, it would be ok to output negqi2, xorqi3 and >> addc_internal since xorqi3 only sets N and Z, not the Carry bit) > >For that you'd have to model all of the flags bits independently. >I don't believe any target has found that level of complexity to be worth the >trouble. Something like that shows up in the pdp11, where "mov" does not touch C. And C matters for multi-word arithmetic, and also for unsigned compares. So I think a CCmode implementation there would model C separately from the other three flag bits. So not 4 separate elements but two. Right now it's a cc0 target but I figure on changing that at some point. The reasons Paulo mentioned are one of the main reasons for that. paul
RE: Expanding instructions with condition codes inter-deps
>There are lots of parts of the compiler that don't optimize well when an insn >has more than one output. For the normal insn, just clobber the flags; don't >include a second SET. Yes, but... isn't the whole point of CC modeling that you can take advantage of the CC left around by an instruction? Typically in machines with condition codes, you can eliminate test instructions (compare with zero) if the previous instruction has that variable as its output. But if we're discouraged from writing insns with CC outputs as normal practice, and if the compiler doesn't handle such constructs well in optimization, what then? Is cc0 any better here? In cc0 style condition code handling, the condition codes output is implicit rather than explicitly stated. Does that help, or hurt, or make no difference for the point you mentioned? paul
RE: structure offset to structure name conversion.
> If I have a structure e.g.
> struct test_s {
> int32_t var1;
> int32_t var2;
> uint64_t var3;
> int var4;
> } test;
>
> If I have an offset value of 8, I wish to do a lookup and get to:
> test.var3
>
> Is there some part of gcc that I could use to parse .h files and
> produce a table for me of offset against each variable in the
> structure to permit this sort of lookup?
GDB can do this, of course. There is also a utility "pahole" that reads debug
data from an object file or executable file and produces that information. See
your favorite search engine.
paul
RE: volatile correctness: combine vs. target.md
... >> It's never correct to exchange volatile accesses. > >That's not true. volatile accesses to different memory locations >have no special dependence. If it happens that GCC doesn't >do this kind of things then this is only because most passes >don't thouch volatile stmts at all (thus the reports for sub-optimal >code with volatile - we don't even try to do legal transformations). I'm confused. Do you mean that in Volatile int *a, *b; Int j, k; J = *a; k = *b; it is ok to fetch *b before *a? I can't think of any device driver writer who would expect that. paul
RE: Dealing with compilers that pretend to be GCC
Write a test that checks for the existence of that machinery. I agree with the earlier comments. Checking version strings or program names is the wrong way, because you're essentially saying "if it is X then I know it can do Y" rather than directly asking the question "can it do Y". The issue with "if it is X then..." is that a rule of that form is fragile. Even if it is correct today -- which is unlikely -- it WILL be wrong tomorrow. What matters for your purposes is "can it do Y" -- does it (1) support the language features you need, and (2) does it support the GCC plugin mechanism. If the answer to both questions is yes, then your code should work, and it doesn't matter one bit whether the compiler calls itself GCC or FOOCC. paul -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Ludovic Courtès Sent: Thursday, January 19, 2012 11:52 AM To: Paul Eggert Cc: gcc@gcc.gnu.org; bug-autoc...@gnu.org Subject: Re: Dealing with compilers that pretend to be GCC Hi Paul, Paul Eggert skribis: > A 'configure' script is supposed to check for behavior, not identity. > If the compiler supports the features needed, then generally speaking > a 'configure' script shouldn't care whether the compiler is truly GCC. Right. But how would you write feature tests that would check (1) whether the GNU C language is supported, and (2) whether GCC plug-ins are supported? That’s the problem I’m trying to solve. Thanks, Ludo’.
RE: Assignment to volatile objects
I would prefer this to generate a warning. The C language standard change you refer to is a classic example of a misguided change, and any code whose behavior depends on this deserves a warning message, NOT an option to work one way or the other. paul -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Zoltán Kócsi Sent: Monday, January 30, 2012 5:03 PM To: gcc@gcc.gnu.org Subject: Assignment to volatile objects Now that the new C standard is out, is there any chance that gcc's behaviour regarding to volatile lhs in an assignment changes? This is what it does today: volatile int a, b; a = b = 0; translates to b = 0; a = b; because the standard (up to and including C99) stated that the value of the assignment operator is the value of the lhs after the assignment. The C11 standard says the same but then it explicitely states that the compiler does not have to read back the value of the lhs, not even when the lhs is volatile. So it is actually legal now not to read back the lhs. Is there a chance for the compiler to get a switch which would tell it explicitely not to read the value back? Zoltan
RE: -fno-ira removal
>arc m32c m68hc11 mmix pdp11 score vax I'll try to get to pdp11 soon. paul
Re: Should -Wmaybe-uninitialized be included in -Wall?
On Jul 10, 2013, at 10:42 AM, Andi Kleen wrote: > Andrew Haley writes: > >> On 07/09/2013 12:59 PM, Andreas Arnez wrote: >>> With this situation at hand, I wonder whether it's a good idea to keep >>> maybe-uninitialized included in -Wall. Projects which have been using >>> "-Wall -Werror" successfully for many years are now forced to >>> investigate non-existing bugs in their code. >> >> But maybe-uninitialized is very useful, and it's not really inappropriate >> for -Wall. I would question the appropriateness of using -Wall -Werror >> in production code. > > Unfortunately a number of projects do that. I regularly have to remove > -Werror from shipped makefiles, and it's primarily due to this warning. > > Maybe not erroring on the maybe by default would be a good idea? I would rather see such warnings fixed. They exist for a good reason. (If there are false warnings, those are compiler bugs to fix. But in most cases I have seen, the warnings are legit.) Changing -Werror to mean "error out on *most* warnings" would be a very serious mistake. paul
Re: Should -Wmaybe-uninitialized be included in -Wall?
On Jul 10, 2013, at 12:44 PM, Jeff Law wrote: > On 07/10/2013 10:29 AM, Jonathan Wakely wrote: >> On 10 July 2013 17:11, Andi Kleen wrote: >>> FWIW basically -Werror -Wall defines a compiler version specific >>> variant of C. May be great for individual developers, but it's always >>> a serious mistake in any distributed Makefile. >> >> That's a very nice way to put it. > Yup. Particularly when one considers that new warnings tend to show up in > -Wall from one release to the next. > > I've often suggested that for organizations/projects that are sensitive to > additions to -Wall that they use an explicit set of -W options rather than > the often changing -Wall. True. But even if you do that, you may still get new warnings for new compiler releases because of changes/improvements in the checkers. It seems to me there are two cases. One is releases, where you want to maximize the odds that an install will work. For that you clearly don't want -Werror, and you might want to trim back the warnings. The other is the development phase, where you want to weed out questionable code. So for development builds you want lots of warnings, and possible -Werror as well to increase the odds that flagged code will be seen and fixed. paul
Re: Automated Toolchain Building and Testing
On Aug 28, 2013, at 8:52 PM, Samuel Mi wrote: > On Thu, Aug 29, 2013 at 2:54 AM, Jan-Benedict Glaw wrote: >> On Thu, 2013-08-29 02:43:54 +0800, Samuel Mi wrote: ...or can you, instead of using the Java-based client part of Jenkins, issue all commands over a SSH (or maybe even Telnet...) session? Is there a module for this available? >>> If making jenkins running on target systems you want whether old or >>> modern, then take a look at Jenkins-SSH >>> (https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+SSH) to remotely >>> control over ssh. >> >> This looks like a SSH connector for the Jenkins server side, no? > No. Actually, Jenkins implements a built-in SSH server within itself. > At this point, it's consider to be a normal SSH server. So, you can > remotely access Jenkins server via SSH after setting up corresponding > configurations within it. What non-antique Linux doesn't come with Python? paul
Re: GCC retargeting
On Oct 9, 2013, at 5:24 AM, Umesh Kalappa wrote: > Dear Group , > > We are re-targeting the GCC to the CISC target ,which has the eight > 8-bit registers and same register set can used as pair register for > 16 bit computation i.e four 16-bits . > > Any one in the group tell me ,How do i model this requirement using > the target macros like > > REG_CLASS_NAMES and REG_CLASS_CONTENTS etc. > > > Thanks > ~Umesh There probably are other examples, but one you could look at is pdp11, which has 16 bit registers that also can be used in even/odd pairs for 32 bit operations. paul
Re: Make SImode as default mode for INT type.
On Dec 6, 2013, at 5:40 AM, Umesh Kalappa wrote:
> Hi all,
>
> We are re-targeting the gcc 4.8.1 to the 16 bit core ,where word =int
> = short = pointer= 16 , char = 8 bit and long =32 bit.
>
> We model the above requirement as
>
> #define BITS_PER_UNIT 8
>
> #define BITS_PER_WORD 16
>
> #define UNITS_PER_WORD 2
>
> #define POINTER_SIZE16
>
> #define SHORT_TYPE_SIZE 16
>
> #define INT_TYPE_SIZE 16
>
> #define LONG_TYPE_SIZE 32
>
> #define FLOAT_TYPE_SIZE 16
>
> #define DOUBLE_TYPE_SIZE32
>
> Tried to compile the below sample by retargeted compiler
>
> int a =10;
>
> int b =10;
>
>
> int func()
>
> {
>
> return a+ b;
>
> }
>
> the compiler is stating that the a and b are global with short type(HI
> mode) of size 2 bytes.
>
> where as we need the word mode as SI not HI ,I do understand that the
> SI and HI modes are of same size but till I insist better to have SI
> mode.
>
> Please somebody or expert in the group share their thought on the
> same like how do we can achieve this ?
>
> Thanks
> ~Umesh
As Richard mentioned, SImode is not "the mode for int" but rather "the mode for
the type that's 4x the size of QImode". So in your case, that would be the
mode for "long" and HImode is the mode for "int".
Apart from the float and double sizes, what you describe is just like the pdp11
target. And indeed that target has int == HImode as expected.
paul
Re: linux says it is a bug
On Mar 4, 2014, at 2:30 PM, Richard Henderson wrote:
> On 03/04/2014 01:23 AM, Richard Biener wrote:
>> Doesn't sound like a bug but a feature. We can move
>> asm ("" : : : "memory") around freely up to the next/previous
>> instruction involving memory.
>
> Asms without outputs are automatically volatile. So there ought be zero
> change
> with and without the explicit use of the __volatile__ keyword.
That’s what the documentation says but it wasn’t actually true as of a couple
of releases ago, as I recall.
paul
Re: linux says it is a bug
On Mar 5, 2014, at 10:07 AM, Richard Henderson wrote: > On 03/04/2014 10:12 PM, Yury Gribov wrote: Asms without outputs are automatically volatile. So there ought be zero change with and without the explicit use of the __volatile__ keyword. >>> >>> That’s what the documentation says but it wasn’t actually true >>> as of a couple of releases ago, as I recall. >> >> Looks like 2005: >> >> $ git annotate gcc/c/c-typeck.c >> ... >> 89552023( bonzini 2005-10-05 12:17:16 + 9073) /* asm >> statements without outputs, including simple ones, are treated >> 89552023( bonzini 2005-10-05 12:17:16 + 9074) as >> volatile. */ >> 89552023( bonzini 2005-10-05 12:17:16 + 9075) >> ASM_INPUT_P (args) = simple; >> 89552023( bonzini 2005-10-05 12:17:16 + 9076) >> ASM_VOLATILE_P (args) = (noutputs == 0); > > Yep, that's the one. So, more than "a couple" of releases: gcc 4.2 and later. Thanks gentlemen. That explains it — we ran into this in GCC 3.3.3 and then upgraded from there straight to V4.6 or so. paul
Re: Builtin: stack pointer
On Mar 27, 2014, at 6:38 AM, Renato Golin wrote: > On 27 March 2014 10:29, Andreas Schwab wrote: >> Depends on what you need the value for. > > Mostly unwind code that uses both FP and SP, example: But unwind code is inherently platform-dependent. Your objection to the inline asm that references SP by name is that it’s platform dependent. The builtin would reduce the amount of platform dependent code by one line, i.e., probably much less than one percent. paul
RE: RFC: -Wall by default
I think removing an existing warning from -Wall would be a bad idea. paul -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Gerald Pfeifer Sent: Monday, April 09, 2012 12:30 PM To: Robert Dewar Cc: Jonathan Wakely; James Cloos; gcc@gcc.gnu.org; Miles Bader; Gabriel Dos Reis; Ian Lance Taylor; Andrew Haley Subject: Re: RFC: -Wall by default On Sun, 8 Apr 2012, Robert Dewar wrote: > Do you really want me to file hundreds of bug reports that are for > cases of uninitialized variables well known to everyone, and well > understood by everyone, and not easy to fix (or would have been fixed > long ago)? Perhaps we should move this class of warning from -Wall to -Wextra? (I'd prefer that over introducing yet another option -Wstandard.) Gerald
RE: RFH - Testing targets for the switch to C++
Tested x86_64-apple-darwin10, pdp11-aout -- both pass. paul
Re: IRA and two-phase load/store
I think this is what secondary reload is for. Check the internals manual. Something like this shows up in the pdp11 port, where float registers f4 and f5 can't be loaded/stored directly. You can see in that port how this is handled; it seems to work. paul On Apr 27, 2012, at 5:31 PM, Greg McGary wrote: > I'm working on a port that does loads & stores in two phases. > Every load/store is funneled through the intermediate registers "ld" and "st" > standing between memory and the rest of the register file. > > Example: >ld=4(rB) >... >... >rC=ld > >st=rD >8(rB)=st > > rB is a base address register, rC and rD are data regs. The ... represents > load delay cycles. > > The CPU has only a single instance of "ld", but the machine description > defines five in order to allow overlapping live ranges to pipeline loads. > > My mov insn patterns have constraints so that a memory destination pairs with > the "st" register source, and a memory source pairs with "ld" destination > reg. The trouble is that register allocation doesn't understand the > constraint, so it loads/stores from/to random data registers. > > Is there a way to confine register allocation to the "ld" and "st" classes, > or is it better to let IRA do what it wants, then fixup after reload with > splits to turn single insn rC=MEM into the insn pair ld=MEM ... rC=ld ? > > Greg
Re: Register constraints + and =
On May 4, 2012, at 9:44 AM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> Expand generates:
>>
>> (define_insn_and_split "movmem_long"
>> [(set (match_operand:QI 2 "register_operand" "d,c") (const_int 0))
>> (set (mem:BLK (match_operand:QI 0 "register_operand" "d,c"))
>>(mem:BLK (match_operand:QI 1 "register_operand" "x,c")))
>> (set (match_dup 0) (plus:QI (match_dup 0) (match_dup 2)))
>> (set (match_dup 1) (plus:QI (match_dup 1) (match_dup 2)))
>> (clobber (match_scratch:QI 3 "w,w"))]
>> "!TARGET_NO_BLOCK_COPY"
>> "#"
>> "&& reload_completed"
>> [(const_int 0)]
>> {
>> if((which_alternative == 0 && REGNO(operands[2]) == RAH))
>> || which_alternative == 1)
>> {
>>emit_move_insn(operands[3], operands[0]);
>>emit_move_insn(operands[0], operands[2]);
>>emit_move_insn(operands[2], operands[3]);
>> }
>> emit_insn(gen_bc2());
>> DONE;
>> })
>>
>> From what I understand + is for input/output operands, = for output
>> only operands. Since in the above rule (a parallel) all operands are
>> written to and read to, does this mean all their constraints should
>> start with +? Or this only applies per set within each parallel (which
>> doesn't seem to make much sense)?
>
> I agree that there is something wrong here. I agree that as written
> the constraints for operands 0, 1, and 2 should have a '+'.
>
> That said, a '+' constraint is most useful for a pattern that expands
> into multiple instructions. I think this would be better written along
> the lines of
>
> (set (match_operand:QI 2 "register_operand" "=d,c") (const_int 0))
> (set (mem:BLK (match_operand:QI 3 "register_operand" "0")
>(match_operand:QI 4 "register_operand" "1")))
> (set (match_operand:QI 0 "register_operand" "=d,c")
> (plus:QI (match_dup 3)
>(match_operand:QI 5 "register_operand" "2"
> (set (match_operand:QI 1 "register_operand" "=x,c")
> (plus:QI (match_dup 4) (match_dup 5)))
> (clobber (match_scratch:QI 3 "=w,w"))
>
> Also it looks like it might be possible to add a third alternative such
> that that alternative does not require the match_scratch.
I thought that the "operand" in a mem:BLK is the pointer to the block, not the
block itself. So if the instruction(s) generated don't touch the pointer -- a
likely answer for a block-move instruction -- then the operand would be
read-only. Is that the right interpretation?
What I ended up doing in pdp11.md is to add "clobber" clauses for the operands,
because the generated code is typically a block-copy loop that steps the
pointer registers through the buffer. It appeared to do the right thing, but
I'll admit it was more of a "try this until it works" type of thing rather than
a deep understanding of the precisely correct interpretation.
paul
Re: Register constraints + and =
On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote: > writes: > >> I thought that the "operand" in a mem:BLK is the pointer to the block, >> not the block itself. So if the instruction(s) generated don't touch >> the pointer -- a likely answer for a block-move instruction -- then >> the operand would be read-only. Is that the right interpretation? > > Yes. > > But many block move instructions do in fact touch the pointer, in that > they update the registers pointing to the starts of the blocks to point > to the ends after the instruction completes. I interpreted + to mean that the operand is written with a value known to the compiler, as opposed to clobber which means that the value is not known (or not one that can be described to the compiler). So I take it that for mem:BLK a + operand is interpreted as final value == end of the buffer? Or byte after the buffer? paul
Re: Register constraints + and =
On May 4, 2012, at 1:52 PM, Ian Lance Taylor wrote: > writes: > >> On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote: >> >>> writes: >>> I thought that the "operand" in a mem:BLK is the pointer to the block, not the block itself. So if the instruction(s) generated don't touch the pointer -- a likely answer for a block-move instruction -- then the operand would be read-only. Is that the right interpretation? >>> >>> Yes. >>> >>> But many block move instructions do in fact touch the pointer, in that >>> they update the registers pointing to the starts of the blocks to point >>> to the ends after the instruction completes. >> >> I interpreted + to mean that the operand is written with a value known to >> the compiler, as opposed to clobber which means that the value is not known >> (or not one that can be described to the compiler). So I take it that for >> mem:BLK a + operand is interpreted as final value == end of the buffer? Or >> byte after the buffer? > > H. I don't really know what you mean, so there is some sort of > communication difficulty. > > A '+' in a constraint for an operand means that the operand is both read > and written by the instruction. It's relatively unusual to find such a > constraint in a GCC backend. In a GCC backend, it's more common to > write the instruction as a PARALLEL with one insn that sets the operand, > another insn that uses the operand, and a matching constraint to put > both operands in the same register. > > A '+' in a constraint doesn't say anything at all about what value the > register has after the insn. That is expressed only in the RTL. > > The place where you often see '+' in a constraint is in an asm > instruction. The asm instruction could also use a matching constraint, > but there is generally less point since the asm instruction can't say > anything about the value the register will have after the asm executes. > > Comparing '+' in a constraint and CLOBBER doesn't make sense. The '+' > tells the register allocator something about which registers it may use. > In particular, an operand with a '+' constraint may not be placed in a > register that holds either an input or an output operand. An operand > with an '=' constraint, on the other hand, may be placed in the same > register as an input operand. > > Constraints like '+' matter to the register allocator and reload. RTL > constructs like CLOBBER matter to the RTL optimizers. They are > different categories of things. > > Ian Thanks, that helps. What I was trying to describe is the handling of a memcpy operation in the .md file, where the operands are the memory pointers and (in my case) I want to tell the machinery that the registers it's using to pass in the addresses no longer have those addresses in them on completion. So I put in clobbers to say that. What I really wanted to do is express that the pointer registers, on completion, point just past the buffer, so the optimizer could take advantage of that, but it wasn't clear how one would do that. paul
Re: Register constraints + and =
On May 9, 2012, at 5:34 AM, Paulo J. Matos wrote: > On 08/05/12 21:57, Jan Hubicka wrote: >> >> In expanded form it is >> >> (set (reg5) (const 10)) >> >> (parallel [(set (reg2) (const 0)) >>(set (reg0) (plus (reg3) (reg5))) >>(set (reg1) (plus (reg4) (reg5))) >>(set (mem (reg3)) (mem (reg4)))]) >> >> (set (reg0) (plus (reg0) (const 10))) >> >> (set (reg1) (plus (reg1) (const 10))) >> >> instructions separated by empty lines. >> > > > Jan, > why do you need the two sets after the parallel? Aren't those sets repeating > what the parallel is already doing? They look like they are doing the same as > the second and third insn in the parallel. > He was showing the RTL expansion of the example he gave: >> >> >> So seeing something like >> >> memcpy(DX,SX,10) >> DX+=10 >> SX+=10 >> >> is IMO foldable to >> >> memcpy(DX,SX,20) > The two extra sets are for the two statements after the memcpy, and the concern is that the optimizer (a future optimizer) could fold that and mess up the intent. paul
Trying to track down a register allocation issue
I'm running into an ICE due to what looks like wrong register allocation, and
I'm trying to figure out where the problem lies. It shows up with today's GCC
(trunk). I haven't yet tried to narrow it down to a particular change.
It shows up in the pdp11 target, -O2. Not clear that this is pdp11 specific.
The ira dump shows this insn:
(insn 72 71 73 8 (set (reg:SI 129 [ D.2729 ])
(mem:SI (post_inc:HI (reg:HI 167 [orig:107 ivtmp.50 ] [107])) [2
MEM[base: D.2843_99, offset: 0B]+0 S4 A16]))
../../../../../newlib-1.18.0/newlib/libc/stdlib/gdtoa-gethex.c:79 11 {movsi}
(expr_list:REG_INC (reg:HI 167 [orig:107 ivtmp.50 ] [107])
(nil)))
The pointer register (167) is used later in the block, and is shown as alive at
block end.
The reload dump shows it like this:
(insn 72 248 250 8 (set (reg:SI 2 r2)
(mem:SI (post_inc:HI (reg:HI 2 r2)) [2 MEM[base: D.2843_99, offset:
0B]+0 S4 A16]))
../../../../../newlib-1.18.0/newlib/libc/stdlib/gdtoa-gethex.c:79 11 {movsi}
(expr_list:REG_INC (reg:HI 2 r2)
(nil)))
That causes an ICE in the postreload stage. But in any case, I'm trying to
figure out why reload assigned R2 both to reg 129 and to reg 167, when 167 is
still alive.
Any suggestions on where to look?
paul
Re: Trying to track down a register allocation issue
On May 14, 2012, at 5:47 PM, Joern Rennecke wrote: > Quoting paul_kon...@dell.com: > >> I'm running into an ICE due to what looks like wrong register allocation, >> and I'm trying to figure out where the problem lies. It shows up with >> today's GCC (trunk). I haven't yet tried to narrow it down to a particular >> change. >> >> It shows up in the pdp11 target, -O2. Not clear that this is pdp11 specific. > > If a match test is confused with an overlap test somehwhere, the incidence > would be influenced by the endianness. The little-endian equivalent > would be (reg:SI 2) versus (reg:HI 3). Except that the latter wouldn't > tend to be created by (misdirected) attempts to tie modes of different sizes. Hm. But pdp11.h says: #define MODES_TIEABLE_P(MODE1, MODE2) 0 so it seems that tying modes of different sizes should not be happening here. Also, I don't see reg:SI 2 vs. reg:HI 3, I see reg:SI 2 vs. reg:HI 2. So the overlap is explicit, it doesn't depend on endians or mode sizes. > And of course you have a word size factor here; on a 32 or 64 bit target, > you need larger modes to get multi-hard-register pseudos. paul
50% slowdown with LTO
I'm not sure what LTO is supposed to do -- the documentation is not exactly clear. But I assumed it should make things faster and/or smaller. So I tried using it on an application -- a processor emulator, CPU intensive code, a lot of 64 bit integer arithmetic. Using a compile/assembler run on the emulated system as a benchmark, I compared the code on x86_64-linux, gcc 4.7.0, -O2 plain, -O2 -fprofile-use (after having done -fprofile-generate), and -O2 -fprofile-use -flto (using a separate set of profile data files from -fprofile-generate -flto). Results: profiling speeds things up about 8%, but LTO is 50% (!) slower than without. Any suggestions of what to look at for this? paul
gcc trunk fails to build without isl/cloog
The installation instructions seem to imply that GCC can be built without having ISL and/or CLOOG installed, and the configure script accepts --without-isl and --without-cloog. But I can't build that. Reading the installation instructions makes me expect that such a configuration would skip the building of the "graphite" loop optimization machinery. What happens instead is that it's built anyway, but the makefile aborts at the point where it tries to compile gcc/graphite.c (because cloog/cloog.h does not exist). Is this supposed to work? paul
ISL install troubles
Where does one go to report issues with ISL? Since GCC doesn't build without it, I'm trying to install ISL from sources. That doesn't work. It accepts --with-gmp but there is nothing in the Makefile to pay attention to that -- the compiles are done without any switches so it fails unless gmp.h is in /usr/include. Since I installed gmp from source in the usual way, it's in /usr/local/. paul
Re: gcc trunk fails to build without isl/cloog
On Aug 13, 2012, at 12:42 PM, H.J. Lu wrote: > On Mon, Aug 13, 2012 at 9:01 AM, wrote: >> The installation instructions seem to imply that GCC can be built without >> having ISL and/or CLOOG installed, and the configure script accepts >> --without-isl and --without-cloog. >> >> But I can't build that. Reading the installation instructions makes me >> expect that such a configuration would skip the building of the "graphite" >> loop optimization machinery. What happens instead is that it's built >> anyway, but the makefile aborts at the point where it tries to compile >> gcc/graphite.c (because cloog/cloog.h does not exist). >> >> Is this supposed to work? >> > > Trunk builds fine without ppl when GCC is configured with --without-ppl: > > auto-host.h:/* #undef HAVE_cloog */ > > [hjl@gnu-mic-2 build-x86_64-linux]$ ldd gcc/cc1 > linux-vdso.so.1 => (0xff98) > libmpc.so.2 => /libx32/libmpc.so.2 (0xf73ad000) > libmpfr.so.4 => /libx32/libmpfr.so.4 (0xf7157000) > libgmp.so.10 => /libx32/libgmp.so.10 (0xf6eeb000) > libdl.so.2 => /libx32/libdl.so.2 (0xf6ce8000) > libz.so.1 => /libx32/libz.so.1 (0xf6ad4000) > libm.so.6 => /libx32/libm.so.6 (0xf67db000) > libc.so.6 => /libx32/libc.so.6 (0xf642c000) > /libx32/ld-linux-x32.so.2 (0xf75c1000) > [hjl@gnu-mic-2 build-x86_64-linux]$ > > I do have mpc, mpfr and gmp. Is ppl another name for cloog? If I don't have cloog, should I say --without-ppl? That doesn't make much sense, and it isn't documented. paul
Re: ISL install troubles
On Aug 14, 2012, at 4:17 AM, Richard Guenther wrote: > On Mon, Aug 13, 2012 at 6:25 PM, wrote: >> Where does one go to report issues with ISL? >> >> Since GCC doesn't build without it, I'm trying to install ISL from sources. >> That doesn't work. It accepts --with-gmp but there is nothing in the >> Makefile to pay attention to that -- the compiles are done without any >> switches so it fails unless gmp.h is in /usr/include. Since I installed gmp >> from source in the usual way, it's in /usr/local/. > > GCC builds without ISL, it just disables support for GRAPHITE optimizations. That's what you would think but that's not actually the case. What happens is that either configure or the build blows up at the building of graphite, I reported that yesterday as well. > > The easiest way to use ISL is to drop it into the GCC source tree, alongside > with cloog. I'll give that a try. paul
Re: ISL install troubles
On Aug 14, 2012, at 4:17 AM, Richard Guenther wrote: > On Mon, Aug 13, 2012 at 6:25 PM, wrote: >> Where does one go to report issues with ISL? >> >> Since GCC doesn't build without it, I'm trying to install ISL from sources. >> That doesn't work. It accepts --with-gmp but there is nothing in the >> Makefile to pay attention to that -- the compiles are done without any >> switches so it fails unless gmp.h is in /usr/include. Since I installed gmp >> from source in the usual way, it's in /usr/local/. > > GCC builds without ISL, it just disables support for GRAPHITE optimizations. > > The easiest way to use ISL is to drop it into the GCC source tree, alongside > with cloog. > > Richard. That worked. But since ISL is also distributed by itself and has an installation procedure that looks like it is meant to work when that procedure is run by itself, it would be nice if that procedure actually worked. paul
Size difference in base class between GCC releases
I'm doing some checking of data structure layouts in different releases of our code -- which were produced by different releases of GCC (3.3.3 vs. 4.5.4). One difference I'm seeing that is puzzling is in the handling of base classes. Specifically, the case where a base class has padding at the end to fill it out to a multiple of the alignment. In GCC 3.3.3, when such a class is used as a base class, that padding is omitted, and the first derived class data member starts right after the last base class real (not pad) data member. In GCC 4.5.4, the base class is used padding and all, the first derived class data member starts after the padding of the base class. Which is correct? Or are both correct? This sort of thing is a potential cause of trouble if such a class is used as a container for persistent data. paul
Re: Size difference in base class between GCC releases
On Aug 27, 2012, at 3:33 PM, Jonathan Wakely wrote: > On 27 August 2012 19:48, Paul_Koningwrote: >> I'm doing some checking of data structure layouts in different releases of >> our code -- which were produced by different releases of GCC (3.3.3 vs. >> 4.5.4). >> >> One difference I'm seeing that is puzzling is in the handling of base >> classes. Specifically, the case where a base class has padding at the end >> to fill it out to a multiple of the alignment. >> >> In GCC 3.3.3, when such a class is used as a base class, that padding is >> omitted, and the first derived class data member starts right after the last >> base class real (not pad) data member. In GCC 4.5.4, the base class is used >> padding and all, the first derived class data member starts after the >> padding of the base class. > > This depends on whether the base class is a POD or not. > > According to a note in the Itanium C++ ABI "the C++ standard requires > that compilers not overlay the tail padding in a POD" (I don't know > off the top of my head where that is stated in the standard.) > >> Which is correct? Or are both correct? This sort of thing is a potential >> cause of trouble if such a class is used as a container for persistent data. > > GCC 3.4 and later conform to the Itanium C++ ABI, which specifies the > behaviour you're seeing as required by the C++ standard, so 4.5 is > correct. Interesting. What if the base class is not a POD? It doesn't seem to be, if I remember the definition of POD correctly. paul
Re: Size difference in base class between GCC releases
On Aug 27, 2012, at 4:05 PM, Gabriel Dos Reis wrote: > On Mon, Aug 27, 2012 at 1:48 PM, wrote: >> I'm doing some checking of data structure layouts in different releases of >> our code -- which were produced by different releases of GCC (3.3.3 vs. >> 4.5.4). >> >> One difference I'm seeing that is puzzling is in the handling of base >> classes. Specifically, the case where a base class has padding at the end >> to fill it out to a multiple of the alignment. >> >> In GCC 3.3.3, when such a class is used as a base class, that padding is >> omitted, and the first derived class data member starts right after the last >> base class real (not pad) data member. In GCC 4.5.4, the base class is used >> padding and all, the first derived class data member starts after the >> padding of the base class. >> >> Which is correct? Or are both correct? This sort of thing is a potential >> cause of trouble if such a class is used as a container for persistent data. >> >>paul >> > > Is this message > > http://gcc.gnu.org/ml/gcc/2002-08/msg00874.html > > relevant to your case? > > -- Gaby Yes, that looks like the exact case. And the mail thread seems to say that the "3.3.3" behavior I'm seeing is what G++ was doing at that time, as was HP -- but not Intel. So now we have it done differently in later compilers. I know this is changing data structure layouts in our code; I don't know yet if that is a problem (i.e., if it applies to layouts used in persistent data or in protocol messages). I assume there isn't some compiler switch I can use to control this behavior? paul
Re: C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?
On Aug 28, 2012, at 9:45 AM, Michael Matz wrote: > Hi, > > On Tue, 28 Aug 2012, Ian Lance Taylor wrote: > >>> Or do we have a rule than any file using C++ specific feature should >>> be renamed from *.c to *.cc at the moment the C++ feature goes inside? >> >> We do not have such a rule and I would not recommend it. I think we >> should rename all the files at once at some point. > > That has implications on things like > svn blame file.cc@somerevision > in case somerevision was before that rename. So I'm not sure we should > rename the files. I see disadvantages but no real advantages. True, that particular syntax doesn't work, but "svn blame file.cc -r somerevision" does -- because that command identifies the object to operate on in the namespace of the current (head) revision, and then examines the state of that object back in the requested revision. paul
Bug in bitfield handling?
This seems to be a bug:
struct bug
{
int f1:1;
unsigned long long f2:31;
};
struct bug test = { 1, 0x8000ULL };
int main (int c, char **v)
{
unsigned long long tf2;
tf2 = test.f2 << 16;
if (tf2 == 0x8000ULL)
return 0;
return 1;
}
Since the underlying type of field f2 is unsigned long long, I would not expect
the expression "test.f2 << 16" to do sign extending of a 32 bit intermediate
result. But that is in fact what GCC produces, for x86_64-linux (gcc 4.7.0).
If I explicitly cast test.f2 to unsigned long long before the shift, the
expected result appears. But I shouldn't have to do that cast, given that the
type of f2 is already unsigned long long, correct?
paul
Re: Bug in bitfield handling?
On Sep 7, 2012, at 2:02 PM, Andrew Pinski wrote:
> On Fri, Sep 7, 2012 at 10:57 AM, wrote:
>> This seems to be a bug:
>>
>> struct bug
>> {
>>int f1:1;
>>unsigned long long f2:31;
>> };
>>
>> struct bug test = { 1, 0x8000ULL };
>>
>> int main (int c, char **v)
>> {
>>unsigned long long tf2;
>>
>>tf2 = test.f2 << 16;
>>if (tf2 == 0x8000ULL)
>>return 0;
>>return 1;
>> }
>>
>> Since the underlying type of field f2 is unsigned long long, I would not
>> expect the expression "test.f2 << 16" to do sign extending of a 32 bit
>> intermediate result. But that is in fact what GCC produces, for
>> x86_64-linux (gcc 4.7.0).
>>
>> If I explicitly cast test.f2 to unsigned long long before the shift, the
>> expected result appears. But I shouldn't have to do that cast, given that
>> the type of f2 is already unsigned long long, correct?
>
> The type of "test.f2" is a 31 bit unsigned integer (the declared type
> is used for alignment) and that fits in a 32bit signed integer so when
> doing test.f2 << 16, it is promoted to only an 32bit signed integer.
>
> Thanks,
> Andrew
Ok, thanks.
GDB doesn't do things this way, so I guess I have to tell them.
paul
Re: GCC 4.7.2 error handling type short
On Nov 26, 2012, at 3:57 PM, Bill Beech (NJ7P) wrote: > I have run into a problem with both 4.6.1 and 4.7.2 of the gcc compiler > handling type short. Sizeof(unsigned short) returns a length of 2 as > expected, but when I use a union of a character buffer and some fields > including a unsigned short the value returned is 2 bytes but the buffer > pointer is moved 4 bytes. > ... > As you can see the value at 0410 in the file, 6601 is returned as 358, which > is correct. The 4-byte > value following 67 01 00 00 is not returned for the unsigned int but rather > 00 00 30 00 is returned next (which equals 3145728 decimal). While a > sizeof(unsigned short) returns 2 bytes, in this case the pointer into the > unioned buffer is moved 4 bytes. > > This bug makes it hell to you any of your products to build emulators for the > 16-bit processors. > > Is there a definition for a 16-bit quantity that will work in a union? > > Thanks! > > Bill Beech > NJ7P You meant struct, right, not union? Every field has a size as well as an alignment. The starting address of each field is forced to be a multiple of its alignment. In many cases, for primitive data types (like the various size integers) the alignment equals the size; for example, a 4-byte int has alignment 4. So if you have a struct of short then int, the compiler has to insert 2 bytes of padding before the int to obey the alignment. In some cases, there are types that don't have alignment == sizeof, for example long long int on Intel is size 8 but (by default) alignment 4. Since you mentioned 16-bit processors -- are you talking about a port for a 16-bit processor, where you want int (size 4) to be aligned 2? (For example, that would be sensible on a PDP-11.) If so, you'd want to tell the compiler how to do that; I'm not sure of the details, presumably they are in the GCC Internals manual. Or are you talking about an existing port which has defined the alignment of int to be 4? If so, that might be because unaligned accesses would cause exceptions. Or it may just be a convention. In either case, you can use the "packed" attribute to override the normal alignment of fields. See the GCC documentation for details. paul
Re: Use of templates in c code?
On Feb 13, 2013, at 5:04 PM, Diego Novillo wrote: > ... > Ah, so if we rename a file with 'svn rename', its history will be > preserved across the rename? In that case, renaming files should not > be a problem. Yes, that's one of many ways that SVN (or most other source control systems) are superior over CVS. paul
Re: 32 bit pointers on a 64 bit system
On Mar 6, 2013, at 7:38 AM, David McQuillan wrote: > Have there been any implementations of gcc for a 32 bit pointer system where > the registers are 64 bits long? MIPS (N32 ABI, and if you want, also O64) is another example. paul
