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 arr
"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.
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/
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 imp
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
--
「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
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 inte
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
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.
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 e
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 pro
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 kn
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 to
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
i
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
> ad
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-wa
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 _remov
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
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 m
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 bett
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
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 w
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-buildd
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.
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 save
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
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.
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:
>
>
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
-
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.
"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
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
--
「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
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/cha
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
r
k, bugzilla'd
thanks,
-miles
--
Cat is power. Cat is peace.
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:
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
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 vis
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 opt
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
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
com
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
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.
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;
>> }
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(unsigne
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 distanc
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.
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 casu
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));
> }
>
> i
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
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 networ
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
r
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 co
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 fi
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 hamstri
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 st
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 memb
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
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 c
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. C
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 fo
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 G
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 lear
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
> cons
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
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 si
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
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 AFAI
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 b
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
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
> th
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
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 i
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 asso
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.
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 runni
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 = "
"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'
77 matches
Mail list logo
