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: [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: 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: [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: [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: 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: 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.
