Re: 3 byte variables [feature request]
If you're using C++ and are willing to use gcc (and clang) extensions,
you can do a bit better, e.g.:
class __attribute__((packed)) int24_t
{
public:
operator int () const { return b; }
int24_t (int v) : b (v) {}
int24_t () {}
private:
int b : 24;
};
Then an array like int24_t a[1000] will only take 3000 bytes, and
you can kinda/sorta mix int24_t types with integers...
Of course the generated code is not so efficient, so don't use such
types in inner loops if you can help it!
[Dunno if C++11 has any more portable replacement for the
__attribute__((packed))...]
-miles
--
雨上がり に歩いて、風 柔らかい
Re: [google gcc-4_7,gcc-4_8,integration] Add bounds checks to vectorbool
Paul Pluzhnikov ppluzhni...@google.com writes: Keying off NDEBUG rather than __OPTIMIZE__ seems like a more consistent approach -- if you want assert()s, then you probably also want these checks. That's a bad idea. NDEBUG (Be really slow unless the user has positively defined this macro, whose use is rare enough that many people will not even be aware of it) should be used less, not more. The __OPTIMIZE__ is far superior, because it happens automatically when the user specifies any optimization option. -miles -- Guilt, n. The condition of one who is known to have committed an indiscretion, as distinguished from the state of him who has covered his tracks.
Re: Fix PR 53743 and other -freorder-blocks-and-partition failures
A nitpick: the dragon book was first published 36 years ago... (!) -miles -- “There are moments, Jeeves, when one asks oneself, ‘Do trousers matter?’” “The mood will pass, sir.” [P.G. Wodehouse, The Code Of The Woosters]
Re: GIt Issue
Iyer, Balaji V balaji.v.i...@intel.com writes: I tried the following command: git clone http://gcc.gnu.org/git/gcc.git gcc.git Please try the git protocol instead of http: git clone git://gcc.gnu.org/git/gcc.git gcc.git Thanks for your help Markus. Unfortunately, http is the only option for me. Does gcc.gnu.org not support the modern git smart http transport? git: and http: should be near identical these days (except that http will get through many more firewalls and proxies). http://git-scm.com/2010/03/04/smart-http.html -miles -- 永日の 澄んだ紺から 永遠へ
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
N.M. Maclaren n...@cam.ac.uk writes: That is another matter entirely. The code of gcc/gfortran is supposed to be compilable with other compilers, and it is foolish to make unnecessary assumptions by relying on undefined behaviour. The simple facts are that C++ does NOT define bool to be compatible with _Bool, and there are enough differences in specification and semantics to make it likely that they are not the same in at least some compilers. This mess has caused and still causes no end of problems for Fortran interoperability and in standards like MPI. Er, maybe so, but is there actually an issue in _this_ case? From original message, it sounds like these are internal compiler interfaces, so all that matters is that they be self-consistent, and there's no external ABI involved... So as long as all the code in question is compiled with C++ and uses C++ bool, or is compiled with C99 and uses _Bool, and doesn't use any functionality that isn't in the intersection of those two types, there shouldn't be any problem, right? -miles -- Congratulation, n. The civility of envy.
Re: C++ PATCH: use identifier_p instead of naked TREE_CODE == IDENTIFIER_NODE
Gabriel Dos Reis g...@axiomatics.org writes: in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST except that it returns a typed pointer instead of a boolean value. What's the point of returning a pointer when the name (and apparently, use, judging from the patch) suggest a boolean...? [If it's intended to be used in non-boolean contexts as well, using _p for the name seems vaguely ill-considered...] -miles -- Never miss a good chance to shut up. -- Will Rogers
Re: C++ PATCH: use identifier_p instead of naked TREE_CODE == IDENTIFIER_NODE
Gabriel Dos Reis g...@integrable-solutions.net writes: In many places, we do thinks like: 1. test that we have a identifier. 2. immediately follow that with access to parts of the tree as identifiers, but check again that we really an identifier, etc. There is nothing silly about that. Sure, it's a common and useful pattern. I'm just saying it's silly to call it ..._p in that case... -miles -- 雨上がり に歩いて、風 柔らかい
Re: [PATCH] Fix PR56466
Marek Polacek pola...@redhat.com writes: + bool changed = false; + changed |= true; + changed |= true; + changed |= true; + changed |= true; +if (changed) Why do you use |= ...? Isn't it equivalent to just = (which is more clear) for a boolean? Thanks, -miles -- 永日の 澄んだ紺から 永遠へ
Re: [google gcc-4_7] new module grouping method (issue7393058)
x...@google.com (Rong Xu) writes: - gcov_unsigned_t is_exported; + gcov_unsigned_t flag;/* bit 0: is_exported, + bit 1: need to include all the auxiliary + modules in use compilation. */ flags? Thanks, -miles -- 永日の 澄んだ紺から 永遠へ
Re: GCC cannot move address calculation to store+load?
Richard Biener richard.guent...@gmail.com writes: Note that combine does not apply because %eax is used multiple times. This also means that for code-size the combining is not a good idea. Though the lea instruction seems rather large, so in fact the code is a fair bit smaller without it, e.g. as generated by clang/llvm: clang/llvm 3.1 (-O2 -m32): foo: 0: 8b 44 24 08 mov0x8(%esp),%eax 4: 8b 4c 24 04 mov0x4(%esp),%ecx 8: 8b 14 c1mov(%ecx,%eax,8),%edx b: 89 15 00 00 00 00 mov%edx,0x0 11: 89 04 c1mov%eax,(%ecx,%eax,8) 14: 31 c0 xor%eax,%eax 16: c3 ret gcc 4.8 20130113 (-O2 -m32): foo: 0: 8b 54 24 08 mov0x8(%esp),%edx 4: 8d 04 d5 00 00 00 00lea0x0(,%edx,8),%eax b: 03 44 24 04 add0x4(%esp),%eax f: 8b 08 mov(%eax),%ecx 11: 89 0d 00 00 00 00 mov%ecx,0x0 17: 89 10 mov%edx,(%eax) 19: 31 c0 xor%eax,%eax 1b: c3 ret -miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
Re: RFC - Remove support for PCH post 4.8
2012/11/29 Gabriel Dos Reis g...@integrable-solutions.net: My understanding from attending the last C++ standards committee is that we are still way far from having something that gets consensus of good enough proposal on modules to coalesce around. We have several proposals, each in various states of experimental implementations; nothing more. Do you have pointers to any other other (currently viable) proposals, besides the one outlined by N3347 and the slides Chris pointed a link to? Thanks, -miles p.s. sorry if all of this is common knowledge... ^^; -- Cat is power. Cat is peace.
Re: RFC - Remove support for PCH post 4.8
Chris Lattner clatt...@apple.com writes: Clang has fantastic support for PCH... and soon modules. We don't plan to drop PCH support when modules is implemented. Do you have a pointer to the modules proposal clang will implement? Thanks, -miles -- 「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
Re: RFC - Alternatives to gengtype
Basile Starynkevitch bas...@starynkevitch.net writes: PS. LLVM has also a decisive documentation advantage w.r.t. GCC What...? The last time I tried to do something with LLVM, the internals docs were awful (full of not yet written kinda stuff, usually just in the area I was confused about)... and gcc historically has had great internals documentation, though I don't know if it's managed to keep up with all the changes in the 4.x series... -miles -- Yorton, Wressle, and Gospel Oak, the richness of your heritage is ended. We shall not stop at you again; for Dr Beeching stops at nothing.
Re: faster random number engine
Can this replace the current mersenne twister implementation in std:: once the endianness issue, etc, have been worked out? -miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen
Re: [cxx-conversion] Make double_int a class with methods and operators. (issue6443093)
Mike Stump mikest...@comcast.net writes: Constructors are allowed, but PODs are often passed more efficiently. That property seemed particularly important for double_int. Show us the difference in timing. Show us the generated code. I can't imagine that it could ever matter. I'm also curious about that statement... PODs don't really seem to offer much advantage with modern compilers, except in a few very specific cases (of which this doesn't seem to be one), e.g. in unions. -miles -- values of β will give rise to dom!
Re: [cxx-conversion] Make double_int a class with methods and operators. (issue6443093)
Richard Guenther richard.guent...@gmail.com writes:
Constructors are allowed, but PODs are often passed more efficiently.
That property seemed particularly important for double_int.
Show us the difference in timing. Show us the generated code. I
can't imagine that it could ever matter.
I'm also curious about that statement... PODs don't really seem to
offer much advantage with modern compilers, except in a few very
specific cases (of which this doesn't seem to be one), e.g. in unions.
They make a difference for the by-value passing ABI. double-ints can
be passed in two registers on most platforms.
Sure, but that doesn't seem to depend on PODness -- non-PODs can be
passed in two registers as well, AFAICS...
E.g., in the following:
typedef long valtype;
struct X { valtype x, y; };
struct Y { Y (valtype a, valtype b) : x (a), y (b) { } valtype x, y; };
extern void fx (X x);
void test_x () {X x = { 1, 2 }; fx (x); }
extern void fy (Y y);
void test_y () {Y y (1, 2); fy (y); }
test_x and test_y use exactly the same calling sequence (and contain
exactly the same assembly code)... [on x86-64]
Thanks,
-miles
--
80% of success is just showing up. --Woody Allen
Re: [PATCH][2/n] Allow anonymous SSA names, a bunch of new predicates for SSA names
Michael Matz m...@suse.de writes: Bikeshedding: please settle on consistent naming, either IS, or HAS or _P. (FWIW, I suggest _P). IS and HAS have different meanings... -miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth
Re: Allow use of ranges in copyright notices
Robert Dewar de...@adacore.com writes: On 7/2/2012 8:35 AM, Alexandre Oliva wrote: On Jun 30, 2012, David Edelsohn dje@gmail.com wrote: IBM's policy specifies a comma: first year, last year and not a dash range. But this notation already means something else in our source tree. I think using the dash is preferable, and is a VERY widely used notation, used by all major software companies I deal with! Also the dash notation has been vetted by FSF lawyers (and accordingly is used by other GNU projects that pay a lot of attention to getting the legal details right, like Emacs). -miles -- Politeness, n. The most acceptable hypocrisy.
Re: [wwwdocs] Update coding conventions for C++
Magnus Fromreide ma...@lysator.liu.se writes: Two spaces for members is common practice with GNU, and it seems to be used for libstdc++. One space for protection labels is not something I have heard of before and libstdc++ uses no indentation for them. A freshly started emacs also doesn't indent access labels. Yeah, zero indentation (or rather, aligned with the surrounding brace level, e.g. for nested structures/classes) is certainly the defacto GNU standard for C++ access labels (private:, etc). There seems no reason for GCC to be different. -miles -- Quotation, n. The act of repeating erroneously the words of another. The words erroneously repeated.
Re: Renaming Stage 1 and Stage 3
Richard Guenther richard.guent...@gmail.com writes: why not give them names with an actual meaning? Development Stage and Stabilizing Stage? I realize those are rather long names, but you can always put short forms in tables, like Dev Stage and Stab Stage. The latter is when the knives come out, eh...? -miles -- Mayonnaise, n. One of the sauces that serve the French in place of a state religion.
Re: [cxx-conversion] New Hash Table (issue6244048)
Gabriel Dos Reis g...@integrable-solutions.net writes: if this coding standard is going to be adopted as a GNU coding convention, then you have to be flexible and allow yourself to see beyond the past written in C. You have to ask yourself: how do I want the codebase to look like in 10, 15, 20, 25 years. Er, sure, but that's obviously not an excuse for simply _ignoring_ the existing C standard, as nightstrike seemed to be suggesting. For the most part, the existing C standard (with the obvious generalizations where C++ is a superset) works perfectly fine for C++ too -- and yes, this is still true even if BS is annoyed by some people's use of C/C++ (I get BS's point, but it's silly to read too much into it). -miles -- We have met the enemy, and he is us. -- Pogo
Re: How to compare two text files? Using sed, cmp, diff, tr?
Joern Rennecke amyl...@spamcop.net writes: Some platforms need b for fopen, others reject it. Hmm, really? b seems to standard in ISO-C (and widely used in programs aiming for portability)... -miles -- Bore, n. A person who talks when you wish him to listen.
Re: [cxx-conversion] New Hash Table (issue6244048)
NightStrike nightstr...@gmail.com writes: You wouldn't use the GNU C Coding conventions to write in tcl, and you shouldn't use them to write in C++. You should just create the GNU C++ Coding Standards new, and not base them off of the former. ... r, just use some common sense, and change things which need changing. C++ and C are not the same, but they certainly have enough overlap that using the existing C conventions as a starting point makes a huge amount of sense... To just start new would either (1) end up adopting many of the same rules anyway, or (2) result in a huge amount of absolutely pointless inconsistency (where otherwise identical code ends up looking different). E.g., as a start, there's absolutely no reason to change most of the indentation or spacing rules, because the C rules work totally fine for C++ (with obvious extensions to handle new cases). You can argue about the details (should namespaces be indented or not?), but most of it is pretty obvious. -miles -- Egotist, n. A person of low taste, more interested in himself than in me.
Re: [Patch / RFC] Improving more locations for binary expressions
Paolo Carlini paolo.carl...@oracle.com writes: in case my message ends up garbled, the carets do not point to (column 13), two times point to b (column 20), which is obviously wrong. In other terms, all the columns are 20, all wrong. The new caret support does seem to have revealed a bunch of places where the column info in error messages was pretty screwy... I guess nobody paid much attention to it before... :] Should these get reported as bugzilla bugs...? -miles -- The trouble with most people is that they think with their hopes or fears or wishes rather than with their minds. -- Will Durant
Re: Should gcc give warning for this case?
Qun-Ying zhu.quny...@gmail.com writes: No warning at all. Should gcc warn about the *next pointer points to an unknown structure? I know it is allow by the standard, but most of the case, it indicates some error in the code. Hmm? Where do you expect to warn? You never dereference the pointer, so there's no error, and un-dereferenced pointers to unknown structures are not uncommon in C programs, so a warning about this would result in many false positives... -miles -- Freebooter, n. A conqueror in a small way of business, whose annexations lack of the sanctifying merit of magnitude.
Re: Announce - Thread safety annotations no longer supported in GCC
Delesley Hutchins deles...@google.com writes: I can give you detailed technical reasons why GIMPLE was not working for us if you like, but I'm not sure it would be all that constructive. Why wouldn't it be constructive? Even if it's impractical for gcc to change to the degree needed to fit your particular project (especially in the short term), hearing the details of how gcc's representations fell short, and how others may have done things better, seems useful. Understanding is almost always a good thing, even if it can't always be put to immediate use... Things will evolve over time (yes, even gcc!), and such input plays a very useful part in guiding this evolution. Of course, such an explanation entails work on your part, so it's understandable if you're a bit skeptical as to whether it's worth the effort, but still, in the abstract... Thanks, -Miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth
Re: Switching to C++ by default in 4.8
Ian Lance Taylor i...@google.com writes: And GCC usually has better diagnostic than clang except in those few areas which it does not (those some might say those areas are the most important ones). No. clang's diagnostics for C++ are much much better than GCC's. Obviously GCC's can improve, but today clang's are much better. Meh. Clang's diagnostics are often pretty good, and it's rightly lauded for that, but the OMG clang totally murders gcc for diagnostics! meme (which seems to be staple of clang's unfortunately large fanboi contingent) is an exaggeration. Clang's diagnostics are not _that_ good, gcc's are [currently] not that bad, and the situations where the difference is the most noticeable tend to be obscure. (remember: Only Henry Spencer can say No. and really get away with it...) -miles -- Non-combatant, n. A dead Quaker.
Re: RFC: -Wall by default
Robert Dewar de...@adacore.com writes: I've got a radically different experience here, real bugs were introduced while trying to remove this warning, and as far as I can tell, I've never found any bugs involving precedence of and || -- in the code I'm working on --, whose precedence is really well known from everyone. You simply can't make a claim on behalf of everyone like this, and it's very easy to prove you wrong, i personally know many competent programmers who do NOT know this rule. ... and it's quite possible that such bugs resulting from adding parentheses means that the programmer fixing the code didn't actually know the right precedence! I think the relative precedence of * and + can be safely termed very well known, but in the case of and ||, it's not so clear... -miles -- Brain, n. An apparatus with which we think we think.
Re: RFC: -Wall by default
2012年4月10日15:26 Eric Botcazou ebotca...@adacore.com: Something like -Wdefault-warnings is a reasonable choice, for the reasons already mentioned in this sub-thread. Purists will find that -Wdefault-warnings is redundant though, since -W is supposed to mean warning already, e.g. it's -Wall and not -Wall-warnings. (-Wnormal ?) The name doesn't have to be perfect and utterly unambiguous, as it's rarely going to be used (and people cope with misleading names like -Wall :), and it's more important that it makes sense with no- prepended anyway... -Wno-standard -Wno-default -Wno-defaults -Wno-default-warnings To be honest, all of those sound fine to me... bike-sheddin', -miles -- Cat is power. Cat is peace.
Re: RFC: -Wall by default
Andrew Haley a...@redhat.com writes: The argument is that we should enable the warnings by default because it makes gcc more competitive. But that only makes gcc more competitive if enabling these kinds of warnings by default is an advantage. However, we haven't established that -Wall by default is advantageous. More warnings (if they're reasonable warning) enabled results in better, less buggy, more portable, code for users. That's surely an advantage for users, and making users happy is good for gcc, yes? [Moreover, by helping to prevent obscure bugs caused by bogus code, it can help avoid people thinking that the compiler's broken.] -miles -- Come now, if we were really planning to harm you, would we be waiting here, beside the path, in the very darkest part of the forest?
Re: Switching to C++ by default in 4.8
Torvald Riegel trie...@redhat.com writes: I hate to bring this up, but in my personal experience, getting started with LLVM was _much_ easier than with GCC. LLVM is a much newer codebase, so that's an advantage unrelated to the language. I dunno, I've some experience with LLVM as well, and I actually found it rather more difficult to get started with than gcc... Part of this is, of course, is that gcc has excellent internals documentation, whereas LLVM's is almost non-existant, but LLVM's much more proper C++ coding style didn't seem to help a whole lot with making it understandable (and if anything may have made it _worse_). Gcc's code, while insanely nasty in places (reload...), generally seems to be written in a straight-forward manner that I found fairly easy to follow (given some persistence). Of course C++ could help a little in slimming down gcc's code (e.g. using constructors/destructors, etc). -Miles -- Carefully crafted initial estimates reward you not only with reduced computational effort, but also with understanding and increased self-esteem. -- Numerical methods in C, Chapter 9. Root Finding and Nonlinear Sets of Equations
Re: RFC: -Wall by default
James Cloos cl...@jhcloos.com writes: GDR Exactly. Our bugzilla databases has lot of requests in this spirit. If that is so, then defaulting to -Wall will just generate even more requests to turn that off. You may well imagine. However, it isn't known. Turning it on by default, at least for a while is one way to replace such imagination with actual data... [Or, perhaps, not -Wall perse, but maybe a new option which is a little more conservative, -Wstandard or something...] -miles -- Friendship, n. A ship big enough to carry two in fair weather, but only one in foul.
Re: RFC: -Wall by default
Dave Korn dave.korn.cyg...@gmail.com writes: IMHO we should move the -Wunused ones into -Wextra if we're going to turn on -Wall by default. The rest seem pretty reasonable defaults to me. How about instead adding new -Wstandard, which will be on by default, and keeping -Wall / -Wextra the same (so as to not _remove_ warnings for people that currently use -Wall). -miles -- An atheist doesn't have to be someone who thinks he has a proof that there can't be a god. He only has to be someone who believes that the evidence on the God question is at a similar level to the evidence on the werewolf question. [John McCarthy]
Re: RFC: -Wall by default
domi...@lps.ens.fr (Dominique Dhumieres) writes: PS -Wall is a simple enough option to be remembered by all users who need it As is -Wno-all, of course. (if they don't use it, they don't want it). That isn't necessarily the case. In my experience, there seem to be a lot of developers who simply don't think much about the issue to the point of adding warning options, but who are not really averse to _heeding_ warnings that the compiler emits by default. It's kind of hard to say where the right balance lies given gcc's disparate user community, but ... one way to find out is try... :] For instance, how about adding -Wall to the default options now, and then re-evaluate the issue based on any complaints that come in from people using snapshots? That's hardly a perfect method, as the sort of people who run compiler snapshots are maybe not entirely representative, but at least it's better data than one gets by simply sitting around and pontificating... -Miles -- Ocean, n. A body of water covering seven-tenths of a world designed for Man - who has no gills.
Re: RFC: -Wall by default
Robert Dewar de...@adacore.com writes: We have run into people running benchmarks where they were specifically prohibited from using other than the default options, and gcc fared badly in such comparisons. Yeah, there was the silly benchmark at phoronix where they came to the conclusion that tcc was a better compiler than gcc because it generated faster programs when run without any options... [*] Phoronix is well known for completely clueless benchmarking practices, but ... unfortunately some people actually seem to pay attention to what they say. -miles -- Innards, n. pl. The stomach, heart, soul, and other bowels.
Re: RFC: -Wall by default
Miles Bader mi...@gnu.org writes: For instance, how about adding -Wall to the default options now, and then re-evaluate the issue based on any complaints that come in from people using snapshots? That's hardly a perfect method, as the sort of people who run compiler snapshots are maybe not entirely representative, but at least it's better data than one gets by simply sitting around and pontificating... I guess it's pretty obvious, but I meant to say ... and then later re-evaluate the issue before the next release -miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Pedro Alves pal...@redhat.com writes: OK, you've all made clear you have your sensible reasons to have the '.info' ... it available only though the new, undocumented option named (literally) hack!info-in-builddir. I hope this is acceptable to you. ... *undocumented* option '!hack!info-in-builddir' (whose name should made it clear that it is not meant for public consumption). So will this be called a hack forever, or will the naming be revisited before a release? IMO, either the feature is sensible, and there doesn't seem to be a good reason other users couldn't also use it, and hence it should get a non-hackish name and be documented; or it isn't sensible, and then it shouldn't exist. Why the second-class treatment? I suspect there are better, cleaner, ways to accomplish the underlying goal, but I suppose the gcc maintainers don't want to spend the time fiddling around with their build infrastructure for such a minor issue... -miles -- Alone, adj. In bad company.
Re: Switching to C++ by default in 4.8
Ian Lance Taylor i...@google.com writes: What is the earliest release of G++ that will allow GCC to bootstrap? Another thing that is worth testing. Right now I would anticipate that even fairly old releases of G++ can bootstrap GCC. However, we will need to decide what old release we want to ensure works. 4.2 at the latest might be a good idea, given its continued widespread use in scared of the GPL3[*] communities (*BSD, the pre-clang llvm frontend, the pathscale/path64 compiler frontend, etc)... [*] stronger language omitted for diplomatic reasons -miles -- Zeal, n. A certain nervous disorder afflicting the young and inexperienced.
Re: gcc extensibility
Bernd Schmidt ber...@codesourcery.com writes: No, that means would be using the old tool named 'patch' before building GCC. Or even the new tool named 'git'. [... and note that git apply doesn't actually require a git repo, and is a great (generally rather better behaved) replacement for the patch command.] -miles -- Youth, n. The Period of Possibility, when Archimedes finds a fulcrum, Cassandra has a following and seven cities compete for the honor of endowing a living Homer.
Re: Proposed plugin API for GCC
David Malcolm dmalc...@redhat.com writes: I initially attempted an underscore_based_naming_convention but quickly found it difficult to get concise function names, so I switched to a CamelCaseBased_NamingConvention with an underscore separating a notional namespace element from a secondary element, which saved plenty of space. Just use the same names, but with underscore separated (lowercase) words instead of StuDLyCapS; obviously they won't be significantly longer, but will maintain gcc naming conventions, and will more readable. -Miles -- Suppose we've chosen the wrong god. Every time we go to church we're just making him madder and madder. -- Homer Simpson
Re: Is it a bug when use “”if the operator is out of the size 0~63
Yang Yueming yueming.y...@huawei.com writes: long long abc = 0x01234567891abcde; long long xyz; ... xyz = abc 65; ... The result of xyz should be 0，but it is 2468acf123579bc ,same as xyz = abc 1,Why? Because the shift operators in C have an undefined result when the shift-count is larger than the size of the type. As the compiler generally just generates the underlying CPU's shift instruction, then what happens in practice depends on the CPU. Different CPUs do different things in such a case, and one popular alternative is to simply interpret the shift-count modulo the word-size. So as for int a35and etc.. Same thing. -miles -- Electricity, n. The cause of all natural phenomena not known to be caused by something else.
Re: Dealing with compilers that pretend to be GCC
ludovic.cour...@inria.fr (Ludovic Courtès) writes: Rather than assertions, one could use predicates: #if #has_builtin(foo) #has_attribute(bar) ... #endif The difference being that (1) predicates were designed specifically for this purpose, and (2) there’s no magic involved. but ... predicates are (1) less portable, since they involve magic syntax (whereas it's obvious how to make magic macros portable) and (2) deprecated even in gcc... -miles -- You can hack anything you want, with TECO and DDT.
Re: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
Chris Lattner clatt...@apple.com writes:
Int foo (void) { return 1; }
A message like
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
is just pain to the eyes, and apart from that it is not more helpful
than a simple syntax error before 'foo':
FWIW, Clang produces:
t.c:1:1: error: unknown type name 'Int'; did you mean 'int'?
Int foo (void)
gcc 4.6 (and later) produces a more reasonable message:
$ gcc-4.6 -c e.c
e.c:1:1: error: unknown type name ‘Int’
I suspect the OA has an older version of gcc...
-Miles
--
80% of success is just showing up. --Woody Allen
Re: why GCC does implicit promotion to unsigned char?
Konstantin Vladimirov konstantin.vladimi...@gmail.com writes:
It looks really weird. Why gcc promotes char to unsigned char internally?
Hmm, maybe not useful, but if you used unsigned char as the variable
types or the -funsigned-char command-line option, it won't ('cause the
variables will already be unsigned)...
-miles
--
Politics, n. A strife of interests masquerading as a contest of
principles. The conduct of public affairs for private advantage.
Re: Dealing with compilers that pretend to be GCC
Chris Lattner clatt...@apple.com writes: Why not just implement the clang feature checking macros? http://clang.llvm.org/docs/LanguageExtensions.html#feature_check Yes, please. [Hopefully with a smidgen of cooperation regarding the actual feature names...] -miles -- Dawn, n. When men of reason go to bed.
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
willus.com willus@willus.com writes: For the math functions, this is normally more a libc feature, so you might get very different results on different OS. Then again, by using -ffast-math, you allow the math functions to return any random value, so I can think of ways to make it even faster ;-) I use -ffast-math all the time and have always gotten virtually identical results to when I turn it off. The speed difference is important for me. Also, of course, -ffast-math is really shorthand for a bunch of more detailed options; which are OK and which are not is often very application-dependent. One can easily fine-tune the result by either using the more detailed options instead of -ffast-math, or perhaps by specifying -ffast-math and then turning _off_ (with -fno-xxx) anything that's too risky -Miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.'
Re: non-virtual-destructor warnings redux
2011/12/24 Jonathan Wakely jwakely@gmail.com:
On 24 December 2011 10:50, Paolo Carlini wrote:
On 12/24/2011 03:04 AM, Miles Bader wrote:
What do people think... is this a better non-virtual-dtor warning?
First of all I'd check http://gcc.gnu.org/gcc-4.7/changes.html#cxx and
see that I already added it ;-)
Ah, argh, sorry!
It turns out the file where clang caught the bug is the _one_ file in
my program I compile without -Wall ('cause it's automatically
generated code with ... er... lots of ... questionable stuff); clang
has this particular warning enabled by default, so it caught it
though...!
thanks,
-miles
--
Cat is power. Cat is peace.
Re: gcc-4.7-20111224 is now available
gccad...@gcc.gnu.org writes: Snapshot gcc-4.7-20111224 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20111224/ oooh a christmas present! merry xmas~ -miles -- 「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
NSDMI bug?
Is the following code valid?
#include tuple
struct X
{
std::tupleint,int tt{1, 2}; // works
};
struct Y
{
std::tupleint,int tt = std::tupleint,int{1, 2}; // *error*
};
'cause it results in an error with gcc 20111210:
$ g++-snapshot -c -std=c++11 nsdmi2.cc
nsdmi2.cc:10:43: error: expected unqualified-id before 'int'
$ g++-snapshot --version
g++ (Debian 20111210-1) 4.7.0 20111210 (experimental) [trunk revision 182188]
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks,
-miles
--
Alone, adj. In bad company.
Re: NSDMI bug?
k, bugzilla'd thanks, -miles -- Cat is power. Cat is peace.
non-virtual-destructor warnings redux
gcc seems to have had a succession of warnings about non-virtual-
destructors-in-classes-with-virtual-methods, none of which really
worked all that well in practice (and so none are enabled by default,
even by -Wall or -Wextra).
But I notice clang has a variant which seems pretty well-behaved on
real code:
struct X { virtual void m () = 0; };
void test (X *x) { delete x; }
yields:
$ clang++ -c dnvd.cc
dnvd.cc:2:23: warning: delete called on 'X' that is abstract but has
non-virtual
destructor [-Wdelete-non-virtual-dtor]
By triggering at the point of _delete_, for a class type it knows
can't be the most-derived (because it's abstract), it avoids the
well but I only ever delete most-derived-classes false positive.
I had endless problems with false positives with all of gcc's various
non-virtual-dtor warnings, but I've had zero problems with this one,
and it's actually caught real bugs for me (and note that it's enabled
by default).
What do people think... is this a better non-virtual-dtor warning?
-miles
--
If you can't beat them, arrange to have them beaten. [George Carlin]
Re: warn about deprecated access declarations
Jonathan Wakely jwakely@gmail.com writes: How about ...; suggest adding the using keyword? That sounds like the compiler is suggesting that the user suggests doing that! It is similar to suggest parentheses Good point, that's not correct English either, but it would be consistent. (Suggest X is an imperative, telling the user to suggest X. The intention is for the compiler to suggest it, not tell the user to suggest it, so the correct grammar would be GCC suggests X.) How about ; suggestion: use parentheses or ; suggestion: add the `using' keyword (using whatever convention for quoting code). -miles -- Do not taunt Happy Fun Ball.
Re: Suspicion of regression in uninitialized value detection
Robert Dewar de...@adacore.com writes: The worst thing for me about -O1 is arguments disappearing in the trace back, that's really a deal breaker. Wasn't Alexandre Oliva's VTA work supposed to help this kind of thing...? Did that ever get merged? -miles -- Joy, n. An emotion variously excited, but in its highest degree arising from the contemplation of grief in another.
Re: Implement C1X _Alignas, _Alignof, max_align_t, stdalign.h
BTW, is there a reason that C1X _Alignas is supported, but not C++11 alignas? Is the latter harder? Thanks, -Miles -- Generous, adj. Originally this word meant noble by birth and was rightly applied to a great multitude of persons. It now means noble by nature and is taking a bit of a rest.
Re: Delegating Constructors?
Jason Merrill ja...@redhat.com writes: Hmm, has he been contacted recently? The original patch was from ages ago... Yes, I've been in communication with him and the FSF. I expect this to be sorted out soon so we can put in the patch. Cool, thanks! -miles -- Cynic, n. A blackguard whose faulty vision sees things as they are, not as they ought to be. Hence the custom among the Scythians of plucking out a cynic's eyes to improve his vision.
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
David Brown da...@westcontrol.com writes: If the compiler can generate fractional arithmetic code directly from such expressions, then it is indeed a good step towards implementing such types as a pure C++ class without needing to use compiler extensions. ... I am not saying the compiler couldn't generate optimal code (on a target with hardware support for these operations) out from carefully written generic C++ code - but I do think it would be easier to get good code if the compiler views these types as native. Of course, even if a special compiler representation turns out to be necessary for optimal performance, that doesn't mean that the _syntax_ has to be something wacky (whereas C has little choice). It would be perfectly reasonable to have the public interface be a thin library wrapper around unadvertised builtin types -- and that's probably quite preferable as it would enable a portable pure library solution for compilers that do not contain special support. -Miles -- 「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
Delegating Constructors?
Hi, I'm wondering whether there's been any progress on the recent Delegating Constructors patch: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01202.html The last post on that thread (in gcc-patches) was early last month. There doesn't seem to have been any objection, just minor review-type comments, and it sounded like it was in pretty good shape, but the thread eventually just sort of petered out. Is this likely to go in for 4.7? Thanks, -Miles -- Yorton, Wressle, and Gospel Oak, the richness of your heritage is ended. We shall not stop at you again; for Dr Beeching stops at nothing.
Re: Delegating Constructors?
Ville Voutilainen ville.voutilai...@gmail.com writes: Is this likely to go in for 4.7? As far as I know, all the review comments have been fixed, I posted a patch that fixed the unwanted whitespace changes and such. It's pending copyright paperwork from the author of the original patch. (my copyright paperwork is in order, but since I didn't write all of it, there's some crossing t's and dotting i's). Hmm, has he been contacted recently? The original patch was from ages ago... Thanks, -Miles -- Cynic, n. A blackguard whose faulty vision sees things as they are, not as they ought to be. Hence the custom among the Scythians of plucking out a cynic's eyes to improve his vision.
Re: Option to make unsigned-signed conversion always well-defined?
2011/10/7 Pedro Pedruzzi pedro.pedru...@gmail.com: It is. For example -100 + -100 = -200 (less than INT8_MIN; does not fit). But -1 + -1 = -2, is ok. Ah, now I see... -miles -- Cat is power. Cat is peace.
Re: Long-term plan for C++98/C++11 incompatibility
FWIW, I seem to have no obvious problems compiling with -std=c++0x, and then linking with system c++ libraries that were presumably compiled using default options (e.g., I use the OpenEXR library, which is C++) So if there are incompatibilities, they don't seem to be fatal... -Miles -- Hers, pron. His.
Re: Option to make unsigned-signed conversion always well-defined?
Ulf Magnusson ulfali...@gmail.com writes:
Might as well do
bool overflowbit(unsigned int a, unsigned int b) {
const unsigned int sum = a + b;
return (a ^ b) ~(a ^ sum) 0x80;
}
But still not very good output compared to other approaches as expected.
How about:
bool overflowbit2(unsigned int a, unsigned int b)
{
const unsigned int sum = a + b;
return ~(a ^ b) sum 0x80;
}
?
I thik it has the same results as your function...
[I just made a table of all 8 possibilities, and checked!]
-miles
--
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.
Re: Option to make unsigned-signed conversion always well-defined?
Pedro Pedruzzi pedro.pedru...@gmail.com writes:
On Thu, Oct 6, 2011 at 11:04 AM, Miles Bader mi...@gnu.org wrote:
How about:
bool overflowbit2(unsigned int a, unsigned int b)
{
const unsigned int sum = a + b;
return ~(a ^ b) sum 0x80;
}
Miles, it is not the same. Take for example (0xff, 0xff). In 8-bit
2's complement, this is (-1, -1) and does not overflow. Your
function says it does.
Negative overflow isn't considered overflow...? wacky...
-miles
--
=
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.
Re: Volatile qualification on pointer and data
David Brown david.br...@hesbynett.no writes: So what advantages would there be in declaring a volatile buffer like this to be const? At best, you are helping the compiler check that you don't accidentally write to it in your own code. That's actually pretty handy tho... -Miles -- Everywhere is walking distance if you have the time. -- Steven Wright
Re: g++ 2.5.2 does not catch reference to local variable error.
Jonathan Wakely jwakely@gmail.com writes: g++ -Wall -Wextra ... should flag a warning on the following code but does not. Thanks for the apology, but it should still be reported to bugzilla not to this list. BTW, it should only warn if given -Weffc++, right? -Miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth
Re: g++ 2.5.2 does not catch reference to local variable error.
Jonathan Wakely jwakely@gmail.com writes: No, returning a reference to a local variable is always wrong, not only because Meyers says so. True ... :} -miles -- Apologize, v. To lay the foundation for a future offense.
Re: libgcc: strange optimization
Richard Guenther richard.guent...@gmail.com writes:
But then can't people use a pure assembler stub instead? Without
inlining there isn't much benefit left from writing
void f1(int arg)
{
register int a1 asm(r8) = 10;
register int a2 asm(r1) = arg;
asm(scall : : r(a1), r(a2));
}
instead of
f1:
mov r8, 10
mov r1, rX
scall
ret
in a .s file no? I doubt much prologue/epilogue is needed.
Or even write
void f1(int arg)
{
asm(mov r8, %0; mov r1 %1; scall; : : g(a1), g(a2) : r8, r1);
}
Of course in practice people _do_ want to use it with f1 inlined, where
using reg variables (or alternatively, some expanded constraint language
for the asm parameters) can really get rid of tons of unnecessary asm
moves, and they want the compiler to guard against conflicts.
-Miles
--
Whatever you do will be insignificant, but it is very important that
you do it. Mahatma Gandhi
Re: Assignment Operator Bug
Mactavish mdtabisha...@gmail.com writes:
I have compiled this code in MS Visual C++ Express 2008 and it works as
it should be but when i compile this code in Mingw as a part of GCC ver
4.4.1-2 the input() function should return a temporary object to 'ob'
object and invoke the assignment operator '=' but it doesn't and it
shows me error :no match for 'operator=' in 'ob=input()()'
This is the wrong mailing list for this question (the list is for gcc
development). A better list would be gcc-h...@gcc.gnu.org or maybe
the comp.lang.c++ newsgroup.
As to your problem, I think it's a bug in your program (and a bug in
VC++ that it accepts it). Later versions of gcc give a more
explanatory error message, which make the reason more obvious:
$ g++-4.6 -c s.cc
s.cc: In function ‘int main()’:
s.cc:63:14: error: no match for ‘operator=’ in ‘ob = input()()’
s.cc:63:14: note: candidate is:
s.cc:46:8: note: sample sample::operator=(sample)
s.cc:46:8: note: no known conversion for argument 1 from ‘sample’ to
‘sample {aka sample}’
Temporary objects can't be passed as non-const references.
You can fix it by changing the argument type of sample::operator= to
be const sample instead of sample .
-Miles
--
One of the lessons of history is that nothing is often a good thing to
do, and always a clever thing to say. -- Will Durant
Re: temporarily giving up using Git for GCC MELT
On Sun, Feb 27, 2011 at 11:19 PM, Frank Ch. Eigler f...@redhat.com wrote: Miles Bader mi...@gnu.org writes: Do you use the http: or git: protocol for cloning? The official gcc git repo only supports the old git http: protocol, which is almost useless on slow/high-latency networks... gcc.gnu.org does talk git:// too. Right; I meant, over http:, it only supports the old protocol. By new http, you are probably referring to the git-http-backend widget, which we can investigate setting up. Yes http://progit.org/2010/03/04/smart-http.html -Miles -- Cat is power. Cat is peace.
Re: temporarily giving up using Git for GCC MELT
Basile Starynkevitch bas...@starynkevitch.net writes: PS. By the way, git clone-ing the GCC git repository takes a lot of time from Europe. Perhaps having a daily tar ball of the result of that command available by ftp would be very nice Do you use the http: or git: protocol for cloning? The official gcc git repo only supports the old git http: protocol, which is almost useless on slow/high-latency networks... [There's also a github mirror, and github supports the smart http: protocol: https://github.com/mirrors/gcc.git ] -Miles -- Consult, v.i. To seek another's disapproval of a course already decided on.
Re: GCC 4.6 performance regressions
Jonathan Wakely jwakely@gmail.com writes: Because phoronix uses make -j the compile times are highly random. Don't they know how to use 'time' to measure something more useful? I wouldn't be entirely surprised, last time I looked they didn't seem to know to use --enable-checking=release when comparing compile time of snapshots against releases. While I appreciate Phoronix as a booster site, their benchmarking practice often seems very dodgy; I'd take the results with a large grain of salt -miles -- .Numeric stability is probably not all that important when you're guessing.
Re: Proposal for automatic generation of c++ header files
Achilleas Margaritis axil...@gmail.com writes: So, if the compiler checks the code, and the documentation says whatever must be said about the program, headers are completely redundant. I think this is often/usually not true in practice though. It seems _far_ more common for there to be reasonable header files than for there to be reasonable documentation (in part because much documentation is not actually reasonable). With a module language, one can read the actual source files instead the headers, of course, but this is often much more difficult than reading the header files, because there's _too_ much (usually irrelevant) information in the source files... This could be helped by, for instance, a tool that automatically hid most of a source file for browsing purposes, showing only exported interfaces, but I'm not sure it's good to assume such a thing. [My main complaint about C/C++ header files would not be the redundancy of the interface declarations, but rather that they contain too much private information that should really be hidden to users of the interface, and so make reading the interface more complicated (similar to reading the actual source file).] -Miles -- Laughter, n. An interior convulsion, producing a distortion of the features and accompanied by inarticulate noises. It is infectious and, though intermittent, incurable.
Re: Committed Go frontend
Ian Lance Taylor i...@google.com writes: As I just mentioned on the gcc-patches mailing list, I have just committed the Go frontend to mainline. What's the name of the resulting compiler binary? ggo? -Miles -- Opposition, n. In politics the party that prevents the Goverment from running amok by hamstringing it.
Re: new requirement of constexpr for static const float data members is too restrictive
On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: If you are doing that, why don't you write a simpler code by just defining (e.g. initializing) the data member outside the class? 'cause I want the compiler to be able to use (inline) the underlying values. -Miles -- Cat is power. Cat is peace.
Re: new requirement of constexpr for static const float data members is too restrictive
Gabriel Dos Reis g...@integrable-solutions.net writes: If you are doing that, why don't you write a simpler code by just defining (e.g. initializing) the data member outside the class? 'cause I want the compiler to be able to use (inline) the underlying values. then write even simple code: dispense with the class stuff and use bona fide `const float' at namespace scope. It works with all compilers and all versions of GCC/g++. Right, but I want it in the class namespace. I.e., I can choose between various types of ugliness -- wrong namespace, funny syntax, or (currently) gcc-dependence. I used to choose gcc- dependence, but then switched to funny syntax. In the future when c++0x support is more widespread, of course, I won't have to make such an annoying choice any more... -Miles -- XML is like violence. If it doesn't solve your problem, you're not using enough of it.
Re: new requirement of constexpr for static const float data members is too restrictive
Gabriel Dos Reis g...@integrable-solutions.net writes: I.e., I can choose between various types of ugliness -- wrong namespace, funny syntax, or (currently) gcc-dependence. I used to choose gcc- dependence, but then switched to funny syntax. In the future when c++0x support is more widespread, of course, I won't have to make such an annoying choice any more... hmm, that sounds like an awful lot of effort put into something that looked to me as simple code to write using standard functionalities. Though I have to confess I do not understand why the class must be right and the namespace must be wrong. (Maybe I have not seen the real code, I don't know.) Exactly. Which is right or acceptable depends on the details and programming style, and is subjective to some degree. Anyway, what's important is whether existing code _may_ have chosen to use this gcc feature, and may not consider pre-c++0x alternatives palatable. The point was made that this feature was already deprecated -- but I think given that a more-palatable option will be available in c++0x[*], it would be nice to give users a certain amount of overlap during which both the old (deprecated) and new features are both supported. That would suggest keeping this feature for a while still... [If there were no such c++0x feature coming, I guess it would matter less when the deprecation actually changed to removal.] [*] more palatable because only definitions need be updated, not uses, all attributes of the existing gcc-only code are maintained (inheritance by subclasses, etc), and there's no need for a change in programming style. -Miles -- Learning, n. The kind of ignorance distinguishing the studious.
Re: new requirement of constexpr for static const float data members is too restrictive
Richard Guenther richard.guent...@gmail.com writes:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?
'cause I want the compiler to be able to use (inline) the underlying values.
I think it'll do that with initializing the member outside of the class as
well.
struct X { static float const v; };
const float X::v = 1;
int main()
{
return (int)X::v;
}
That'll work if you only have one file ... but the only way that
definition of X::v would be visible to many users in a typical prog is
if it were in a header file -- and then you'll get a mulitple-definition
error for X::v when linking
-miles
--
Justice, n. A commodity which in a more or less adulterated condition the
State sells to the citizen as a reward for his allegiance, taxes and personal
service.
Re: new requirement of constexpr for static const float data members is too restrictive
On Tue, Nov 30, 2010 at 11:40 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: I agree. I think we have a case here where people will say anything to justify a (mis)feature that leads to brittle codes Why does it lead to brittle codes? If people are worried about multiple translation units, they will still have to provide a definition outside the class -- most likely Why? Certainly as in my experience, that's not true. In C++ static const is a way of defining constants, and the fact that integral class constants were allowed whereas floating-point class constants were not was just a wart. It's nice that c++0x has fixed this wart, but there was nothing wrong with gcc's different method of doing so, beyond its lack of portability. -Miles -- Cat is power. Cat is peace.
Re: new requirement of constexpr for static const float data members is too restrictive
Ian Lance Taylor i...@google.com writes: We could decide not to do anything about this, but I don't think it's a non-issue. With -std=gnu++98 g++ accepts this invalid code. That is, it is a g++ extension, and the code is properly rejected with -pedantic-errors. We could decide to carry the extension forward to -std=gnu++0x. Or we could decide to carry the extension forward to -std=gnu++0x when -fpermissive is used. Or we could decide to just drop the extension. The main problem with the last option is that it complicates the migration of existing gnu++98 programs to gnu++0x. It becomes necessary to add constexpr to use gnu++0x. Unfortunately, gnu++98 rejects constexpr. So there is no simple way to modify this program to be both valid gnu++98 and valid gnu++0x. That makes the transition more difficult. It seems to me that it would be better for our users to accept this code in gnu++0x mode with -fpermissive. I agree. I used to use this feature a lot, and indeed that was the primary reason I _didn't_ use -pedantic-errors. It's nice that C++0x has an official way to support this feature (it seems very silly that C++98 didn't), but there are surely many projects that don't want to commit to C++0x just yet. [Recently I went through and changed all my uses of static const float fields to use inline static methods instead, which is at least portable, but yuck, how ugly is that...] BTW, if it's decided that `-fpermissive' should be necessary, I think the error message should note that ... -Miles -- Once, adj. Enough.
Re: GFDL/GPL issues
Florian Weimer f...@deneb.enyo.de writes: Duplication is how other GNU projects handle this. For instance, many Emacs Lisp functions are documented twice: once as a docstring in the source code (which is roughly equivalent to the comment-in-spec approach), and once in the Elisp reference (which is GFDLed). Well probably we can all agree that such duplication is undesirable, unless it is automated, since documentation can get out of sync. There's a school of thought that claims that things need to be described at least twice, both formally and informally. I don't think these people mean code and documentation, but rather two forms of documentation. With elisp, I've found that in practice I usually start by copying the docstring (the in code doc) to the manual (the doc doc), but almost always end up largely rewriting to fit the context in the manual better, and to explain things in more detail (modern docstrings tend to be rather verbose compared to docstrings-of-old, but they're still generally more terse than the manual). What this says, I dunno; it'd be nice to have the freedom to just do whatever's best, of course... -Miles -- Neighbor, n. One whom we are commanded to love as ourselves, and who does all he knows how to make us disobedient.
Re: GFDL/GPL issues
Robert Dewar de...@adacore.com writes: I am actually a bit dubious about automatic extraction of documentation from code. The kind of thing you can get this way is in any case easily obtained by browsing the code. Presumably it saves the effort of browsing the code, which is not a small thing... (If I'm learning about an interface, I want a concise introduction to the functions in it, and the work of finding the appropriate functions in the appropriate location in the appropriate file can be pretty annoying). Moreover, it such extraction can to improve the source code for browsing too: if a function's header-comment were actually included in the documentation (suitably massaged), that's all the more incentive to write really good and clear function header-comments... -Miles -- The car has become... an article of dress without which we feel uncertain, unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964]
Re: GFDL/GPL issues
Ian Lance Taylor i...@google.com writes: Please move such unconstructive arguments elsewhere. Wait. Steven's comment was on the snarky side, but coming from a long-time gcc contributor I don't think it was over the line or even near it. I think he was expressing a perfectly valid point of view considering the constraints that the FSF places on gcc developers. For certain aspects of gcc, generating documentation from code makes all kinds of sense. The fact that the FSF is preventing us from doing that is a real problem. It's not a critical problem, but it's one in a line of real problems. I think it'd be a lot more palatable if there were at least some justification given for ignoring the request -- but at least the way Mark stated it, rms was just dismissive. -Miles -- Do not taunt Happy Fun Ball.
Re: GFDL/GPL issues
Mark Mitchell m...@codesourcery.com writes: I agree that we are likely to get more traction with a request to dual license as opposed to re-license. Well, I've asked -- but RMS shot down that idea. Did he give reasons, and/or indicate any other possible methods to use? -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT]
Re: C++0x Memory model and gcc
Andrew MacLeod amacl...@redhat.com writes: -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right? -Miles -- Road, n. A strip of land along which one may pass from where it is too tiresome to be to where it is futile to go.
Re: C++0x Memory model and gcc
Andrew MacLeod amacl...@redhat.com writes: -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right? Right. Its just a single processor memory model, so it doesn't limit any optimizations. Hmm, though now that I think about it, I'm not exactly sure what I mean by explicit synchronization. Standard libraries (boost threads, the upcoming std::thread) provide things like mutexes and conditional-variables, but does using those guarantee that the right things happen with any shared data-structures they're used to coordinate...? Thanks, -Miles -- Vote, v. The instrument and symbol of a freeman's power to make a fool of himself and a wreck of his country.
Re: Code assistance with GCC
Chris Lattner clatt...@apple.com writes: I did this because the other responses made it seem that it wasn't something that would be accepted back into GCC proper. Maintaining an Can you point at any response that said it would not be accepted back into GCC proper? There were no such comments AFAIK. All that has been said is that it is not possible to implement it AS A PLUGIN, Nope, you are correct. Again, the cc was a mistake and I apologize for it. But people aren't objecting to the CC, they're objecting to the message you were (apparently) trying to send to the original poster. If anything, the CC was _good_, because it allowed some measure of debate. -Miles -- Fast, small, soon; pick any 2.
Re: updated code size comparison
John Regehr reg...@cs.utah.edu writes: I've updated the code size results here: http://embed.cs.utah.edu/embarrassing/dec_09/ The thing that bothers me about this is that you seem to put a lot of emphasis on the test X generated larger code than Y without any reflection of how much larger (it could be 1 byte, it could be 50 times). Moreover, aggregating those boolean results to yield things like X generated larger code than Y NN% of the time seems even weirder. Is this really useful information, other than for marketing? -Miles -- Vote, v. The instrument and symbol of a freeman's power to make a fool of himself and a wreck of his country.
Re: Should -Wjump-misses-init be in -Wall?
Gabriel Dos Reis dosr...@gmail.com writes:
Historically, many C programmers have resisted that idea (even when we could
argue that it really is bad style programming.)
They have?(!)
This warning warns about: goto L; { int x = 3; L: ... }
but not about: goto L; { int x; L: ... }
right?
So... is the idea that there might be code that assigns to x after L:,
before the first use of x, making the warning superfluous?
-Miles
--
Twice, adv. Once too often.
Re: LLVM as a gcc plugin?
Chris Lattner clatt...@apple.com writes: Some time ago, there was a discussion about integrating LLVM and GCC [1]. However, with plugin infrastructure in place, could LLVM be plugged into GCC as an additional optimization plugin? I'd love to see this, but I can't contribute to it directly. I think the plugin interfaces would need small extensions, but there are no specific technical issues preventing it from happening. LLVM has certainly progressed a lot since that (really old) email went out :) Is there a description somewhere of areas where llvm is thought to do well compared to gcc, and maybe future plans for improvement? In the (limited) tests I've done, gcc [4.4, but 4.2 yields similar results] seems to do a lot better than llvm [2.5], but those were C++ code and I wonder if llvm is currently concentrating on C? -Miles -- Quotation, n. The act of repeating erroneously the words of another. The words erroneously repeated.
Re: GCC 4.5: nonconstant array index in initializer error
Joe Buck joe.b...@synopsys.com writes: The compiler is not supposed to be pedantic by default. A standards document saying that a diagnostic is required should not be the end of the story, especially when we're talking about important, widely used code bases. Sure, but at least your example code seems pretty dodgy -- it would be quite reasonable to argue that even a compiler in practical mode (as opposed to pedantic mode) should reject it. -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche
combine register note problem with multi-word values
When `try_combine' combines two instructions, it adds the register notes from the old insns to the new combined insn. It also adds new register notes calculated from the new insn's clobbers by `recog_for_combine'. In this process, it (`distribute_notes') suppresses duplicate register notes, but in doing so, seems to basically ignore the mode used in the notes' REG expressions -- so if the new note really refers to multiple registers because the mode is larger than word size, and the old note does _not_ (but does refer to the same starting register), then the result will only contain the register note for the smaller value. Since the new notes calculated by `recog_for_combine', which contain precise information from the new insn's clobbers, are added _last_, it seems as if this may result in incorrect register notes. Would it be OK to add the new reg notes calculated from clobbers first, before the notes from the old insns? Thanks, -Miles -- Come now, if we were really planning to harm you, would we be waiting here, beside the path, in the very darkest part of the forest?
Re: reload question
Ian Lance Taylor ian@airs.com writes: I agree that gcc is not well designed to cope with an accumulator architecture. Reload can't cope. I've had a fair amount of success with the approach I initially posted (perturbing the emission order of reloads based on dependencies between the operand they are associated with). It's still pretty fragile in the sense that even a tiny mistake in something like the constraints will cause reload to barf, but I guess that's to be expected. The code produced seems pretty reasonable too (with almost no peepholes at all); for instance it will allocate a variable to the accumulator in the odd case where that's possible. [I don't know if this is the sort of thing that's viable for merging into standard gcc, but maybe a simpler approach based on a backend hook or something would be.] I gotta admit though, by now I thoroughly hate the gcc reload code... -Miles -- ((lambda (x) (list x x)) (lambda (x) (list x x)))
Re: reload question
BTW, if anybody replies, could you keep me in the CC: header? I do read this list, but it won't be convenient in the next few days. Thanks, -Miles -- .Numeric stability is probably not all that important when you're guessing.
Re: reload question
Bernd Schmidt [EMAIL PROTECTED] writes:
Reload insns aren't themselves reloaded. You should look at the
SECONDARY_*_RELOAD_CLASS; they'll probably let you do what you want.
Ah, thank you!
I've defined SECONDARY_*_RELOAD_CLASS (and PREFERRED_* to try to help
things along), and am now running into more understandable reload
problems: unable to find a register to spill in class :-/
The problem, as I understand, is that reload doesn't deal with conflicts
between secondary and primary reloads -- which are common with my arch
because it's an accumulator architecture.
For instance, slightly modifying my previous example:
Say I've got a mov instruction that only works via an accumulator A,
and a two-operand add instruction. r regclass includes regs A,X,Y,
and a regclass only includes reg A.
mov has constraints like: 0 = g,a 1 = a,gi
and add3 has constraints: 0 = a 1 = 02 = ri (say)
So if before reload you've got an instruction like:
add temp, [sp + 4], [sp + 6]
and v2 and v3 are in memory, it will have to have generate something like:
mov A, [sp + 4]; primary reload 1 in X, with secondary reload 0 A
mov X, A ;
mov A, [sp + 6]; primary reload 2 in A, with no secondary reload
add A, X
mov temp, A
There's really only _one_ register that can be used for many reloads, A.
The problem is that reload doesn't seem to be able to produce this kind of
output: if it chooses A as a primary reload (common, as most insns use A as
a first operand), reload will think it conflicts with secondary reloads that
also use A (when it really needn't, as the secondary reloads only use A
temporarily). This is particularly bad with RELOAD_OTHER reloads, as
I kludged around this to some degree by changing `reload_conflicts'
(reload1.c) to always think secondary reloads _don't_ conflict [see patch1].
As that will fail in the case where a primary reload is loaded before a
secondary reload using the same register, I _also_ modified
`emit_reload_insns' to sort the order in which operand reloads are output so
that an operand who's secondary reload interferes with another operand's
primary reload is always loaded first.
However I think this is not guaranteed to always work -- certainly merely
disregarding conflicts with secondary reloads will fail for architectures
which are slightly less anemic, say with _two_ accumulators... :_)
Does anybody have a hint for a way to solve this problem?
Reload is very confusing...
Thanks,
-Miles
= patch1 =
--- gcc-3.4.3/gcc/reload1.c 2004-05-02 21:37:17.0 +0900
+++ gcc-3.4.3-supk0-20050317/gcc/reload1.c 2005-03-17 19:49:35.935534000
+0900
@@ -1680,7 +1688,7 @@ find_reg (struct insn_chain *chain, int order)
{
int other = reload_order[k];
- if (rld[other].regno = 0 reloads_conflict (other, rnum))
+ if (rld[other].regno = 0 reloads_conflict (other, rnum, 0))
for (j = 0; j rld[other].nregs; j++)
SET_HARD_REG_BIT (used_by_other_reload, rld[other].regno + j);
}
@@ -4601,18 +4609,25 @@
}
/* Return 1 if the reloads denoted by R1 and R2 cannot share a register.
- Return 0 otherwise.
+ Return 0 otherwise. If SECONDARIES_CAN_CONFLICT is zero, secondary
+ reloads are considered never to conflict; otherwise they are treated
+ normally.
This function uses the same algorithm as reload_reg_free_p above. */
int
-reloads_conflict (int r1, int r2)
+reloads_conflict (int r1, int r2, int secondaries_can_conflict)
{
enum reload_type r1_type = rld[r1].when_needed;
enum reload_type r2_type = rld[r2].when_needed;
int r1_opnum = rld[r1].opnum;
int r2_opnum = rld[r2].opnum;
+ /* Secondary reloads need not conflict with anything. */
+ if (!secondaries_can_conflict
+ (rld[r1].secondary_p || rld[r2].secondary_p))
+return 0;
+
/* RELOAD_OTHER conflicts with everything. */
if (r2_type == RELOAD_OTHER)
return 1;
= patch2 =
--- gcc-3.4.3/gcc/reload1.c 2004-05-02 21:37:17.0 +0900
+++ gcc-3.4.3-supk0-20050317/gcc/reload1.c 2005-03-17 19:49:35.935534000
+0900
@@ -6951,6 +6966,51 @@ emit_reload_insns (struct insn_chain *chain)
do_output_reload (chain, rld + j, j);
}
+#ifdef SECONDARY_INPUT_RELOAD_CLASS
+ for (j = 0; j reload_n_operands; j++)
+opnum_emit_pos[j] = emit_pos_opnum[j] = j;
+
+ /* Order the operands to avoid conflicts between the primary reload of
+ one operand and a secondary reload in another operand (which we
+ ignored before). XXX this only works for input reloads!! */
+ for (j = 0; j n_reloads; j++)
+if (rld[j].secondary_p)
+ /* This is a secondary reload; see if it should go before something
+else. */
+ {
+ int i;
+ int this_opnum = rld[j].opnum;
+ int cur_emit_pos = opnum_emit_pos[this_opnum];
+ int new_emit_pos = cur_emit_pos;
+
+ for (i = j; i = 0; i--)
+
Re: Merging calls to `abort'
Dave Korn [EMAIL PROTECTED] writes: I very strongly feel that this optimisation should be placed under user control rather than just disabled, and that it should remain enabled by default at -Os; but I wouldn't go to the ropes over whether or not it's included in -Os as long as there's a -f that will allow me to switch it back on. I don't think there's been any argument about that -- of course it will be user-controllable. The question is what the default should be. I think that a deeply embedded system that uses abort() is not the common case for gcc, and so the defaults shouldn't cater to it; maybe you're right that the use of -Os is a reasonable hint though. -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson
reload question
Hi, I'm writing a new gcc port, and having problems making reload work. Say I've got a mov instruction that only works via an accumulator A, and a two-operand add instruction. r regclass includes regs A,X,Y, and a regclass only includes reg A. So mov has constraints like: 0 = g,a 1 = a,gi and add3 has constraints: 0 = r 1 = 02 = i (say) Then if there's an insn before reload like: add3 X, Y, 1 Reload will notice this, and generate a reload to put Y into X, so you'll end up with: mov X, Y add3 X, X, 1 That seems to be happening correctly. Now, what I _expected_ to happen is that reload would then be repeated to handle the newly added mov insn, which would see that the mov insn's constraint don't match, and would then generate an additional reload to yield: mov A, Y mov X, A add3 X, X, 1 but in fact this final step doesn't seem to be happening -- it just finishes reload without changing the bogus mov X, Y insn and goes on to die with an insn does not satisfy its constraints: error in final. I've been trying to track through reload seeing what it's doing, but my mind is being twisted into little knots, and I'd really like to at least know if what I think should be happening is accurate. Any hints? Thanks, -Miles -- .Numeric stability is probably not all that important when you're guessing.
