Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Paul_Koning]

> 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: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Paul_Koning]

> 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: Machine constraints list

[Paul_Koning]

> 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: An abridged "Writing C" for the gcc web pages

[Paul_Koning]

> On Apr 22, 2016, at 12:21 PM, Bernd Schmidt  wrote:
> 
> (Apologies if you get this twice, the mailing list didn't like the html 
> attachment in the first attempt).
> 
> We frequently get malformatted patches, and it's been brought to my attention 
> that some people don't even make the effort to read the GNU coding standards 
> before trying to contribute code. TL;DR seems to be the excuse, and while I 
> find that attitude inappropriate, we could probably improve the situation by 
> spelling out the most basic rules in an abridged document on our webpages. 
> Below is a draft I came up with. Thoughts?

Would you expect people to conform to the abridged version or the full 
standard?  If the full standard, then publishing an abridged version is not a 
good idea, it will just cause confusion.  Let the full standard be the rule, 
make people read it, and if they didn't bother that's their problem.

paul

Re: Spurious register spill with volatile function argument

[Paul_Koning]

> 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 >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: Is test case with 700k lines of code a valid test case?

[Paul_Koning]

> 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: Is test case with 700k lines of code a valid test case?

[Paul_Koning]

> 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?

[Paul_Koning]

> 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: __builtin_memcpy and alignment assumptions

[Paul_Koning]

> 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: basic asm and memory clobbers - Proposed solution

[Paul_Koning]

> 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

[Paul_Koning]

> 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: basic asm and memory clobbers - Proposed solution

[Paul_Koning]

> 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

[Paul_Koning]

> 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

[Paul_Koning]

> 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

[Paul_Koning]

> 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: C++ order of evaluation of operands, arguments

[Paul_Koning]

> 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

[Paul_Koning]

> 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

[Paul_Koning]

> 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: basic asm and memory clobbers

[Paul_Koning]

> 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

[Paul_Koning]

> 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

[Paul_Koning]

> 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: Git conversion: disposition of old branches and tags

[Paul_Koning]

> 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: Compiler support for erasure of sensitive data

[Paul_Koning]

> 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

[Paul_Koning]

> 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: Moving to git

[Paul_Koning]

 On Aug 20, 2015, at 4:09 PM, Jason Merrill ja...@redhat.com 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

[Paul_Koning]

 On Aug 20, 2015, at 4:24 PM, Jason Merrill ja...@redhat.com 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: Is there a way to adjust alignment of DImode and DFmode?

[Paul_Koning]

 On May 20, 2015, at 1:00 PM, H.J. Lu hjl.to...@gmail.com 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?

[Paul_Koning]

 On May 20, 2015, at 1:22 PM, Jakub Jelinek ja...@redhat.com 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 hjl.to...@gmail.com 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: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

[Paul_Koning]

From: gcc-patches-ow...@gcc.gnu.org [gcc-patches-ow...@gcc.gnu.org] on behalf 
of H.J. Lu [hjl.to...@gmail.com]
Sent: Tuesday, May 19, 2015 11:27 AM
To: Joseph Myers
Cc: Magnus Granberg; GCC Patches
Subject: Re: PING^3: [PATCH]: New configure options that make the compiler use 
-fPIE and -pie as default option

On Tue, May 19, 2015 at 8:21 AM, Joseph Myers jos...@codesourcery.com wrote:
 ...
 I think the whole thing should be posted as one patch, with both the
 target-independent changes and the target-specific changes for all
 targets.


That is what makes me concerned.  I have some simple target-specified
patches which weren't reviewed for years. What will happen if no one
reviews some simple target-specified changes due to

1. Reviewers don't have access to those targets.
2. Target maintainers aren't review them.
3. There are no clear maintainers for those targets.

As the result, my patch may go nowhere.
---

But that hasn't stopped others from posting patches like that, or getting them 
approved.  And we also have global maintainers who can approve things.  It 
feels a bit like a hypothetical issue is being used as a reason to do part of 
the job.


paul

Re: Questions about C as used/implemented in practice

[Paul_Koning]

 On Apr 17, 2015, at 9:14 AM, Peter Sewell peter.sew...@cl.cam.ac.uk 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: inline asm clobbers

[Paul_Koning]

 On Mar 11, 2015, at 8:53 PM, David Wohlferd d...@limegreensocks.com 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: inline asm clobbers

[Paul_Koning]

 On Mar 11, 2015, at 7:19 PM, Ian Lance Taylor i...@google.com wrote:
 
 On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd d...@limegreensocks.com 
 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: Obscure crashes due to gcc 4.9 -O2 = -fisolate-erroneous-paths-dereference

[Paul_Koning]

 On Feb 20, 2015, at 12:01 PM, Jeff Law l...@redhat.com 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

[Paul_Koning]

 On Feb 20, 2015, at 12:01 PM, Jeff Law l...@redhat.com 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: Android native build of GCC

[Paul_Koning]

 On Feb 6, 2015, at 5:28 AM, Andrew Haley a...@redhat.com 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: Branch taken rate of Linux kernel compiled with GCC 4.9

[Paul_Koning]

 On Jan 13, 2015, at 7:44 AM, Alexander Monakov amona...@ispras.ru 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: volatile access optimization (C++ / x86_64)

[Paul_Koning]

 On Jan 5, 2015, at 4:11 PM, DJ Delorie d...@redhat.com 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: volatile access optimization (C++ / x86_64)

[Paul_Koning]

 On Jan 5, 2015, at 1:47 PM, DJ Delorie d...@redhat.com 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

[Paul_Koning]

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)

[Paul_Koning]

 On Jan 5, 2015, at 1:24 PM, DJ Delorie d...@redhat.com 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)

[Paul_Koning]

 On Dec 30, 2014, at 1:32 PM, Matt Godbolt m...@godbolt.org wrote:
 
 On Tue, Dec 30, 2014 at 5:05 AM, Torvald Riegel trie...@redhat.com 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: Bootstrap failure on Mac OS Yosemite (10.10)

[Paul_Koning]

 On Dec 29, 2014, at 2:01 PM, paul_kon...@dell.com paul_kon...@dell.com 
 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)

[Paul_Koning]

 On Dec 26, 2014, at 6:19 PM, Andrew Haley a...@redhat.com wrote:
 
 On 26/12/14 22:49, Matt Godbolt wrote:
 On Fri, Dec 26, 2014 at 4:26 PM, Andrew Haley a...@redhat.com 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)

[Paul_Koning]

 On Dec 27, 2014, at 1:40 PM, Andrew Haley a...@redhat.com wrote:
 
 On 27/12/14 18:04, Matt Godbolt wrote:
 On Sat, Dec 27, 2014 at 11:57 AM, Andrew Haley a...@redhat.com 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

Re: Problems with gcc-bugs

[Paul_Koning]

On Sep 29, 2014, at 7:59 PM, George R Goffe grgo...@yahoo.com 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: Remove LIBGCC2_HAS_?F_MODE target macros

[Paul_Koning]

On Sep 11, 2014, at 9:22 PM, Joseph S. Myers jos...@codesourcery.com wrote:

 This patch removes the LIBGCC2_HAS_{SF,DF,XF,TF}_MODE target macros,
 replacing them by predefines with -fbuilding-libgcc, together with a
 target hook that can influence those predefines when needed.
 
 The new default is that a floating-point mode is supported in libgcc
 if (a) it passes the scalar_mode_supported_p hook (otherwise it's not
 plausible for it to be supported in libgcc) and (b) it's one of those
 four modes (since those are the modes for which libgcc hardcodes the
 possibility of support).  The target hook can override the default
 choice (in either direction) for modes that pass
 scalar_mode_supported_p (although overriding in the direction of
 returning true when the default would return false only makes sense if
 all relevant functions are specially defined in libgcc for that
 particular target).
 
 The previous default settings depended on various settings such as
 LIBGCC2_LONG_DOUBLE_TYPE_SIZE, as well as targets defining the above
 target macros if the default wasn't correct.
 
 The default scalar_mode_supported_p only declares a floating-point
 mode to be supported if it matches one of float / double / long
 double.  This means that in most cases where a mode is only supported
 conditionally in libgcc (TFmode only supported if it's the mode of
 long double, most commonly), the default gets things right.  Overrides
 were needed in the following cases:
 
 * SFmode would always have been supported in libgcc (the condition was
  BITS_PER_UNIT == 8, true for all current targets), but pdp11
  defaults to 64-bit float, and in that case SFmode would fail
  scalar_mode_supported_p.  I don't know if libgcc actually built for
  pdp11 (and the port may well no longer be being used), but this
  patch adds a scalar_mode_supported_p hook to it to ensure SFmode is
  treated as supported.

I thought it does build.  I continue to work to keep that port alive.

The change looks fine.

The ideal solution, I think, would be to handle the choice of float length that 
the pdp11 target has via the multilib machinery.  Currently it does not do 
that.  If multilib were added for that at some point, would that require a 
change of the code in that hook?

paul

Re: ViewVC is broken on your web site

[Paul_Koning]

On Aug 6, 2014, at 2:38 PM, David Gero david.g...@exfo.com 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

[Paul_Koning]

On Aug 6, 2014, at 2:59 PM, Paolo Carlini paolo.carl...@oracle.com wrote:

 Hi,
 
 On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote:
 On Aug 6, 2014, at 2:38 PM, David Gero david.g...@exfo.com 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: [PATCH 8/8] Add a common .md file and define standard constraints there

[Paul_Koning]

On Jun 12, 2014, at 3:24 PM, Segher Boessenkool seg...@kernel.crashing.org 
wrote:

 On Thu, Jun 05, 2014 at 10:43:25PM +0100, Richard Sandiford wrote:
 This final patch uses a common .md file to define all standard
 constraints except 'g'.
 
 I had a look at what targets still use g.  Note: there can be
 errors in this, it's all based on  \g[,]  :-)
 
 * frv and mcore use g in commented-out patterns;
 * cr16, mcore, picochip, rl78, and sh use g where they mean rm
  or m;
 * m68k uses it (in a dbne pattern) where the C template splits
  the r, m, i cases again;
 * bfin, fr30, h8300, m68k, rs6000, and v850 use it as the second
  operand (# bytes pushed) of the call patterns; that operand is
  unused in all these cases, could just be ;
 * cris, m68k, pdp11, and vax actually use g.
 
 So it won't be all that much work to completely get rid of g.
 Do we want that?

Is it simply a matter of replacing “g” by “mri”?  That’s what the doc suggests. 
 Or is there more to the story than that?

paul

Re: soft-fp functions support without using libgcc

[Paul_Koning]

On May 16, 2014, at 12:25 PM, Ian Bolton ian.bol...@arm.com wrote:

 On Fri, May 16, 2014 at 6:34 AM, Sheheryar Zahoor Qazi
 sheheryar.zahoor.q...@gmail.com 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: Builtin: stack pointer

[Paul_Koning]

On Mar 27, 2014, at 6:38 AM, Renato Golin renato.go...@linaro.org wrote:

 On 27 March 2014 10:29, Andreas Schwab sch...@suse.de 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: linux says it is a bug

[Paul_Koning]

On Mar 5, 2014, at 10:07 AM, Richard Henderson r...@redhat.com 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: linux says it is a bug

[Paul_Koning]

On Mar 4, 2014, at 2:30 PM, Richard Henderson r...@redhat.com 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: [Patch, RTL] Eliminate redundant vec_select moves.

[Paul_Koning]

On Dec 10, 2013, at 9:50 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote:

 Hello,
 On 09 Dec 14:08, H.J. Lu wrote:
 There are no regressions on Linux/x86-64 with -m32 and -m64.
 Can you check if it improves code quality on x886?
 
 That is exactly what I was talking about. However I wasn't sure
 that we can change already defined (and used throughout ports)
 target hook.
 
 ...
 
 Attached patch + updated test.

You're missing the documentation change needed for this.

paul

Re: [Patch, RTL] Eliminate redundant vec_select moves.

[Paul_Koning]

On Dec 10, 2013, at 2:12 PM, H.J. Lu hjl.to...@gmail.com wrote:

 On Tue, Dec 10, 2013 at 11:05 AM, Tejas Belagod tbela...@arm.com wrote:
 ...
 So, if (subreg:DI (match_operand:V4SF 1 register_operand x,x) 0) is a
 valid subreg, why not allow it in CANNOT_CHANGE_MODE_CLASS (like in Kirill's
 patch http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00987.html) and resolve
 the actual register later in subreg_get_info ()?
 
 Let's wait for Kirill's results on GCC testsuite.

I'm puzzled.  What is the connection between testsuite results and a design 
decision about a code change?  The question remains valid even if the testsuite 
didn't exist at all.

paul

Re: Make SImode as default mode for INT type.

[Paul_Koning]

On Dec 6, 2013, at 5:40 AM, Umesh Kalappa umesh.kalap...@gmail.com 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: Turn most genrecog warnings into errors

[Paul_Koning]

On Nov 22, 2013, at 3:43 AM, Richard Sandiford rdsandif...@googlemail.com 
wrote:

 genrecog does some useful sanity checks on the .md files.  At the moment
 it only reports most of the problems as warnings though, which means you
 won't notice them unless you specifically look.
 
 I think the only message in validate_pattern that deserves to be a
 warning is the one about missing modes, since the current code does
 warn about valid cases.  It would be good to tighten that up at some
 point, but not today.
 
 Tested by building cc1 with and without the warning for each backend
 (picking an arbitrary configuration triple in each case).  The patch
 below updates backends for which the fix was truly obvious:
 removing constraints from things that don't allow constraints,
 replacing one target-independent predicate with another that
 doesn't accept immediates, or using match_operand rather than
 match_test to test subpredicates.  I've posted separate patches
 for the backends that need changing in other ways.
 
 Also tested in the normal way on x86_64-linux-gnu.  OK to install?
 
 Thanks,
 Richard
 
 
 gcc/
   * genrecog.c (validate_pattern): Treat all messages except missing
   modes as errors.
   * config/epiphany/epiphany.md: Remove constraints from
   define_peephole2s.
   * config/h8300/h8300.md: Remove constraints from define_splits.
   * config/msp430/msp430.md: Likewise.
   * config/mcore/mcore.md (movdi_i, movsf_i, movdf_k): Use
   nonimmediate_operand rather than general_operand for operand 0.
   * config/moxie/moxie.md (*movsi, *movqi, *movhi): Likewise.
   * config/pdp11/predicates.md (float_operand, float_nonimm_operand):
   Use match_operator rather than match_test to invoke general_operand.
   * config/v850/v850.md (*movqi_internal, *movhi_internal)
   (*movsi_internal_v850e, *movsi_internal, *movsf_internal): Likewise.

I think you meant use match_operand rather than ... (in 
config/pdp11/predicates.md).

paul

Re: GCC retargeting

[Paul_Koning]

On Oct 9, 2013, at 5:24 AM, Umesh Kalappa umesh.kalap...@gmail.com 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: Automated Toolchain Building and Testing

[Paul_Koning]

On Aug 28, 2013, at 8:52 PM, Samuel Mi samuel.mi...@gmail.com wrote:

 On Thu, Aug 29, 2013 at 2:54 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
 On Thu, 2013-08-29 02:43:54 +0800, Samuel Mi samuel.mi...@gmail.com 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: Should -Wmaybe-uninitialized be included in -Wall?

[Paul_Koning]

On Jul 10, 2013, at 10:42 AM, Andi Kleen wrote:

 Andrew Haley a...@redhat.com 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?

[Paul_Koning]

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: 32 bit pointers on a 64 bit system

[Paul_Koning]

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

Re: Use of templates in c code?

[Paul_Koning]

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: GCC 4.7.2 error handling type short

[Paul_Koning]

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

[Bug debug/55063] [4.8 Regression] Thousands of failures in the libstdc++-v3 tests after revision 192739

[paul_koning at dell dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55063



Paul Koning paul_koning at dell dot com changed:



   What|Removed |Added



 CC||paul_koning at dell dot com



--- Comment #6 from Paul Koning paul_koning at dell dot com 2012-10-25 
18:15:23 UTC ---

This looks like my misunderstanding of what add_AT_flag does.   I assumed it

turns on a flag in a set of flags, but it actually adds a flag record to a list

of records.  What appears to be needed is a check that the flag is not already

present, and add one only in that case.



I'll work up a patch.

[Bug debug/54508] Wrong debug information emitted if data members not referenced

[paul_koning at dell dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508



Paul Koning paul_koning at dell dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #5 from Paul Koning paul_koning at dell dot com 2012-10-23 
18:53:28 UTC ---

Fixed in trunk.

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 5, 2012, at 6:05 PM, Cary Coutant wrote:

 There certainly is a fair amount of code in dwarf2read.c in gdb to handle 
 DW_AT_declaration and do things differently for declarations.
 
 Should I rework this patch to use that mechanism instead?  If so, how?  If 
 the class is marked only by prune_unused_types_mark visiting it as a parent, 
 but hasn't been marked by ??? that visits all its children, then emit it 
 with a DW_AT_declaration marking?
 
 One question I'd consider is what do you want to see in the debugger
 if this truly is the only debug info you have for the class? (For
 example, in the test case you added, a DW_AT_declaration attribute
 won't help if there's no full definition of the class anywhere else.)
 Is it reasonable to just show a truncated class definition in that
 case, or do you want the full definition available. My tentative
 answer would be that we do the pruning here because we expect there to
 be a full definition somewhere else, and that the lack of a
 DW_AT_declaration attribute is the bug.

The answer appears to be:
1. Until the full symbols have been read (via gdb -r, or by reference to 
another symbol in that compilation unit) such declarations are not visible.  
Once the full symbols have been read, a class marked as DW_AT_declaration is 
shown as imcomplete type which makes sense.

I think this is reasonable behavior.  I confirmed that if you do have a 
definition elsewhere, gdb does the correct thing.  That's what you would 
expect, given that the DW_AT_declaration flag was already being generated (for 
imcomplete types).
 
 As you've discovered, however, it's not straightforward. You'll want
 to add the declaration attribute if you mark the DIE from below, but
 not from any reference where dokids is true. Alternatively, add the
 declaration attribute if any of its children are pruned. Perhaps that
 could be done in prune_unused_types_prune().
 
 If you're willing to rework the patch this way (assuming GDB does the
 right thing with it), I think that would be better. Thanks.
 
 -cary

Attached is the revised patch.  It marks classes as declaration if they 
weren't marked by one of the mark functions that visits children, and something 
was actually pruned.  That second check is needed, otherwise the class 
Executor in testcase nested-3.C gets marked as a declaration.

The testcase has been reworked to check both aspects.  Struct s gets defined 
(because a variable of that type is defined), while class c and union u are 
not, so they are marked as declaration while struct s is not marked.  The 
testcase verifies that.

Tested by build and check RUNTESTFLAGS=dwarf2.exp on Linux and Darwin.  Ok to 
commit?

paul

ChangeLog:

2012-10-23  Paul Koning  n...@arrl.net

* dwarf2out.c (prune_unused_types_prune): If pruning a class and
not all its children were marked, add DW_AT_declaration flag.

testcases/ChangeLog:

2012-10-23  Paul Koning  n...@arrl.net

* g++.dg/debug/dwarf2/pr54508.C: New.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 192405)
+++ gcc/dwarf2out.c (working copy)
@@ -21218,6 +21218,7 @@
 prune_unused_types_prune (dw_die_ref die)
 {
   dw_die_ref c;
+  int pruned = 0;
 
   gcc_assert (die-die_mark);
   prune_unused_types_update_strings (die);
@@ -21240,13 +21241,24 @@
  prev-die_sib = c-die_sib;
  die-die_child = prev;
}
- return;
+ pruned = 1;
+ goto finished;
}
 
 if (c != prev-die_sib)
-  prev-die_sib = c;
+  {
+   prev-die_sib = c;
+   pruned = 1;
+  }
 prune_unused_types_prune (c);
   } while (c != die-die_child);
+
+ finished:
+  /* If we pruned children, and this is a class, mark it as a 
+ declaration to inform debuggers that this is not a complete
+ class definition.  */
+  if (pruned  die-die_mark == 1  class_scope_p (die))
+add_AT_flag (die, DW_AT_declaration, 1);
 }
 
 /* Remove dies representing declarations that we never use.  */

Index: gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C
===
--- gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
+++ gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
@@ -0,0 +1,72 @@
+// PR debug/54508
+// { dg-do compile }
+// { dg-options -g2 -dA -fno-merge-debug-strings }
+
+// { dg-final { scan-assembler-not \cbase0\\[ \t\]+\[#;/!|@\]+ 
DW_AT_name } }
+// { dg-final { scan-assembler \c0\\[ \t\]+\[#;/!|@\]+ 
DW_AT_name\[\r\n\]+\[\^\r\n\]+\[\r\n\]+\[\^\r\n\]+\[\r\n\]+\[\^#;/!|@\]+\[#;/!|@\]+
 DW_AT_decl_line\[\r\n\]+\[\^#;/!|@\]+\[#;/!|@\]+ DW_AT_declaration } }
+// { dg-final { scan-assembler-not \OPCODE0\\[ \t\]+\[#;/!|@\]+ 
DW_AT_name } }
+// { dg-final { scan-assembler-not \bi0\\[ \t\]+\[#;/!|@\]+ DW_AT_name 
} }
+// { dg-final { scan-assembler-not \si0\\[ \t\]+\[#;/!|@\]+ DW_AT_name 
} }
+// { 

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 23, 2012, at 2:02 PM, Jason Merrill wrote:

 OK.
 
 Jason

Thanks.  Committed.

paul

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 5, 2012, at 4:16 AM, Jakub Jelinek wrote:

 On Thu, Oct 04, 2012 at 05:26:11PM -0700, Cary Coutant wrote:
 Index: gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C
 ===
 --- gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (revision 192048)
 +++ gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (working copy)
 @@ -59,11 +59,11 @@
 // { dg-final { scan-assembler foo\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn2\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not staticfn3\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not staticfn4\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler staticfn3\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler staticfn4\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn5\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn6\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not method1\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler method1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg2\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg3\[^\n\r\]*DW_AT_name } }
 
 The fact that these two tests were specifically checking for the
 absence of staticfn3 and staticfn4 leads me to believe that the
 current behavior is deliberate. Jakub, that change was yours (it dates
 back to November 2008). Are you OK with Paul's change?
 
 Yes, thought it would be interesting to get some .debug_info size growth
 numbers for a few projects (say libstdc++.so and some larger C++ codebase
 (some KDE core library, or OO.o) without/with the patch, to see how much
 does it bring with it (I'm not that much worried about the DW_TAG_subprogram
 added itself, but about about types it will additionally bring in).
 We have dwz and likely would get most of the growth back due to redundancy
 removal though.
 
   Jakub

I did a quick test on a large application of ours where this issue was causing 
trouble.  Without the patch, it generates 115 MB of debug data; with the patch, 
that grows to 120 MB.

paul

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 5, 2012, at 11:34 AM, paul_kon...@dell.com
 paul_kon...@dell.com wrote:

 
 On Oct 5, 2012, at 4:16 AM, Jakub Jelinek wrote:
 
 On Thu, Oct 04, 2012 at 05:26:11PM -0700, Cary Coutant wrote:
 Index: gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C
 ===
 --- gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (revision 192048)
 +++ gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (working copy)
 @@ -59,11 +59,11 @@
 // { dg-final { scan-assembler foo\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn2\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not staticfn3\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not staticfn4\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler staticfn3\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler staticfn4\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn5\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn6\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not method1\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler method1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg2\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg3\[^\n\r\]*DW_AT_name } }
 
 The fact that these two tests were specifically checking for the
 absence of staticfn3 and staticfn4 leads me to believe that the
 current behavior is deliberate. Jakub, that change was yours (it dates
 back to November 2008). Are you OK with Paul's change?
 
 Yes, thought it would be interesting to get some .debug_info size growth
 numbers for a few projects (say libstdc++.so and some larger C++ codebase
 (some KDE core library, or OO.o) without/with the patch, to see how much
 does it bring with it (I'm not that much worried about the DW_TAG_subprogram
 added itself, but about about types it will additionally bring in).
 We have dwz and likely would get most of the growth back due to redundancy
 removal though.
 
  Jakub
 
 I did a quick test on a large application of ours where this issue was 
 causing trouble.  Without the patch, it generates 115 MB of debug data; with 
 the patch, that grows to 120 MB.

So given the comments, is this patch now ok to commit?

Thanks,
paul

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 5, 2012, at 2:43 PM, Cary Coutant wrote:

 It seems to me that there are cases where we just want to emit the
 class for the context info (like a namespace, which doesn't have to be
 complete everywhere). Is there a way to tell the debugger that this
 class declaration is incomplete and that it should look elsewhere for
 a full definition?
 
 I think DW_AT_declaration would be appropriate.
 
 Yeah, that's what I was thinking. I was going to check with dje to see
 if GDB would do the right thing in that case.
 
 -cary

Does that mean I should hold off committing this change?

paul

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 5, 2012, at 2:43 PM, Cary Coutant wrote:

 It seems to me that there are cases where we just want to emit the
 class for the context info (like a namespace, which doesn't have to be
 complete everywhere). Is there a way to tell the debugger that this
 class declaration is incomplete and that it should look elsewhere for
 a full definition?
 
 I think DW_AT_declaration would be appropriate.
 
 Yeah, that's what I was thinking. I was going to check with dje to see
 if GDB would do the right thing in that case.
 
 -cary

There certainly is a fair amount of code in dwarf2read.c in gdb to handle 
DW_AT_declaration and do things differently for declarations.

Should I rework this patch to use that mechanism instead?  If so, how?  If the 
class is marked only by prune_unused_types_mark visiting it as a parent, but 
hasn't been marked by ??? that visits all its children, then emit it with a 
DW_AT_declaration marking?

paul

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 5, 2012, at 6:05 PM, Cary Coutant wrote:

 There certainly is a fair amount of code in dwarf2read.c in gdb to handle 
 DW_AT_declaration and do things differently for declarations.
 
 Should I rework this patch to use that mechanism instead?  If so, how?  If 
 the class is marked only by prune_unused_types_mark visiting it as a parent, 
 but hasn't been marked by ??? that visits all its children, then emit it 
 with a DW_AT_declaration marking?
 
 One question I'd consider is what do you want to see in the debugger
 if this truly is the only debug info you have for the class? (For
 example, in the test case you added, a DW_AT_declaration attribute
 won't help if there's no full definition of the class anywhere else.)
 Is it reasonable to just show a truncated class definition in that
 case, or do you want the full definition available. My tentative
 answer would be that we do the pruning here because we expect there to
 be a full definition somewhere else, and that the lack of a
 DW_AT_declaration attribute is the bug.
 
 As you've discovered, however, it's not straightforward. You'll want
 to add the declaration attribute if you mark the DIE from below, but
 not from any reference where dokids is true. Alternatively, add the
 declaration attribute if any of its children are pruned. Perhaps that
 could be done in prune_unused_types_prune().
 
 If you're willing to rework the patch this way (assuming GDB does the
 right thing with it), I think that would be better. Thanks.
 
 -cary

I'll give it a try.  I'll keep the existing patch in reserve in case we run out 
of time before Phase 1 end -- it would be good to have some sort of fix for 
this bug even if it's not the ideal one.

paul

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 4, 2012, at 1:38 PM, Cary Coutant wrote:

  /* We also have to mark its parents as used.
 -(But we don't want to mark our parents' kids due to this.)  */
 +(But we don't want to mark our parent's kids due to this,
 +unless it is a class.)  */
  if (die-die_parent)
 -   prune_unused_types_mark (die-die_parent, 0);
 +   prune_unused_types_mark (die-die_parent,
 +(die-die_parent-die_tag == 
 DW_TAG_class_type ||
 + die-die_parent-die_tag == 
 DW_TAG_structure_type ||
 + die-die_parent-die_tag == 
 DW_TAG_union_type));
 
 I'd suggest replacing these conditions with a call to class_scope_p().
 That will also cover DW_TAG_interface_type, which might be irrelevant
 for this particular case, but is probably good to cover in the general
 case.
 
 -cary

Thanks, that makes it very simple.  Here is the updated patch.

Ok to commit with this change?

paul

ChangeLog:

2012-10-04  Paul Koning  n...@arrl.net

* dwarf2out.c (prune_unused_types_mark): Mark all of parent's
children if parent is a class.

testsuite/ChangeLog:

2012-10-04  Paul Koning  n...@arrl.net

* g++.dg/debug/dwarf2/pr54508.C: New.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 192048)
+++ gcc/dwarf2out.c (working copy)
@@ -21035,9 +21035,11 @@
   prune_unused_types_mark_generic_parms_dies (die);
 
   /* We also have to mark its parents as used.
-(But we don't want to mark our parents' kids due to this.)  */
+(But we don't want to mark our parent's kids due to this,
+unless it is a class.)  */
   if (die-die_parent)
-   prune_unused_types_mark (die-die_parent, 0);
+   prune_unused_types_mark (die-die_parent, 
+class_scope_p (die-die_parent));
 
   /* Mark any referenced nodes.  */
   prune_unused_types_walk_attribs (die);
Index: testsuite/g++.dg/debug/dwarf2/pr54508.C
===
--- testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
+++ testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
@@ -0,0 +1,67 @@
+// PR debug/54508
+// { dg-do compile }
+// { dg-options -g2 -dA }
+
+// { dg-final { scan-assembler \cbase0\\[ \t\]+\[#;/!|@\]+ 
DW_AT_name\|DW_AT_name: \cbase\ } }
+// { dg-final { scan-assembler \OPCODE0\\[ \t\]+\[#;/!|@\]+ 
DW_AT_name\|DW_AT_name: \OPCODE\ } }
+// { dg-final { scan-assembler \bi0\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
+// { dg-final { scan-assembler \si0\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
+// { dg-final { scan-assembler \f10\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
+// { dg-final { scan-assembler \f20\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
+// { dg-final { scan-assembler-not \nc0\\[ \t\]+\# 
DW_AT_name\|DW_AT_name: \nc\ } }
+
+class cbase
+
+{
+public:
+ static int si;
+int bi;
+};
+
+class c : public cbase
+
+{
+public:
+ enum
+ {
+  OPCODE = 251
+ };
+ int i ;
+ static const char *testc (void) { return foo; }
+};
+
+struct s
+{
+int f1;
+static const char *tests (void) { return test; }
+};
+
+union u
+{
+int f2;
+double d;
+static const char *testu (void) { return test union; }
+};
+
+namespace n 
+{
+const char *ntest (void) { return test n; }
+
+class nc
+{
+public:
+int i;
+static int sj;
+};
+}
+
+extern void send (int, int, const void *, int);
+
+void test (int src)
+{
+  int cookie = 1;
+  send(src, c::OPCODE, c::testc (), cookie);
+  send(src, c::OPCODE, s::tests (), cookie);
+  send(src, c::OPCODE, u::testu (), cookie);
+  send(src, c::OPCODE, n::ntest (), cookie);
+}

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

Updated patch: there were two existing testcases that needed to be adjusted 
because of this fix.

Ran check RUNTESTFLAGS=dwarf2.exp, no regressions.

paul

ChangeLog:

2012-10-04  Paul Koning  n...@arrl.net

* dwarf2out.c (prune_unused_types_mark): Mark all of parent's
children if parent is a class.

testsuite/ChangeLog:

2012-10-04  Paul Koning  n...@arrl.net

* g++.dg/debug/dwarf2/pr54508.C: New.
* g++.dg/debug/dwarf2/localclass1.C: Expect staticfn1, staticfn2,
method1 in debug output.
* g++.dg/debug/dwarf2/localclass2.C: Likewise.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 192048)
+++ gcc/dwarf2out.c (working copy)
@@ -21035,9 +21035,11 @@
 prune_unused_types_mark_generic_parms_dies (die);

 /* We also have to mark its parents as used.
-(But we don't want to mark our parents' kids due to this.)  */
+(But we don't want to mark our parent's kids due to this,
+unless it is a class.)  */
 if (die-die_parent)
-   prune_unused_types_mark (die-die_parent, 0);
+   prune_unused_types_mark (die-die_parent, 
+class_scope_p (die-die_parent));

 /* Mark any referenced nodes.  */
 prune_unused_types_walk_attribs (die);
Index: gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C
===
--- gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
+++ gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
@@ -0,0 +1,67 @@
+// PR debug/54508
+// { dg-do compile }
+// { dg-options -g2 -dA -fno-merge-debug-strings }
+
+// { dg-final { scan-assembler \cbase0\\[ \t\]+\[#;/!|@\]+ DW_AT_name 
} }
+// { dg-final { scan-assembler \OPCODE0\\[ \t\]+\[#;/!|@\]+ DW_AT_name 
} }
+// { dg-final { scan-assembler \bi0\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
+// { dg-final { scan-assembler \si0\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
+// { dg-final { scan-assembler \f10\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
+// { dg-final { scan-assembler \f20\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
+// { dg-final { scan-assembler-not \nc0\\[ \t\]+\# DW_AT_name } }
+
+class cbase
+
+{
+public:
+ static int si;
+int bi;
+};
+
+class c : public cbase
+
+{
+public:
+ enum
+ {
+  OPCODE = 251
+ };
+ int i ;
+ static const char *testc (void) { return foo; }
+};
+
+struct s
+{
+int f1;
+static const char *tests (void) { return test; }
+};
+
+union u
+{
+int f2;
+double d;
+static const char *testu (void) { return test union; }
+};
+
+namespace n 
+{
+const char *ntest (void) { return test n; }
+
+class nc
+{
+public:
+int i;
+static int sj;
+};
+}
+
+extern void send (int, int, const void *, int);
+
+void test (int src)
+{
+  int cookie = 1;
+  send(src, c::OPCODE, c::testc (), cookie);
+  send(src, c::OPCODE, s::tests (), cookie);
+  send(src, c::OPCODE, u::testu (), cookie);
+  send(src, c::OPCODE, n::ntest (), cookie);
+}
Index: gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C
===
--- gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (revision 192048)
+++ gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (working copy)
@@ -59,11 +59,11 @@
 // { dg-final { scan-assembler foo\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn2\[^\n\r\]*DW_AT_name } }
-// { dg-final { scan-assembler-not staticfn3\[^\n\r\]*DW_AT_name } }
-// { dg-final { scan-assembler-not staticfn4\[^\n\r\]*DW_AT_name } }
+// { dg-final { scan-assembler staticfn3\[^\n\r\]*DW_AT_name } }
+// { dg-final { scan-assembler staticfn4\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn5\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn6\[^\n\r\]*DW_AT_name } }
-// { dg-final { scan-assembler-not method1\[^\n\r\]*DW_AT_name } }
+// { dg-final { scan-assembler method1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg2\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg3\[^\n\r\]*DW_AT_name } }
Index: gcc/testsuite/g++.dg/debug/dwarf2/localclass2.C
===
--- gcc/testsuite/g++.dg/debug/dwarf2/localclass2.C (revision 192048)
+++ gcc/testsuite/g++.dg/debug/dwarf2/localclass2.C (working copy)
@@ -59,11 +59,11 @@
 // { dg-final { scan-assembler foo\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn2\[^\n\r\]*DW_AT_name } }
-// { dg-final { scan-assembler-not staticfn3\[^\n\r\]*DW_AT_name } }
-// { dg-final { scan-assembler-not staticfn4\[^\n\r\]*DW_AT_name } }
+// { dg-final { scan-assembler staticfn3\[^\n\r\]*DW_AT_name } }
+// { dg-final { scan-assembler 

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 4, 2012, at 8:26 PM, Cary Coutant wrote:

 Index: gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C
 ===
 --- gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (revision 192048)
 +++ gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (working copy)
 @@ -59,11 +59,11 @@
 // { dg-final { scan-assembler foo\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn2\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not staticfn3\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not staticfn4\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler staticfn3\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler staticfn4\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn5\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn6\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not method1\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler method1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg2\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg3\[^\n\r\]*DW_AT_name } }
 
 The fact that these two tests were specifically checking for the
 absence of staticfn3 and staticfn4 leads me to believe that the
 current behavior is deliberate. Jakub, that change was yours (it dates
 back to November 2008). Are you OK with Paul's change?
 
 It seems to me that there are cases where we just want to emit the
 class for the context info (like a namespace, which doesn't have to be
 complete everywhere). Is there a way to tell the debugger that this
 class declaration is incomplete and that it should look elsewhere for
 a full definition?
 
 -cary

Certainly GDB does not currently do that.  As it stands, it uses whatever 
definition it finds first, so depending on which compilation unit's symbols are 
read first, what you see varies unpredictably. If there is a way to express in 
Dwarf-2 the fact that this is an incomplete definition, GDB could presumably be 
changed to take advantage of that.  I have no idea how hard that is.

paul

Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

On Oct 4, 2012, at 8:26 PM, Cary Coutant wrote:

 Index: gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C
 ===
 --- gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (revision 192048)
 +++ gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (working copy)
 @@ -59,11 +59,11 @@
 // { dg-final { scan-assembler foo\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler staticfn2\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not staticfn3\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not staticfn4\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler staticfn3\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler staticfn4\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn5\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler-not staticfn6\[^\n\r\]*DW_AT_name } }
 -// { dg-final { scan-assembler-not method1\[^\n\r\]*DW_AT_name } }
 +// { dg-final { scan-assembler method1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg1\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg2\[^\n\r\]*DW_AT_name } }
 // { dg-final { scan-assembler arg3\[^\n\r\]*DW_AT_name } }
 
 The fact that these two tests were specifically checking for the
 absence of staticfn3 and staticfn4 leads me to believe that the
 current behavior is deliberate. Jakub, that change was yours (it dates
 back to November 2008). Are you OK with Paul's change?
 
 It seems to me that there are cases where we just want to emit the
 class for the context info (like a namespace, which doesn't have to be
 complete everywhere). Is there a way to tell the debugger that this
 class declaration is incomplete and that it should look elsewhere for
 a full definition?
 
 -cary

The code itself (where I changed dwarf2out.c) is from 2003-02-28, by rth, what 
appears to be the original implementation of the -feliminate-unused-debug-types 
flag.

Looking at Jakub's change from 2008 and PR/27017 it fixes, it looks more like a 
case of much more debug information that was missing and Jakub's change 
corrected that.  It looks like those two testcase files describe the resulting 
behavior, but I don't read the discussion in PR/27017 as saying that having 
staticfn3 omitted was specifically desired. 

paul

Re: RFC: LRA for x86/x86-64 [4/9]

[Paul_Koning]

On Oct 1, 2012, at 2:51 PM, Richard Sandiford wrote:

 ...
 E.g. for MIPS, SImode loads and stores have a displacement range of
 [-32768, 32764], but DImode loads and stores only accept [-32768, 32760].
 So the maximal displacement depends on mode, even though the instruction set
 is pretty regular.

It may be that the case doesn't arise in code GCC generates, but I don't think 
that's true.  The offset field is always a 2's complement 16 bit integer, hence 
in the range -32768..32767.  The alignment required in loading multibyte data 
with aligned load/store instructions applies to the final address, not the 
offset.  For example, if R1 contains 1, then LD r2,32767(r1) will work.

paul

Re: [PATCH v2, rtl-optimization]: Fix PR54457, [x32] Fail to combine 64bit index + constant

[Paul_Koning]

On Sep 27, 2012, at 2:04 PM, Uros Bizjak wrote:

 
 
 
 I agree (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C) is
 a good transformation, but why do we need to handle as special
 the case where the subreg is itself the operand of a plus or minus?
 I think it should happen regardless of where the subreg occurs.
 
 Don't we need to restrict this to the low part though?
 
 ...
 
 After some off-line discussion with Richard, attached is v2 of the patch.
 
 2012-09-27  Uros Bizjak  ubiz...@gmail.com
 
PR rtl-optimization/54457
* simplify-rtx.c (simplify_subreg):
   Simplify (subreg:SI (op:DI ((x:DI) (y:DI)), 0)
   to (op:SI (subreg:SI (x:DI) 0) (subreg:SI (x:DI) 0)).
 ...

Is it just specific to DI - SI, or is it for any large mode - smaller mode, 
like SI - HI?

paul

[Bug debug/54508] Wrong debug information emitted if data members not referenced

[paul_koning at dell dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508



--- Comment #3 from Paul Koning paul_koning at dell dot com 2012-09-24 
19:32:21 UTC ---

Created attachment 28260

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28260

Fix and testcase for this, as submitted to the gcc-bugs list



I'm not sure if the main submission should be here or to gcc-bugs -- I posted a

fix there a week ago.  Attached is what I submitted (including a small

adjustment to the regexp used in the testcase file).

Ping: [patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

Ping...

paul

Begin forwarded message:

 From: paul_kon...@dell.com
 Date: September 20, 2012 4:55:05 PM EDT
 To: gcc-patches@gcc.gnu.org
 Subject: Re: [patch] pr/54508: fix incomplete debug information for class
 
 Attached below is an update to the testcase file, to fix the scan-assembler 
 regexp comment character matching.  This uses the same regexp element that 
 H-P Nilsson used in the fix to nested-3.C two days ago.
 
 By the way, I ran check-g++ for dwarf2.exp on this change, no regressions.
 
 Ok to commit?  
 
   paul
 
 On Sep 17, 2012, at 5:24 PM, paul_kon...@dell.com
 paul_kon...@dell.com wrote:
 
 If the only reference in a source file is to a static method of a class, 
 then GCC would output debug information for the class name but not any of 
 its members or base classes.  The attached patch fixes this by having 
 prune_unused_types_mark mark all of the parent's children if the parent 
 DIE type is for a class.
 
 The associated new testcase verifies this, and also verifies this that 
 references to a function in a namespace do *not* cause other parts of that 
 namespace to be emitted as debug information, but that references to a 
 method in a class (or struct or union) do emit the other information for 
 that class.
 
 Ok to commit?  This would close PR/54508.
 
  paul
 
 ChangeLog:
 
 2012-09-17  Paul Koning  n...@arrl.net
 
  * dwarf2out.c (prune_unused_types_mark): Mark all of parent's
  children if parent is a class.
 
 testsuite/ChangeLog:
 
 2012-09-17  Paul Koning  n...@arrl.net
 
  * g++.dg/debug/dwarf2/pr54508.C: New.
 
 Index: gcc/dwarf2out.c
 ===
 --- gcc/dwarf2out.c  (revision 191408)
 +++ gcc/dwarf2out.c  (working copy)
 @@ -21033,9 +21033,13 @@
  prune_unused_types_mark_generic_parms_dies (die);
 
  /* We also have to mark its parents as used.
 - (But we don't want to mark our parents' kids due to this.)  */
 + (But we don't want to mark our parent's kids due to this,
 + unless it is a class.)  */
  if (die-die_parent)
 -prune_unused_types_mark (die-die_parent, 0);
 +prune_unused_types_mark (die-die_parent, 
 + (die-die_parent-die_tag == DW_TAG_class_type 
 ||
 +  die-die_parent-die_tag == 
 DW_TAG_structure_type ||
 +  die-die_parent-die_tag == 
 DW_TAG_union_type));
 
  /* Mark any referenced nodes.  */
  prune_unused_types_walk_attribs (die);
 Index: gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C
 ===
 --- gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C  (revision 0)
 +++ gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C  (revision 0)
 @@ -0,0 +1,67 @@
 +// PR debug/54508
 +// { dg-do compile }
 +// { dg-options -g2 -dA }
 +
 +// { dg-final { scan-assembler \cbase0\\[ \t\]+\# 
 DW_AT_name\|DW_AT_name: \cbase\ } }
 +// { dg-final { scan-assembler \OPCODE0\\[ \t\]+\# 
 DW_AT_name\|DW_AT_name: \OPCODE\ } }
 +// { dg-final { scan-assembler \bi0\\[ \t\]+\# DW_AT_name } }
 +// { dg-final { scan-assembler \si0\\[ \t\]+\# DW_AT_name } }
 +// { dg-final { scan-assembler \f10\\[ \t\]+\# DW_AT_name } }
 +// { dg-final { scan-assembler \f20\\[ \t\]+\# DW_AT_name } }
 +// { dg-final { scan-assembler-not \nc0\\[ \t\]+\# 
 DW_AT_name\|DW_AT_name: \nc\ } }
 +...
 
 // PR debug/54508
 // { dg-do compile }
 // { dg-options -g2 -dA }
 
 // { dg-final { scan-assembler \cbase0\\[ \t\]+\[#;/!|@\]+ 
 DW_AT_name\|DW_AT_name: \cbase\ } }
 // { dg-final { scan-assembler \OPCODE0\\[ \t\]+\[#;/!|@\]+ 
 DW_AT_name\|DW_AT_name: \OPCODE\ } }
 // { dg-final { scan-assembler \bi0\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
 // { dg-final { scan-assembler \si0\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
 // { dg-final { scan-assembler \f10\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
 // { dg-final { scan-assembler \f20\\[ \t\]+\[#;/!|@\]+ DW_AT_name } }
 // { dg-final { scan-assembler-not \nc0\\[ \t\]+\# 
 DW_AT_name\|DW_AT_name: \nc\ } }
 
 class cbase
 
 {
 public:
 static int si;
int bi;
 };
 
 class c : public cbase
 
 {
 public:
 enum
 {
  OPCODE = 251
 };
 int i ;
 static const char *testc (void) { return foo; }
 };
 
 struct s
 {
int f1;
static const char *tests (void) { return test; }
 };
 
 union u
 {
int f2;
double d;
static const char *testu (void) { return test union; }
 };
 
 namespace n 
 {
const char *ntest (void) { return test n; }
 
class nc
{
public:
int i;
static int sj;
};
 }
 
 extern void send (int, int, const void *, int);
 
 void test (int src)
 {
  int cookie = 1;
  send(src, c::OPCODE, c::testc (), cookie);
  send(src, c::OPCODE, s::tests (), cookie);
  send(src, c::OPCODE, u::testu (), cookie);
  send(src, c::OPCODE, n::ntest (), cookie);
 }
 

[Bug debug/54508] Wrong debug information emitted if data members not referenced

[paul_koning at dell dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508

--- Comment #2 from Paul Koning paul_koning at dell dot com 2012-09-17 
21:31:29 UTC ---
I just submitted a proposed fix to the gcc-patches list.

[DOC] Update -feliminate-unused-debug-types description

[Paul_Koning]

Currently the description of -feliminate-unused-debug-types says that it is off 
by default.  In fact, it is on by default.  The attached patch corrects the 
documentation to reflect that.

Ok to commit?

paul

2012-09-17  Paul Koning  n...@arrl.net

* doc/invoke.text (-feliminate-unused-debug-types): Update to
reflect that this is enabled by default.

Index: invoke.texi
===
--- invoke.texi (revision 191393)
+++ invoke.texi (working copy)
@@ -324,7 +324,7 @@
 -fdump-tree-storeccp@r{[}-@var{n}@r{]} @gol
 -fdump-final-insns=@var{file} @gol
 -fcompare-debug@r{[}=@var{opts}@r{]}  -fcompare-debug-second @gol
--feliminate-dwarf2-dups -feliminate-unused-debug-types @gol
+-feliminate-dwarf2-dups -fno-eliminate-unused-debug-types @gol
 -feliminate-unused-debug-symbols -femit-class-debug-always @gol
 -fenable-@var{kind}-@var{pass} @gol
 -fenable-@var{kind}-@var{pass}=@var{range-list} @gol
@@ -6192,17 +6192,18 @@
 Print the compiler's built-in specs---and don't do anything else.  (This
 is used when GCC itself is being built.)  @xref{Spec Files}.
 
-@item -feliminate-unused-debug-types
+@item -fno-eliminate-unused-debug-types
 @opindex feliminate-unused-debug-types
-Normally, when producing DWARF 2 output, GCC emits debugging
+@opindex fno-eliminate-unused-debug-types
+Normally, when producing DWARF 2 output, GCC avoids producing debug symbol 
+output for types that are nowhere used in the source file being compiled.
+Sometimes it is useful to have GCC emit debugging
 information for all types declared in a compilation
 unit, regardless of whether or not they are actually used
-in that compilation unit.  Sometimes this is useful, such as
+in that compilation unit, for example 
 if, in the debugger, you want to cast a value to a type that is
 not actually used in your program (but is declared).  More often,
 however, this results in a significant amount of wasted space.
-With this option, GCC avoids producing debug symbol output
-for types that are nowhere used in the source file being compiled.
 @end table
 
 @node Optimize Options

Re: [DOC] Update -feliminate-unused-debug-types description

[Paul_Koning]

On Sep 17, 2012, at 1:20 PM, Ian Lance Taylor wrote:

 On Mon, Sep 17, 2012 at 8:59 AM,  paul_kon...@dell.com wrote:
 
 2012-09-17  Paul Koning  n...@arrl.net
 
* doc/invoke.text (-feliminate-unused-debug-types): Update to
reflect that this is enabled by default.
 
 This is OK.
 
 Thanks.
 
 Ian

Thanks.  Committed.

paul

[patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

If the only reference in a source file is to a static method of a class, then 
GCC would output debug information for the class name but not any of its 
members or base classes.  The attached patch fixes this by having 
prune_unused_types_mark mark all of the parent's children if the parent DIE 
type is for a class.

The associated new testcase verifies this, and also verifies this that 
references to a function in a namespace do *not* cause other parts of that 
namespace to be emitted as debug information, but that references to a method 
in a class (or struct or union) do emit the other information for that class.

Ok to commit?  This would close PR/54508.

paul

ChangeLog:

2012-09-17  Paul Koning  n...@arrl.net

* dwarf2out.c (prune_unused_types_mark): Mark all of parent's
children if parent is a class.

testsuite/ChangeLog:

2012-09-17  Paul Koning  n...@arrl.net

* g++.dg/debug/dwarf2/pr54508.C: New.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 191408)
+++ gcc/dwarf2out.c (working copy)
@@ -21033,9 +21033,13 @@
   prune_unused_types_mark_generic_parms_dies (die);
 
   /* We also have to mark its parents as used.
-(But we don't want to mark our parents' kids due to this.)  */
+(But we don't want to mark our parent's kids due to this,
+unless it is a class.)  */
   if (die-die_parent)
-   prune_unused_types_mark (die-die_parent, 0);
+   prune_unused_types_mark (die-die_parent, 
+(die-die_parent-die_tag == DW_TAG_class_type 
||
+ die-die_parent-die_tag == 
DW_TAG_structure_type ||
+ die-die_parent-die_tag == 
DW_TAG_union_type));
 
   /* Mark any referenced nodes.  */
   prune_unused_types_walk_attribs (die);
Index: gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C
===
--- gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
+++ gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
@@ -0,0 +1,67 @@
+// PR debug/54508
+// { dg-do compile }
+// { dg-options -g2 -dA }
+
+// { dg-final { scan-assembler \cbase0\\[ \t\]+\# 
DW_AT_name\|DW_AT_name: \cbase\ } }
+// { dg-final { scan-assembler \OPCODE0\\[ \t\]+\# 
DW_AT_name\|DW_AT_name: \OPCODE\ } }
+// { dg-final { scan-assembler \bi0\\[ \t\]+\# DW_AT_name } }
+// { dg-final { scan-assembler \si0\\[ \t\]+\# DW_AT_name } }
+// { dg-final { scan-assembler \f10\\[ \t\]+\# DW_AT_name } }
+// { dg-final { scan-assembler \f20\\[ \t\]+\# DW_AT_name } }
+// { dg-final { scan-assembler-not \nc0\\[ \t\]+\# 
DW_AT_name\|DW_AT_name: \nc\ } }
+
+class cbase
+
+{
+public:
+ static int si;
+int bi;
+};
+
+class c : public cbase
+
+{
+public:
+ enum
+ {
+  OPCODE = 251
+ };
+ int i ;
+ static const char *testc (void) { return foo; }
+};
+
+struct s
+{
+int f1;
+static const char *tests (void) { return test; }
+};
+
+union u
+{
+int f2;
+double d;
+static const char *testu (void) { return test union; }
+};
+
+namespace n 
+{
+const char *ntest (void) { return test n; }
+
+class nc
+{
+public:
+int i;
+static int sj;
+};
+}
+
+extern void send (int, int, const void *, int);
+
+void test (int src)
+{
+  int cookie = 1;
+  send(src, c::OPCODE, c::testc (), cookie);
+  send(src, c::OPCODE, s::tests (), cookie);
+  send(src, c::OPCODE, u::testu (), cookie);
+  send(src, c::OPCODE, n::ntest (), cookie);
+}

[Bug debug/49459] attribute((mode(byte))) in a typedef produces wrong debug information

[paul_koning at dell dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49459

--- Comment #3 from Paul Koning paul_koning at dell dot com 2012-09-13 
18:52:51 UTC ---
I spent some time trying to figure this out.  The offending code seems to be
the prune_unused_types machinery.  

If there is a reference to a static method, but no other references to parts of
the class, then the class is treated as unused.  However, the static method
does cause the class name to be emitted in the dwarf output.  But because of
the fact that it is treated as unused, nothing else about the class is emitted.

This messes up code that consumes the debug data, because it now looks like the
class IS defined there, but most of its substance is missing.

This code is sufficiently hard to understand that I'm not likely to get much
further.

Meanwhile, I noticed a documentation bug: the documentation for
-feliminate-unused-debug-types says that this switch is off by default.  That
is no longer true, it is on by default.  If I turn it off, the
prune_unused_types machinery is suppressed and I get valid debug output.

[Bug debug/49459] attribute((mode(byte))) in a typedef produces wrong debug information

[paul_koning at dell dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49459

--- Comment #4 from Paul Koning paul_koning at dell dot com 2012-09-13 
21:18:17 UTC ---
Sorry, please disregard the previous comment, I put it on the wrong bug.

[Bug debug/54508] Wrong debug information emitted if data members not referenced

[paul_koning at dell dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508

--- Comment #1 from Paul Koning paul_koning at dell dot com 2012-09-13 
21:21:58 UTC ---
I spent some time trying to figure this out.  The offending code seems to be
the prune_unused_types machinery.  

If there is a reference to a static method, but no other references to parts of
the class, then the class is treated as unused.  However, the static method
does cause the class name to be emitted in the dwarf output.  But because of
the fact that it is treated as unused, nothing else about the class is emitted.

This messes up code that consumes the debug data, because it now looks like the
class IS defined there, but most of its substance is missing.

Meanwhile, I noticed a documentation bug: the documentation for
-feliminate-unused-debug-types says that this switch is off by default.  That
is no longer true, it is on by default.  If I turn it off, the
prune_unused_types machinery is suppressed and I get valid debug output. 
Unfortunately, it is also so much larger that my builds run very slowly and
some binaries grow by as much as a factor of 5.

[Bug target/43168] internal compiler error for xgcc when building gcc for pdp11-unknown-aout

[paul_koning at dell dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43168

Paul Koning paul_koning at dell dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.6.0
 Resolution||FIXED

--- Comment #2 from Paul Koning paul_koning at dell dot com 2012-09-13 
21:25:19 UTC ---
As I mentioned, this was fixed a while ago.

Bug in bitfield handling?

[Paul_Koning]

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?

[Paul_Koning]

On Sep 7, 2012, at 2:02 PM, Andrew Pinski wrote:

 On Fri, Sep 7, 2012 at 10:57 AM,  paul_kon...@dell.com 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

[Bug debug/54508] New: Wrong debug information emitted if data members not referenced

[paul_koning at dell dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508

 Bug #: 54508
   Summary: Wrong debug information emitted if data members not
referenced
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paul_kon...@dell.com


Created attachment 28142
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28142
test case file

For the attached test case, GDB shows that the class definition for
CIpcDumpACK_NP is wrong.  Only the method is shows; the base class and data
member are missing.

Re: C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?

[Paul_Koning]

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

Size difference in base class between GCC releases

[Paul_Koning]

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

[Paul_Koning]

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

[Paul_Koning]

On Aug 27, 2012, at 4:05 PM, Gabriel Dos Reis wrote:

 On Mon, Aug 27, 2012 at 1:48 PM,  paul_kon...@dell.com 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: ISL install troubles

[Paul_Koning]

On Aug 14, 2012, at 4:17 AM, Richard Guenther wrote:

 On Mon, Aug 13, 2012 at 6:25 PM,  paul_kon...@dell.com 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

[Paul_Koning]

On Aug 14, 2012, at 4:17 AM, Richard Guenther wrote:

 On Mon, Aug 13, 2012 at 6:25 PM,  paul_kon...@dell.com 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

50% slowdown with LTO

[Paul_Koning]

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

[Paul_Koning]

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