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: GIt Issue
"Iyer, Balaji V" 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: GCC cannot move address calculation to store+load?
Richard Biener 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): : 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): : 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 : > 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 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 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 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: Renaming Stage 1 and Stage 3
Richard Guenther 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: How to compare two text files? Using sed, cmp, diff, tr?
Joern Rennecke 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: Should gcc give warning for this case?
Qun-Ying 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 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: RFC: -Wall by default
Robert Dewar 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: Switching to C++ by default in 4.8
Ian Lance Taylor 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: Switching to C++ by default in 4.8
Torvald Riegel 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
Andrew Haley 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: RFC: -Wall by default
2012年4月10日15:26 Eric Botcazou :
>> 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
Dave Korn 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
James Cloos 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
Miles Bader 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: RFC: -Wall by default
Robert Dewar 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
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: Switching to C++ by default in 4.8
Ian Lance Taylor 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: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Pedro Alves 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: gcc extensibility
Bernd Schmidt 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 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 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 a<<35"and 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 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 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 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" 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: 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 -- 「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
Re: non-virtual-destructor warnings redux
2011/12/24 Jonathan Wakely :
> 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.
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: NSDMI bug?
k, bugzilla'd thanks, -miles -- Cat is power. Cat is peace.
NSDMI bug?
Is the following code valid?
#include
struct X
{
std::tuple tt{1, 2}; // works
};
struct Y
{
std::tuple tt = std::tuple{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: Suspicion of regression in uninitialized value detection
Robert Dewar 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: Delegating Constructors?
Jason Merrill 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 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 -- 「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
Re: Delegating Constructors?
Ville Voutilainen 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.
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: 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?
2011/10/7 Pedro Pedruzzi : > 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: Option to make unsigned->signed conversion always well-defined?
Pedro Pedruzzi writes:
> On Thu, Oct 6, 2011 at 11:04 AM, Miles Bader 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: Option to make unsigned->signed conversion always well-defined?
Ulf Magnusson 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: Volatile qualification on pointer and data
David Brown 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 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: g++ 2.5.2 does not catch reference to local variable error.
Jonathan Wakely 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: libgcc: strange optimization
Richard Guenther 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 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 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 wrote: > Miles Bader 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 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 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 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 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 11:40 PM, Gabriel Dos Reis 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
Richard Guenther 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
Gabriel Dos Reis 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
Gabriel Dos Reis 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
On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis 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
Ian Lance Taylor 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 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 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 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 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 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: C++0x Memory model and gcc
Andrew MacLeod 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: Code assistance with GCC
Chris Lattner 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 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 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 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 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 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 = "0"2 = "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;
+
+
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 = "0"2 = "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.
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
