Change of email address
I'm changing to something more permanent and in my control, this is just a notice about it to make sure it goes smoothly. Have a good weekend. I'm going from a.teal then a big a-t sign warwick.ac.uk to alec AT unified then mathematics dot com Alec
Re: Good news, bad news on the repository conversion
I have no idea what order messages are in now because I wasn't CCed into this (so was it before?) but it may not be much money. It depends how long you need it for. Presumably someone's mentioned swapspace too... Anyway do let me know, I don't check the mailing lists as often as I'd like and the junk mail filter is very eager. Alec On 11/07/18 05:29, Eric S. Raymond wrote: Mark Atwood : ESR, how much for the memory expansion? It sounds like we have some volunteers to solve this problem with some money. That's now rthe second problem out. There's a malformation that has turned up in the repo that may sink the conversion entirely. I want to be reasonably sure I can solve that before I go asking for money.
Re: Good news, bad news on the repository conversion
Is this still an issue? (I missed the convo due to an overzealous spam filter; this is the only message I have) I often use AWS Spot instances (bidding on instances other people previsioned but put up for auction as it's not always needed) to get results extremely quickly without hearing a fan or to test changes on a "large" system. What do you need and how long (roughly, eg days, hours...)? https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose-instances.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/memory-optimized-instances.html Take your pick. m4.16xlarge is 64 cores and 256Gib of RAM, x1e.16xlarge 64 cores, just shy of 2 Tb of ram, x1e.32xlarge is 128 cores and 3.9 Tb of Ram Alec PS: Migrating what to what? Wasn't the git migration done years ago? Remember I only have the quoted message! On 09/07/18 21:03, Eric S. Raymond wrote: Florian Weimer : * Eric S. Raymond: The bad news is that my last test run overran the memnory capacity of the 64GB Great Beast. I shall have to find some way of reducing the working set, as 128GB DD4 memory is hideously expensive. Do you need interactive access to the machine, or can we run the job for you? If your application is not NUMA-aware, we probably need something that has 128 GiB per NUMA node, which might be bit harder to find, but I'm sure many of us have suitable lab machines which could be temporarily allocated for that purpose. I would need interactive access. But that's now one level way from the principal problem; there is somme kind of recent metadata damage - or maybe some "correct" but weird and undocumented stream semantics that reposurgeon doesn't know how to emulate - that is blocking correct conversion.
Alignas broken when used with constexpr array data member for structure
Hi there,
In GCC 4.8.4 I have something like the following:
constexpr int x = 5;
constexpr int y = 4;
struct alignas(y) my_data_block {
char data[x];
};
And it causes some weird errors to the tune of "size of array ‘data’ is
not an integral constant-expression" in the presence of the alignas
This is a pretty nasty bug and means it's not implemented as I thought.
I don't know the front-ends (but I do actually know GIMPLE-low and below
quite well, love the pattern matching) and I'd like to dig more, it's
almost certainly fixed - this is just for personal curiosity.
Where would I look? A 1 line reply with a directory would be a great
start; even if it's just a guess.
I did ask in #gcc on freenode - it didn't go so well, sorry to ping you
all for this.
Alec
Re: GCC version bikeshedding
On 20/07/14 22:28, Andi Kleen wrote: Paulo Matos writes: That's what I understood as well. Someone mentioned to leave the patch level number to the distros to use which sounded like a good idea. Sounds like a bad idea, as then there would be non unique gcc versions. redhat gcc 5.0.2 potentially being completely different from suse gcc 5.0.2 Agreed (no experience, but I wouldn't want to live in a world where what Andi describes is the case!) -Andi What is "Bikeshedding"? I've not heard this term before and a quick search showed some weird things, and this very thread! Alec
Re: [RFC][PATCH 0/5] arch: atomic rework
On 17/02/14 20:18, Linus Torvalds wrote:
On Mon, Feb 17, 2014 at 11:55 AM, Torvald Riegel wrote:
Which example do you have in mind here? Haven't we resolved all the
debated examples, or did I miss any?
Well, Paul seems to still think that the standard possibly allows
speculative writes or possibly value speculation in ways that break
the hardware-guaranteed orderings.
And personally, I can't read standards paperwork. It is invariably
Can't => Don't - evidently.
written in some basically impossible-to-understand lawyeristic mode,
You mean "unambiguous" - try reading a patent (Apple have 1000s of
trivial ones, I tried reading one once thinking "how could they have
phrased it so this got approved", their technique was to make the reader
want to start cutting themselves to prove they wern't numb to everything)
and then it is read by people (compiler writers) that intentionally
try to mis-use the words and do language-lawyering ("that depends on
what the meaning of 'is' is"). The whole "lvalue vs rvalue expression
vs 'what is a volatile access'" thing for C++ was/is a great example
of that.
I'm not going to teach you what rvalues and lvalues, but!
http://lmgtfy.com/?q=what+are+rvalues might help.
So quite frankly, as a result I refuse to have anything to do with the
process directly.
Is this goodbye?
Linus
That aside, what is the problem? If the compiler has created code that
that has different program states than what would be created without
optimisation please file a bug report and/or send something to the
mailing list USING A CIVIL TONE, there's no need for swear-words and
profanities all the time - use them when you want to emphasise
something. Additionally if you are always angry, start calling that
state "normal" then reserve such words for when you are outraged.
There are so many emails from you bitching about stuff, I've lost track
of what you're bitching about you bitch that much about it. Like this
standards stuff above (notice I said stuff, not "crap" or "shit").
What exactly is your problem, if the compiler is doing something the
standard does not permit, or optimising something wrongly (read: "puts
the program in a different state than if the optimisation was not
applied") that is REALLY serious, you are right to report it; but
whining like a n00b on Stack-overflow when a question gets closed is not
helping.
I tried reading back though the emails (I dismissed them previously) but
there's just so much ranting, and rants about the standard too (I would
trash this if I deemed the effort required to delete was less than the
storage of the bytes the message takes up) standardised behaviour is
VERY important.
So start again, what is the serious problem, have you got any code that
would let me replicate it, what is your version of GCC?
Oh and lastly! Optimisations are not as casual as "oh, we could do this
and it'd work better" unlike kernel work or any other software that is
being improved, it is very formal (and rightfully so). I seriously
recommend you read the first 40 pages at least of a book called
"Compiler Design, Analysis and Transformation" it's not about the
parsing phases or anything, but it develops a good introduction and
later a good foundation for exploring the field further. Compilers do
not operate on what I call "A-level logic" and to show what I mean I use
the shovel-to-the-face of real analysis, "of course 1/x tends towards 0,
it's not gonna be 5!!" = A-level logic. "Let epsilon > 0 be given, then
there exists an N" - formal proof. So when one says "the compiler
can prove" it's not some silly thing powered by A-level logic, it is the
implementation of something that can be proven to be correct (in the
sense of the program states mentioned before)
So yeah, calm down and explain - no lashing out at standards bodies,
what is the problem?
Alec
Re: Jump threading in tree dom pass prevents if-conversion & following vectorization
Hey, What is jump threading? I've not heard of it before ( http://en.wikipedia.org/wiki/Jump_threading is basically the description of the compiler flag ) Alec On 22/11/13 19:06, Bingfeng Mei wrote: I understand what jump threading does. In theory it reduces number of instructions executed. But it creates messy program structure and prevents further optimizations, at least for target we have (VLIW-based DSP with predicated execution). I just ran through 8 audio codecs we use as internal benchmark. 5 out of 8 codecs have similar performance with/without jump threading (give or take 0.1-0.2%). For the other 3, no jump threading version outperforms by 1-2.5%. I didn't even enable -ftree-vectorize. I am going to do some further investigation and check whether if-conversion can be fixed without disabling jump threading. Bingfeng -Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: 22 November 2013 17:17 To: Bingfeng Mei; Andrew Pinski; Richard Biener Cc: gcc@gcc.gnu.org Subject: Re: Jump threading in tree dom pass prevents if-conversion & following vectorization On 11/22/13 10:13, Bingfeng Mei wrote: So if we are about to fix this in if-conversion, we need to do both in tree & rtl as both ifcvt & ce passes cannot handle it. I am still not convinced jump threading is good for target with predicated execution (assuming no fix for if-conversion). I am doing benchmarking on our target now. I'd be quite surprised if your tests show that it's not beneficial. In simplest terms jump threading identifies conditional branches which can have their destination statically determined based on the path taken to the static branch. And more generally, we try *real* hard not to start enabling/disabling tree passes on a per-target basis. The end result if we were to start doing that is an unmaintainable mess. Jeff
Re: [RFC] Replace Java with Go in default languages
Could we change the subject for responses to this strand of the debate? Alec On 20/11/13 20:27, Basile Starynkevitch wrote: On Wed, 2013-11-20 at 11:45 -0800, Ian Lance Taylor wrote: On Wed, Nov 20, 2013 at 8:45 AM, Alec Teal wrote: It was said before (when this first started) that Go wasn't ready. Another language that looks cool but has yet to mature. Side issue clarification. I believe that Go is ready for any use one might care to put it to. The reasons I believe it is not suitable as a default-enabled language for GCC have to do with licensing and source code issues, not with the language or the compiler support for it. Thanks for the point. Ian, could you explain more what you mean by "source code issues". From my non-native English speaker point of view, I'm understanding "software quality" (i.e. bugs) which is not what you seems to mean. BTW, I am rather in favor of Go becoming more used and perhaps default-enabled (just because I like the language and I trust your work on Go in GCC; the one major thing I miss in Go is dynamic loading à la dlopen). Regards.
Re: Great example of why "everything is a tree" sucks
On 13/11/13 17:32, Jeff Law wrote: On 11/13/13 03:15, Richard Biener wrote: You know - 'tree's were a design decision (well, just my guess - I wasn't around 25 years ago ...). They are a perfect match to represent an AST. So I'd say whoever introduced that middle-end between the FEs AST and RTL was at fault :P (luckily I wasn't around either ... ;)) Yea, you can blame Diego, Andrew and myself largely for the decision to re-use trees in gimple. Reusing trees was a conscious decision made in large part because doing something different for the middle end would have been more work than we could justify at the time. We would have had to do all the things we're doing now, back then to get it "right". The only difference is now we've got a lot more gimple bits that know about trees than we did early in the early gimple/ssa days. I don't think blame is the right word, it was a different era, we now have more ram than could be imagined "back then" and as you say at the time it made sense. I like to think there are a few eras, you had the start, single processor, limited speed, limited ram, then processors got a lot faster (the mhz wars lasted a long time) but still not much ram, then today, buying ram by the 2gb stick usually in pairs is the lowest form you can commonly get (1gb sticks are rare) with processors able to do a huge amount very quickly, parallel stuff doesn't really apply to GCC. Anyway that tangent done with, each era changes software, you started with the undefined behavior wizards/gods then came the era where storing huge programs could actually be done, the "backing store" wasn't measured in kb any more, and so forth. I fear we have entered the era of crap, software doing the same or less with more resources, the era of the cloud (The next version of eclipse is browser based, with the motto "code.anywhere=true;", part of me died) and HTML 5 and other such nonsense. Caja (Nautilus fork within MATE) implemented copying files as a python script, which had a memory leaking endless loop, I do not know why) BUT some stuff continues to get better, GCC is making some pretty huge/amazing changes right now (the tree is a great example) this is an exciting time and I really hope I get to be a part of it. Now let us, as Eric Raymond would say, plan for the future, for it will be here sooner than we think. Alec The point of this mail is to hopefully get you guys pondering on the future, I really enjoy reading these mailing lists and watching the annual tub/pot (I forget...) conference videos you guys make, while my motives are selfish an ounce of prevention is worth a pound of cure :P We did the best we could, now it's time to correct that problem and make sense out of our datastructures. Jeff
Re: [RFC] Replace Java with Go in default languages
There's a point where this becomes "change for the sake of change" perhaps we should stick with "if it's not broken, make no attempt to fix it". Is Java's presence hurting anyone. Yes. Is GCJ's presence hurting anyone? No. That was phrased badly, I hate Java, but GCJ can make it produce something that performs well. I don't use it nearly as often as I ought to I confess but it is still useful. I have never used Ada (no offense, it does have some cool things, I like subtypes with ranges for example). I think many are like me in that if Python isn't fast enough and one wants to experiment/prototype something, one turns to Java for the GC. If memory is trivial to manage to C++. (sidenote, wxPython and wxWidgets FTW) There is no practical reason to replace Java as a default. Anyone using Ada or Go already expects to have to specify it. It was said before (when this first started) that Go wasn't ready. Another language that looks cool but has yet to mature. The test cases are very important though, I doubt there is a person here who would claim otherwise. Unless we can be absolutely sure we are not missing any tests we ought not change. Tests (from what I have seen) are gathered empirically, just yesterday I saw a stack-overflow question that found a bug in GCC, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59123 a new test case was born. This should make them precious. Alec On 13/11/13 16:00, Tom Tromey wrote: "Jeff" == Jeff Law writes: Jeff> Given the problems Ian outlined around adding Go to the default Jeff> languages and the build time issues with using Ada instead of Java, Jeff> I'm unsure how best to proceed. IIRC from upthread the main reason to keep one of these languages is -fnon-call-exceptions testing. How about just writing some tests for that, in C++? It may not be quite as good but it seems like it could be a reasonable first pass; with more obscure issues caught by subsequent testing, much as is the case for non-core targets. Tom
Re: Enable -Wreturn-type by default ?
Who isn't compiling with -Wall and -Wextra?
I do hope Clang ('though I don't use it) doesn't make it an error
because not all functions have to return in C iirc.
Alec
On 13/11/13 16:42, Sylvestre Ledru wrote:
Hello,
I would like to propose the activation by default of -Wreturn-type.
The main objective would to provide a warning for such code:
int foo() {
return;
}
For now, it is only enabled when we have -Wall:
$ gcc -c foo.c
$ gcc -Wall -c foo.c
foo.c: In function ‘foo’:
foo.c:2:2: warning: ‘return’ with no value, in function returning
non-void [-Wreturn-type]
I already wrote the patch but at lot of tests need to be updated to pass
with this change.
It is why, before starting updating all of them, I would like to know if
there is a consensus here.
This bug discuss about this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55189 The idea seems to be
accepted.
Clang is considering that this kind of mistake as an error.
Sylvestre
OpenACC in GCC - how does it not violate the license?
Hey all, I got linked this by a friend today: http://www.mentor.com/embedded-software/blog/post/we-are-bringing-openacc-to-the-gnu-compiler-suite--8d06289f-c4e9-44c8-801b-7a11496e7300 It seems to suggest that GCC can target Nvidia GPUs To quote: or OpenACC 2.0 in GCC, , and generating assembly level instructions for an NVIDIA GPU. Let’s not underestimate the effort involved, which includes teaching GCC how to parse OpenACC directives, how to translate the directives into appropriate blocks of code and data migration, and how to generate instructions for the target device itself. Now while great, is this true!? Nvidia (IIRC, this was like a year ago though) don't even give out the instruction set for their GPUs, can we have GCC targeting closed things? Also there (must be and is) a Cuda runtime, wouldn't we need an open runtime to link against? To quote again: Duncan Poole is responsible for strategic partnerships for NVIDIA’s Accelerated Computing Division. His responsibilities reach across the developer tool chain (the stuff after that quote is just guff) This is by no means an accusation, I'm sure he's doing fine work; but he's doing something I didn't think the GPLv3 allowed (so I want to be corrected) he seems to have added something that requires a closed runtime for a target with a closed instruction set - probably for Nvidia (as he is responsible for "strategic partnerships" with them) I do try and live my life entirely within free software, it means I never have to care about these things. Sorry for my ignorance. Also a search for OpenACC produced very little. Alec
Re: Great example of why "everything is a tree" sucks
The name David Malcolm comes to mind, I remember watching a GCC ... bucket, tub, some sort of large container (pot?) talk on it. He was replacing all the macros with a class with no virtuals (only one data member, as used by the macros in effect) and so forth and using inheritance, doesn't that solve this? (or "wont that solve this?" <--future tense) C++11 has a lot of great things (like std::is_base_of and std::remove_pointer in type_traits) that help with this, I'm pretty sure these came from Boost, most good things come from Boost (read: I am certain they came from Boost and that Boost lets us do them, but it's been so long I couldn't tell you exactly how without reading documentation again). If C++11 stuff can't be used (I'm not saying we should, just observing, I agree that fairly old compilers should be able to build GCC) can't we just use what Boost does? I never spend much time looking but Boost does say which versions of what compilers are supported. If they can do it surely we can? This would allow some pretty solid compile time checks to be introduced I would have thought? Alec On 12/11/13 20:52, Diego Novillo wrote: On Tue, Nov 12, 2013 at 3:35 PM, Jakub Jelinek wrote: Note that we have tons of code which accept either objects or types, both in the frontends and in the middle-end, so changing TREE_TYPE from tree to something else is definitely non-trivial. Well, sure it's hard. This is the whole point behind Andrew's refactoring project: setting up the groundwork for this kind of conversion to be possible. The software engineering atrocities that we have committed in the code base are going to take a few iterations to fix. But fix them, we must. I am convinced that this is the only way for GCC to avoid untimely oblivion; and allow it to evolve in ways that are now hard or impossible to implement. Diego.
Re: [RFC] Replace Java with Go in default languages
If Java must go, and it must have a replacement Ada makes sense. The issues with Go (sadly, you guys are doing superb work) do make sense. I don't know enough about Java (the GCC front end and such) to know if it should go, if it does go why should it be replaced? Alec On 09/11/13 11:55, Eric Botcazou wrote: Right now Go does not build on a range of targets, notably including Windows, MacOS, AIX, and most embedded systems. We would have to disable it by default on targets that are not supported, which is straightforward (we already have rules to disable java on targets it does not support). But to the extent that there are options like -fnon-call-exceptions that are tested primarily by Java and Go, we would get less coverage of those options, since we would not test them on systems that Java supports but Go does not. Let me make the case for Ada here: it's a general purpose, highly portable language, which is regularly built and tested on a significant range of platforms (I personally test it on x86/Linux, x86-64/Linux, PowerPC/Linux, IA-64/Linux, SPARC/Solaris and SPARC64/Solaris). It exercices some features of the compiler that aren't exercised by other languages and stretches some common features much more than the other languages. It turns out that it also enables -fnon-call-exceptions by default. It seamlessly works with LTO. While the fact that a big part of the front-end is written in Ada could be seen as an annoyance (although GNAT has been largely available for about a decade on many systems), it can also be seen a boon; for example, a LTO bootstrap with Ada enabled really exercises cross-language optimizations. Bootstrapping with Ada is marginally slower than with Go (a few percents) and the testsuite is small (4-way parallelizable, testing time of 6 minutes on a fast machine). More seriously, the Go sources live in a separate repository, and are copied to the GCC repo. In practice this means that when Go breaks, it can't be fixed until I am online to fix it. I don't think it would be good for GCC for a bootstrap break to depend on me. In contrast to that, the FSF repository is the master repository for GNAT and breakages can be quickly fixed by anyone with write access.
Re: gnu software bugs - shift left
Hi! On 02/11/13 19:22, Mischa Baars wrote: On 11/02/2013 08:17 PM, Jonathan Wakely wrote: On 2 November 2013 18:57, Mischa Baars wrote: *I understand, however it seems more logical to use the destination type to ** **determine the type of the first and second operand. * No. No it does not. Are you completely sure this is the desired behaviour? *It's the behaviour required by the C standard*, so yes, it is absolutely desirable that GCC does that. *The literal 1 has a fixed type and the literal 31 has a fixed type, ** **and the expression (1<<31) has a fixed type. Whether you assign the ** **result to a different type does not alter those types involved in the ** **expression. * This Wow, that sounds pretty stupid for a standard again :) There is such a vast amount wrong with this I am not sure where to start. Please finish chapter one of whatever book you are reading. It was wrong to make you feel fit to comment on this behavior. Thanks. Alec
Vandalised wiki page
http://gcc.gnu.org/wiki/FunctionMultiVersioning Reported by "kobrien" on the Freenode IRC network, channel #gcc just now, I'm just sending the message. Alec
Re: Trying to find a link for information about parsing template parameters and the >> problem
On 01/04/13 21:08, Jonathan Wakely wrote: On 1 April 2013 20:43, Alec Teal wrote: [snip] Yes that is (was) the problem, I remember reading a document online, I cannot recall where that looked at three ways of solving it and evaluated them, I know of the problem but I want that guy's evaluation! the article spoke about GCC, I'm sure it was under the gnu domain gah! I wish I could recall! Probably http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html It is! Thanks once again Jonathan. Alec
Re: Trying to find a link for information about parsing template parameters and the >> problem
On 01/04/13 17:41, Ian Lance Taylor wrote:
On Mon, Apr 1, 2013 at 8:55 AM, Alec Teal wrote:
I'm still planning to rewrite the c++ parser in GCC, right now I am still
researching, I remember a page that talked about the problems of parsing > in
nested templates, and I cannot find the link!
Searching for it has yielded people asking questions about errors where >>
occurs.
Please provide me with the link.
I'm not sure this kind of message really belongs on the
gcc@gcc.gnu.org mailing list, which is for issues related to the
development of GCC. I understand that you are looking at rewriting
the C++ parser (why?) but this is just a basic C++ question, not a GCC
issue.
An exercise mainly, the goal would be to better facilitate error report
generation, by creating (perhaps with a flag) some sort of AST that may
be dumped or exported. Exporting headers in this form (and importing
later) done with a flag of course. Bringing the parser and symbol table
closer together.
Some things can just be better parsed going from right to left, ; end a
statement and { } form lovely blocks, reading from right to left
shouldn't be too bad at all, nor would perhaps threading complication
(this is just a thought, I know compiling is a task that lends itself to
being done in parallel rather nicely), with this format too you could
perhaps (again with flags) store 'notes' about a function with the hash
of the tokens that make it up, save recompiling an entire file. This
data wouldn't go inside the object file, and these are just some thoughts.
Having such a note file could be useful if any compiler instance can
write to it (if the thing it is notes of is being used) to build a
program-wide callgraph while compiling, I suspect LTO does this already
within the object file though.
If IDEs could make use of this file it'd be even better. I understand
I've gotten quite far from "why the parser" now.
I don't have a link, but it seems to me that the issue is obvious.
The C++ lexer recognizes >> as a single token. So when you write
std::vector>
the final >> is parsed as a single token, rather than the two separate
tokens that the parser expects.
Yes that is (was) the problem, I remember reading a document online, I
cannot recall where that looked at three ways of solving it and
evaluated them, I know of the problem but I want that guy's evaluation!
the article spoke about GCC, I'm sure it was under the gnu domain
gah! I wish I could recall!
Note that this issue is fixed in C++11.
Ian
Alec
Trying to find a link for information about parsing template parameters and the >> problem
Hey guys, I'm still planning to rewrite the c++ parser in GCC, right now I am still researching, I remember a page that talked about the problems of parsing > in nested templates, and I cannot find the link! Searching for it has yielded people asking questions about errors where >> occurs. Please provide me with the link. Alec
Re: anonymous namespaces in GCC source code
On 18/03/13 18:50, Lawrence Crowl wrote: On 3/18/13, Gabriel Dos Reis wrote: I have been having discussion with Andrew about uses of anonymous namespaces in GCC source code. I seem to remember that they used to cause troubles when doing binary diff during bootsrap because we use random names to ensure uniqueness of names; but are we still doing that? We could have an option to take the compile time (and probably some parts of the file path) out of the random number generator. Why not hash the file name and line-number or something? Or add true anonymous name spaces? Why do they require some sort of name? Alec
GCC with C++ type information
Hello all, A friend of mine is attempting to display the type of a template parameter (for whatever reason) and has used -fno-rtti, it makes sense that typeid doesn't work (from ) because there is no type id. However I must say I find it shocking there is no mechanism that GCC provides to do this. I do of course accept that there can be no (pure) macro that can do this but the type of a variable is something that is most certainly available at compile time. I must say I find the usefulness of such a thing questionable but I do not see this as a reason to not have "it". It refers to a "function" (I'm not sure what to call it, I dare not say macro) that takes an expression and returns the name of the expressions type as a const char*. Is there any reason it doesn't exist? There is a work around where __PRETTY_FUNCTION__ may be used and then parsed to find template parameters but this is an awful solution. Alec (Additional/extra question: how might one go about adding such a thing? What would it look like?)
GDB problems
Heya, Long story short, I hit this: http://stackoverflow.com/questions/12595631/debugging-with-gdb-on-a-program-with-no-optimization-but-still-there-is-no-symbo and can't find the problem, it applies here because like the asker of that question I am using a recent GCC build, maybe a week old? I do suspect (there's a mention of a -ggdb3 flag) that I am using an older build of gdb, the guy in the question tried gdb 7.5 (but this was tried a while a go) so even if this isn't gcc related (which I highly doubt, if it were a bug it would have been noticed) I am hoping I'll get even a sentence to point me in the right direction. MAYBE (hint) some links to literature of of how debug data gets scattered over the binary and what has changed between 4.6 (stock) and 4.8 (my current version)... Alec
Re: C/C++ Option to Initialize Variables?
On 18/02/13 11:40, Jeffrey Walton wrote:
Hi All,
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
Is there an option to initialize variables to known values in a C/C++ program?
My use case is 'debug' builds and finding use of uninitialized values
that get lucky by being 0 most of the time. For example:
void DoSomeithWithFoo(FOO** ppf) {
if(ppf && *ppf == NULL) {
*ppf = new FOO;
...
}
}
FOO* p;
DoSomeithWithFoo(&p);
So I would like something that initializes to known, but non-NULL,
such as 0xCDCDCDCD or 0xFDFDFDFD (similar to Visual Studio behavior).
Jeff
Probably not, put =0, if I say "int x;" I am just saying there is an
int, it's name is x, deal with it. I may assign to it later, sticking =0
at the end implicitly wouldn't be good for anything really.
However! calloc initializes the memory to zero change malloc(size to
calloc(1,size and you're done.
Does that help?
Alec
Re: Use of templates in c code?
On 13/02/13 17:11, Jonathan Wakely wrote:
On 13 February 2013 17:01, Alec Teal wrote:
On 13/02/13 17:00, Jonathan Wakely wrote:
I read it. That's not debate, just ill-informed speculation ("cpp is
the recommended extension for C++ as far as I know"). We already have
C++ code in GCC, the runtime library uses .cc and the G++ testsuite
uses .C, adding .cpp as a third choice based on the opinions in that
page or your feeling of unease doesn't seem like a good idea to me.
Why not rename them to?
Because there is reason to prefer .cpp except one person who's never
contributed a line of code to GCC saying he prefers that extension.
That's really childish. I accept I have to prove myself, but people have
feelings.
FWIW I prefer .cc and actually work with the files every day.
Continuing the discussion in this vein seems entirely pointless so
I'll leave this thread here.
Re: Use of templates in c code?
On 13/02/13 17:00, Jonathan Wakely wrote:
On 13 February 2013 16:32, Alec Teal wrote:
On 13/02/13 16:11, Jonathan Wakely wrote:
On 13 February 2013 15:33, Alec Teal wrote:
A few questions, what is this stage 1? (link to documentation please, or
a
descriptive answer).
See http://gcc.gnu.org/develop.html
for the choice of file extension, this is really a tiny thing, but I do
have
a reason for .cpp
http://stackoverflow.com/questions/1545080/correct-c-code-file-extension-cc-vs-cpp
So I have done some research :P
Your reason is a question closed as unconstructive, where the top
answers say it doesn't matter? Why does that support .cpp?
How about using .cc because the existing C++ code in GCC already uses .cc
How about scrolling down? It is such a small issue there is no definitive
answer, the compiler doesn't care, but there is some debate on that page.
I read it. That's not debate, just ill-informed speculation ("cpp is
the recommended extension for C++ as far as I know"). We already have
C++ code in GCC, the runtime library uses .cc and the G++ testsuite
uses .C, adding .cpp as a third choice based on the opinions in that
page or your feeling of unease doesn't seem like a good idea to me.
Why not rename them to?
Re: Use of templates in c code?
On 13/02/13 16:11, Jonathan Wakely wrote: On 13 February 2013 15:33, Alec Teal wrote: A few questions, what is this stage 1? (link to documentation please, or a descriptive answer). See http://gcc.gnu.org/develop.html for the choice of file extension, this is really a tiny thing, but I do have a reason for .cpp http://stackoverflow.com/questions/1545080/correct-c-code-file-extension-cc-vs-cpp So I have done some research :P Your reason is a question closed as unconstructive, where the top answers say it doesn't matter? Why does that support .cpp? How about using .cc because the existing C++ code in GCC already uses .cc How about scrolling down? It is such a small issue there is no definitive answer, the compiler doesn't care, but there is some debate on that page.
Re: Use of templates in c code?
On 13/02/13 16:24, Jonathan Wakely wrote: On 13 February 2013 15:33, Alec Teal wrote: I'm also thinking of re-writing the C++ parser there are some interesting todos (using lookahead rather than "try the next option") it's a topic I enjoy and something I could (probably) do, especially given a working version already. thoughts and feelings on that real quick? Do you mean rewrite or improve? Rewriting it would be a major task, last undertaken for GCC 3.4, and not to be undertaken lightly. Not yet sure, the first thing would be the planning of it, and a prototype that actually parses, probably in Python, python rules! (for quick dev stuff anyway) it depends what I'd have to change and the output from the parser to the next stage (semantic analysis). It'd be a good chance to add some hooks (or something, again it's just a thought) for static analysis to use, fix some of those things that Clang is good for (apparently). Once again, purely a thought, I'd love to at least try, what's this copyright malarkey I've been hearing about? Alec.
Re: Use of templates in c code?
On 13/02/13 13:47, Diego Novillo wrote: I feel silly now, why not use .cpp? SVN's move not good enough? (or is it just because no one could be bothered?) The latter. Perhaps we should start renaming the files. It will help with this confusion and it will also be useful for tools like editors and such. Richi, should we wait for stage 1 to re-open to do a round of mass renames? Diego. I'm at a computer now! A few questions, what is this stage 1? (link to documentation please, or a descriptive answer). for the choice of file extension, this is really a tiny thing, but I do have a reason for .cpp http://stackoverflow.com/questions/1545080/correct-c-code-file-extension-cc-vs-cpp So I have done some research :P I wouldn't go as far as to change header-file extensions because that's clear from the context and most tools now (read: Doxygen) are quite happy with .h being a c++ header file. I like .cpp because it's what I learned, "see-pee-pee" seems to be a natural short-hand of "see-plus-plus" and "see-see" just brings to mind carbon-copying. I am also used to seeing extensions that make sense, ".py" for python, ".php" for php why not go with this. The last reason is a reason but it's quite a null one. Seeing .cpp files makes them feel more accessible when first meeting them, that hesitation when seeing .cc or .C (I've never seen c++ as an extension) just makes it feel either "old-skool" and created by people from before my time (not accessible, daunting in fact) or not nice to glance over because of that thought in the .cc part (this could be a dyslexic thing it doesn't help!), conversely any confident person would not be deterred by such silly reasons (even though I know they're silly, I still feel them) and thus to them it doesn't matter. Alec I'm also thinking of re-writing the C++ parser there are some interesting todos (using lookahead rather than "try the next option") it's a topic I enjoy and something I could (probably) do, especially given a working version already. thoughts and feelings on that real quick?
Re: Use of templates in c code?
On 13/02/13 12:39, Richard Biener wrote: On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal wrote: It's just a filename ... we compile it with a C++ compiler. Richard. I feel silly now, why not use .cpp? SVN's move not good enough? (or is it just because no one could be bothered?) Alec I am sorry if I am searching for a higher reason where there isn't one to be found.
Use of templates in c code?
I've been studying/reading gccs code, watching it compile though a debugger and reading. Today I noticed something odd in the c++ parser's file. I saw what appeared to be a template in a .c file. I am on a different computer now but it was vec< and occurred about 1/6th of the way in, it should be easy to find. Is that allowed? Is my main question. I would support a c with templates it'd save macro usage, that could only be good! Or is there some construct of c I do not know of. Searching for c templates proved fruitless I got loads of c++ results Alec
Re: (2WCCS) Rufen Sie für Abstract
We're getting a lot of crap ATM? Does an admin know?
Re: Bootstrapping process
I prefer books or large bodies of text, not notes and how Tom's I. Wiki pages Jonathan Wakely wrote: >On 1 February 2013 21:27, Alec Teal wrote: >> Nevermind, http://gcc.gnu.org/onlinedocs/ this is amazing and linked to from >> the gcc-melt link. > >And linked to from the GCC home page ... I kinda assumed when asking >for something to read you'd looked at the GCC web pages already. > >If you say what you've read and what you're looking for it might help, >otherwise we can't know if the existing docs on the home page are >relevant or if telling you to read them first then come back is >patronising. >
Re: Bootstrapping process
Nevermind, http://gcc.gnu.org/onlinedocs/ this is amazing and linked to from the gcc-melt link. Thanks so much Basile! I really appreciate the reply, If you feel like replying again any more? I'm a heavy reader :) Alec On 01/02/13 21:17, Alec Teal wrote: What would you search for to find more on the web? I found a lot of stack-overflow questions and guides to building GCC in my quest? Thanks for the links! Alec On 01/02/13 21:16, Basile Starynkevitch wrote: On Fri, Feb 01, 2013 at 08:56:43PM +0000, Alec Teal wrote: If you could link such documentation but about the way GCC is built, then you'd be answering my question http://www.cse.iitb.ac.in/grc/ has a lot of resources & slides. http://gcc-melt.org/docum.html has some slides notably http://gcc-melt.org/GCC-MELT-HiPEAC2012.pdf which might also help. And you can find many other resources on the web too... Cheers
Re: Bootstrapping process
What would you search for to find more on the web? I found a lot of stack-overflow questions and guides to building GCC in my quest? Thanks for the links! Alec On 01/02/13 21:16, Basile Starynkevitch wrote: On Fri, Feb 01, 2013 at 08:56:43PM +, Alec Teal wrote: If you could link such documentation but about the way GCC is built, then you'd be answering my question http://www.cse.iitb.ac.in/grc/ has a lot of resources & slides. http://gcc-melt.org/docum.html has some slides notably http://gcc-melt.org/GCC-MELT-HiPEAC2012.pdf which might also help. And you can find many other resources on the web too... Cheers
Re: Bootstrapping process
On 01/02/13 20:52, Paolo Carlini wrote: Alec Teal ha scritto: I'd like to know more about the bootstrapping phases in terms of why, how, why split it into the phases that exist, so forth but something detailed rather than a "how to" with some side-notes. Just in case your are also curious about living Italian, often in such cases we jokingly reply something like: what about a slice of my ass too? Paolo I don't follow, I would imagine there are plenty of large pdfs and reams of web-pages on moving to Italy and coping with the life-style and whatever else living like an Italian entails, and the Internet has a strong body of ass and things involving it. If you could link such documentation but about the way GCC is built, then you'd be answering my question
Bootstrapping process
Heya, yes I'm still here (Hope that's good) I'd like to know more about the bootstrapping phases in terms of why, how, why split it into the phases that exist, so forth but something detailed rather than a "how to" with some side-notes. Alec.
Re: hard typdef - proposal - I know it's not in the standard
On 28/01/13 10:41, Jonathan Wakely wrote: On 28 January 2013 06:18, Alec Teal wrote: the very nature of just putting the word "hard" before a typedef is something I find appealing I've already explained why that's not likely to be acceptable, because identifiers are allowed before 'typedef' and it would be ambiguous. You need a different syntax. That is why I'd want both, but at least in my mind n3515 would be nearer to "if I really wanted it I could use classes" than the hard-typedef. I've already said N3515 is not about classes. You keep missing the point of what I mean by "like classes" I mean in terms of achieving the result, PLEASE think it though. It can be used to define strong typedefs for classes, which is needed because most types in real C++ programs are class types, but it also works for scalar types.
Re: hard typdef - proposal - I know it's not in the standard
I've thought of how to phrase it. Yes n3515 does allow more than the 'hard-typedef', they do (in part) do the same job, but the context where you'd use one and not the other is very clear, I like clean notations, I think that's a mathematician thing, as I am sure you know (or have touched on) the mathematicians go to great lengths to save themselves ink. I can think of many examples of this, think of ways of writing integrals, especially ones along a parameterized curve in a vector field, it just became an integral with the symbol of the curve below it. 1 doesn't mean 1 it means the multiplicative identity element of a set, "" 0 but for additive notation. You get the idea (I don't want to bore you or go beyond) but think of the hard-typedef as the integral symbol with a circle though it, showing over a closed curve, it's just a short hand in a case where you are integrating over a closed curve, the hard-typedef is a short hand in the case you want to 'inherit' operations from the base class. I hope this explains it better! Alec On 28/01/13 02:38, James Dennett wrote: n3515 is also explicit that the permitted conversions have no run-time cost. Is there anything that you propose that a "private opaque alias" from n3515 does not provide? -- James
Re: hard typdef - proposal - I know it's not in the standard
On 28/01/13 02:38, James Dennett wrote:
That's a cast -- an explicit request in code for a type conversion.
The fact that it's a pure compile-time operation and a no-op at
runtime has no bearing on whether it "is a cast", just as we can
static_cast beween enumerators and integers today with no run-time
cost. One of the purposes of casts is to tell the compiler "Yes, I
mean to write this", and it's common for casts to be purely
compile-time operations. n3515 is also explicit that the permitted
conversions have no run-time cost. Is there anything that you propose
that a "private opaque alias" from n3515 does not provide? -- James
No, it's the other way around, n3515 provides stuff this doesn't - but
by design. It's not an "either or".
(I've deleted like 3 different responses now).
It really isn't an "either or", I am not saying "this over n3515", I
would want both (I think, that's the point of this discussion).
I would prefer a hard-typedef for things like vector components (if I
didn't decide to use a struct, where the components would be given by
name), or ids, the compiler would stop me mixing types unless I meant
to, the very nature of just putting the word "hard" before a typedef is
something I find appealing as the function of it is to stop me from
doing silly things and to allow me to be reminded of what something is
from it's definition (a BookId for example), it'll also allow
overloading, I find the idea of a function called "getName" returning
the name of a book, author or whatever very appealing when passed a
BookId, AuthorId or a whateverId.
The very nature of a typedef is an alias, if I alias something from an
int I have grown to expect to be able to add it and do other integer
things with it, this is true of the hard-typedef to, I don't want to (I
may have said this) be able to define a type system so rigid that an IDE
auto-complete could create a grand unified theory. I don't want to stop
and think when using this on a float type "can I divide this", not all
operations form a group (this is why I mentioned groups earlier), real
numbers do not form a group under multiplication (and hence division by
requirement of an inverse) because of 0 being a real number. Despite
this we may still divide by zero. I do not want to have to use n3515 and
be faced with this temptation. Having said that I have yet to use it so
maybe it wouldn't be that big.
That is why I'd want both, but at least in my mind n3515 would be nearer
to "if I really wanted it I could use classes" than the hard-typedef.
I may have said this too, but I'll say it again. Typedefs are something
that go on a line and define a useful alias. I doubt this is disputed,
sticking the word "hard" before it and gaining this is something I find
very appealing, having to write:
using opaque-type = access-specifier underlying-class {
desired-member-trampoline-signature = default;
friend desired-nonmember-trampoline-signature = default;
};
(or something of that form)
while useful, is less appealing. I don't really care that I /could/ add
BookIds, I think the hard-typedef is more in line with how typedefs are
actually used, but abstract algebra has taught me that you cannot
rigidly define operations on things that'll always be defined or even
useful, I also see operators more as a notation than operations, I think
this is what tempts people and luls them into needlessly defining
operators, adding two BookIds doesn't have to mean the operation of
addition on integers. I am going off topic, suffice to say perhaps I
will think of a use for additive notation for a binary operation on
BookIds, it need not be the same as addition on integers. If I did
define such a thing though doesn't this blur the line between class and
a hard-or-strong typedef?
Alec
Re: hard typdef - proposal - I know it's not in the standard
To some up again (I've kept the quotes so it can be seen what's already been talked about) I propose something that is almost identical to a typedef as it exists now, all behaviour of this hard typedef is almost identical except: 1) the "hard" type is never implicitly 'cast' to anything else of the same actual type (a BookId may never become an int implicitly) 2) the "hard" type may be used in overloading (building on the 'may not be implicitly cast' a call to f(someBook) will never resolve to f(int), only to f(BookId) Because it is to behave like a typedef the c-style cast isn't actually a cast at all, it is a way of telling the compiler you intend to use the hard-typed variable as you have written. There is no actual cast because it's a kind of typedef the underlying data is by definition the same. If the compiler didn't complain when you tried to use a BookId as an int or visa-versa that would defeat the purpose. the c-style cast of "int x = (int) some_book;" or whatever is not a cast (I'm saying the same thing again, sorry) it's just telling the compiler "Yes, I mean to write this" Alec On 24/01/13 19:45, Lawrence Crowl wrote: On 1/24/13, Alec Teal wrote: Did anyone read? I can sometimes take several days to get to reading an email, particularly when travelling. I hope you see how it is nothing like a strong typedef (as its called). To me it seems like the strong one is too similar to a class to be worth adding, especially after reading that paper, it seems like it would allow new-php-user like behaviour of EVERYTHING IS A CLASS but with types, we've all been there. While this could stop some errors ... I've discussed this already. If you want your feature in mainline gcc, you will need to convince the maintainers that the feature is valuable. Likewise, if you want your extension in the C++ language, you will need to convince the C++ standards committee. Both tasks have essentially the same structure. Clearly explain the programming problem you have. You need to explain why the current language is not really working. Using examples of real failures is helpful. You should show that the problem is significant to a significant number of programmers. (They may not know they have a problem, so you will need to explain it.) The for your feature, IIUC, is that you are not proposing something that keeps track of physical units, so many examples of bad operations would not apply to your feature. You need to make the case that there is some aspect of programming that the feature captures in code. You need to examine a few alternative solutions. Presumably, your proposal is one of them. Finally, you should discuss any interaction between your feature and existing features. In your case, you appear to be changing the meaning of C casts. What about C++ casts? Do you need a new one, or do you change the meaning of existing ones? This list of tasks may seem like a lot of work, but it will likely be significantly less than the implementation work. More importantly, it will help ensure that the feature has a market of users. Alec I am eager to see what you guys think, this is a 'feature' I've wanted for a long time and you all seem approachable rather than the distant compiler gods I expected. I can also see why 'strong typedefs' were not done, it tries to do too much with the type system and becomes very object like.... Alec Teal wrote: On 23/01/13 23:07, Lawrence Crowl wrote: On 1/23/13, Jonathan Wakely wrote: On 23 January 2013 09:15, Alec Teal wrote: I was fearful of using the word attribute for fear of getting it wrong? What is "this part" of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's "tree" data structures. FWIW I've usually seen this feature referred to as "strong typedefs". That brings to mind the "strong using" extension G++ had for namespaces, which (prior to getting standardised as "inline namespaces") used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html Note that there is a proposal before the C++ standard committee on just this topic. Consider its semantics when implementing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf After reading that it doesn't seem like the same thing, they are talking about - essentially - creating "classes" to handle types with no runtime overhead, they want to be certain the optimizer got rid of it or save the optimizer a job. I'm not saying that's bad I just think it is separate. Typdefs are supposed to be an alias, yes in light of that the title of "type definition" seems a little misleading when put with that
Re: gcc : c++11 : full support : eta?
On 24/01/13 20:16, Basile Starynkevitch wrote: On Thu, Jan 24, 2013 at 08:11:25PM +, Alec Teal wrote: On 24/01/13 19:55, Diego Novillo wrote: ... I don't know enough yet but GCC seems to be partitioned, this back and front end, There is also a middle-end in GCC (and IMNSHO the middle-end of GCC is its biggest part; it is the thing which does not depend much on the source language and on the target processor & system). IMNSHO (In My Honest Opinion)? and yes that makes sense, but the same is true of LLVM, that is the middle part, it's far away from the code (but is (rather cooley) able to contain metadata IIRC so you can 'rebuild' parts of where it came from, I've never really looked into it that far) but not near a specific machine. It'd be really cool if GCC could compile to LLVM and also parse it. This has to be worth more than "because it is cool" and would certainly (read perhaps) link the two communities together. FWIW, there is some partial documentation about GCC (notably some slides I have made) on http://gcc-melt.org/docum.html FWIW? (of course the main emphasis is on MELT, but there are some explanations about GCC internals) I will be reading that soon, I really enjoyed that RTL presentation yesterday, it's nice to have new stuff to read! If you have any other links, I'd love a big pdf or something rather than just... smaller things. Cheers Alec
Re: gcc : c++11 : full support : eta?
On 24/01/13 20:18, Diego Novillo wrote: On Thu, Jan 24, 2013 at 3:11 PM, Alec Teal wrote: That is a need that g++ cannot currently satisfy. With plugins, one could do something along those lines, but they are heavier, and are at the mercy of the full compiler. Additionally, g++ has very low fidelity wrt the input program; it breaks down the original C++ input almost immediately. I don't quite follow, as opposed to? (Sorry if dumb question) As opposed to an AST that is a very close representation of the original C++ program. Such that if you pretty printed that AST, you'd get something that resembles the original program very closely. I don't really know about GCC and how it parses C++ but could you not just embed more meta-data in GCCs AST? Or even the tokens themselves? or do the two methods mix like oil and water and there really is no compromise that doesn't have two loosers? Alec Diego.
Re: gcc : c++11 : full support : eta?
On 24/01/13 19:55, Diego Novillo wrote: ... Agreed. I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: "toolability" (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. I don't know enough yet but GCC seems to be partitioned, this back and front end, there's some point where there's no GIMPLE and then there is, whenever I've got a big code-blob and need to do something with it where I cannot copy and paste the bits I want to keep, you know, you can't just take the good parts, I've turned to Biology: When DNA replication happens (or protein synthesis - please biologists don't be bionazis) the DNA is not 'unzipped' for very long and doesn't leave the safety of the membrane around the nuclease (this time last year, I would have known the name!) so instead it is transcribed. An enzyme latches onto the 3`UTR end and moves to the 5`UTR end, unzipping the DNA and rezipping it in it's wake, and it transcribes the DNA bases to the complimentary base in RNA, rather than the compliment to DNA's Adenine (thymine) RNA has Uracil. Fun fact. Anyway this fragile DNA structure that can't leave the nuclease or be split up (GCC) can be traversed by this enzyme and spit off useful strands of RNA that expresses the data of the DNA. No fact checking - hope it wasn't to bad, and worthy of writing, with GCC why not add the ability to "siphon" off useful structures and output a form that can be independent of the DNA that is GCC (serialised form) The thing that'd do this would be inside GCC so would have access to all context and whatever data is available. I think that was a superb metaphor. That is a need that g++ cannot currently satisfy. With plugins, one could do something along those lines, but they are heavier, and are at the mercy of the full compiler. Additionally, g++ has very low fidelity wrt the input program; it breaks down the original C++ input almost immediately. I don't quite follow, as opposed to? (Sorry if dumb question) That is not necessarily a bad thing for g++. But, to effectively compete in those areas, it will need to be significantly re-organized. LLVM has similar properties, at least as far as the middle end of the compiler is concerned. GCC still has an edge wrt backend portability. Diego. Alec
Re: hard typdef - proposal - I know it's not in the standard
FYI: Lawrence Crowl says "If you want your feature in mainline gcc" not I. Also I want to be the one to do this feature, implementation. On 24/01/13 19:49, Jeffrey Walton wrote: On Thu, Jan 24, 2013 at 2:45 PM, Lawrence Crowl wrote: On 1/24/13, Alec Teal wrote: ... If you want your feature in mainline gcc, you will need to convince the maintainers that the feature is valuable. Likewise, if you want your extension in the C++ language, you will need to convince the C++ standards committee. Both tasks have essentially the same structure. How does one engage the C and C++ committees? Please forgive my ignorance. Jeff
Re: hard typdef - proposal - I know it's not in the standard
On 24/01/13 18:45, Jonathan Wakely wrote:
On 24 January 2013 16:21, Alec Teal wrote:
That's because this has nothing to do with objects, in the paper that was
linked (called "strong typing") it implemented new types rather like
objects, "using score = public int { //definitions }; for example,
"extending an int" effectively, this is what I mean by a PHP-noob going
class-mad.
I think you've misunderstood the proposal. The syntax you refer to
defines a strong typedef for int and defines an overloaded operator
for it, it doesn't go class-mad and has nothing to do with PHP or
"everything is a class". It would add no overhead over an int either,
if implemented sensibly, it would only have compile-time properties
and not alter runtime behaviour. Reel in the hyperbole.
What? No.
In PHP when people learn about objects they tend to make EVERYTHING into
an object and never use inheritance. I'm playing on that! In the paper
they define X Y and Z components, EVERYTHING is a defined type of sorts.
When it comes to runtime overhead, yes there is none in both cases, but
it's about look, the one in the document looks like a class, it makes
sense to be but it's a bulky syntax for something as small as a typedef.
I'm not saying "not" the above, just that it invites overuse - I do have
an extension to the idea that employs more of the abstract algebra
that'd look a lot like what that paper is on about, anyway, I propose
something simple, not different, small and not able to be over-used
without real stupidity taking over (probably)
See what I mean? Again not saying 1 or the other, just that with this,
then the strong ones.
Re: hard typdef - proposal - I know it's not in the standard
On 24/01/13 14:22, Robert Dewar wrote:
On 1/24/2013 9:10 AM, Alec Teal wrote:
Alec I am eager to see what you guys think, this is a 'feature' I've
wanted for a long time and you all seem approachable rather than the
distant compiler gods I expected.
I certainly see the point of this proposal, indeed introducing
this kind of strong typing makes sense to anyone familiar with
Ada, where it is a standard feature of the language, and the
way that Ada is always used.
I came up with this because of my job, I create stuff for Android
devices this means I have to use Java - I HATE JAVA! It's crap for SO
MANY reasons.
Anyway the stuff I do must be high performance, it's for games (not all
can be done native and it's preferable to use Java where you can because
of the massive wadge of different devices). Lack of structs became a big
problem and OpenGL has a lot of flags, using hard-typing would mean the
IDE could only hint at ones that made sense (rather than the general
int), same with using SQLite on Android, I don't want to create a Java
class because I know what I'm doing and that's overkill, the class will
actually exist! Just to wrap an int, this would allow me to create an
int but not be allowed to mis-use it, it'd also let me overload stuff
based on the type, even when it's an int right down.
It isn't really a feature in the sense of a new syntax, it's just the
word "hard" and the result is this
no-runtime-overhead-but-otherwise-the-same case where you can overload too!
However, I wonder whether it is simply too big a feature for
gcc to add on its own to C++. For sure you would have to have
language lawyers look very carefully at this proposal to see
if it is indeed sound with respect to the formal rules of the
language. Often features that make good sense when expressed
informally turn out to be problematic when they are fully
defined in the appropriate language of the standard.
I agree sadly, even if "hard" was a pre-processor macro that 'became'
hard when GCC was compiling (using a simple #ifdef) and it became a
"normal" typedef, all that lovely overloading and purpose would be gone.
I can also see why 'strong typedefs' were not done, it tries to do
too much with the type system and becomes very object like
I don't see what this has to do with objects!
That's because this has nothing to do with objects, in the paper that
was linked (called "strong typing") it implemented new types rather like
objects, "using score = public int { //definitions }; for example,
"extending an int" effectively, this is what I mean by a PHP-noob going
class-mad.
Re: hard typdef - proposal - I know it's not in the standard
Did anyone read? I hope you see how it is nothing like a strong typedef (as its called). To me it seems like the strong one is too similar to a class to be worth adding, especially after reading that paper, it seems like it would allow new-php-user like behaviour of EVERYTHING IS A CLASS but with types, we've all been there. While this could stop some errors ... I've discussed this already. Alec I am eager to see what you guys think, this is a 'feature' I've wanted for a long time and you all seem approachable rather than the distant compiler gods I expected. I can also see why 'strong typedefs' were not done, it tries to do too much with the type system and becomes very object like Alec Teal wrote: >On 23/01/13 23:07, Lawrence Crowl wrote: >> On 1/23/13, Jonathan Wakely wrote: >>> On 23 January 2013 09:15, Alec Teal wrote: >>>> I was fearful of using the word attribute for fear of getting it wrong? >>>> What >>>> is "this part" of the compiler called >>> I think attributes are handled in the front end and transformed into >>> something in the compiler's "tree" data structures. >>> >>> FWIW I've usually seen this feature referred to as "strong typedefs". >>> That brings to mind the "strong using" extension G++ had for >>> namespaces, which (prior to getting standardised as "inline >>> namespaces") used __attribute__((strong)) so that attribute already >>> exists in the C++ front end: >>> http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html >> Note that there is a proposal before the C++ standard committee on >> just this topic. Consider its semantics when implementing. >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf >> >After reading that it doesn't seem like the same thing, they are talking >about - essentially - creating "classes" to handle types with no runtime >overhead, they want to be certain the optimizer got rid of it or save >the optimizer a job. I'm not saying that's bad I just think it is >separate. Typdefs are supposed to be an alias, yes in light of that the >title of "type definition" seems a little misleading when put with that >paper, but none the less a typedef is an alias. > >While reading the book "The design and evolution of C++" (I am not >saying this to throw around "look, from the 'founder' of C++'s mouth!", >I read it so I could learn why things are the way they are and errors >which would have happened if things had of happened differently, wow >that's a weird sentence, I mean failed attempts) I did enjoy reading >about the strict typing that C++ introduced and that was to catch errors. > >The paper has a point, you would never try to multiply two game scores, >so why have compiler tell you if you do? You'd surely mean it! What if >you want to computer the geometric mean (or something, go with me) >ultimately it's still an int! Why not go a step further and give the >compiler the concept of a group (algebraic structure see [1]) this could >stop divisions by zeros! Why not say you can no longer divide an integer >by another integer? MOST of the time the result wont be an integer, with >their example of cartesian(3) to spherical coordinates you shouldn't >have to rigidly define such stuff that it throws an error when you do >something as silly as mix them up and again, when they define x there is >no one-size-fits-all definition for how x operates with other types. If >you were to seriously try you'd just get so much spam, the only reason >the idea doesn't totally implode is because you can "cast" back to the >"base", so if all your definitions - which are more like conditions - >don't allow something, you just side-step it, this is an own goal the >point was you would never sidestep. > >There is a line between what I am proposing and what they are, I cannot >define exactly where it is, by their own admitance they cant: > >/"This issue has been one of the consistent stumbling blocks in the >design of an opaque typedef// >//facility. In particular, we have come to realize that there is no one >consistent approach to the// >//return type issue such that it will meet all expectations under all >circumstances//:"/ > >If they could this would be far more important than a proposed C++ >feature and would have been 'discovered' during the Abstract Algebra >boom during the times of Gauss. > > >Back on topic! >I always thought of a hard-typedef as an extension of this.
Re: gcc : c++11 : full support : eta?
I am keeping a "diary" of sorts about what I think GCC is and how that changes, how it does things, so forth. Please keep one too! Alec
Re: hard typdef - proposal - I know it's not in the standard
On 23/01/13 23:07, Lawrence Crowl wrote: On 1/23/13, Jonathan Wakely wrote: On 23 January 2013 09:15, Alec Teal wrote: I was fearful of using the word attribute for fear of getting it wrong? What is "this part" of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's "tree" data structures. FWIW I've usually seen this feature referred to as "strong typedefs". That brings to mind the "strong using" extension G++ had for namespaces, which (prior to getting standardised as "inline namespaces") used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html Note that there is a proposal before the C++ standard committee on just this topic. Consider its semantics when implementing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf After reading that it doesn't seem like the same thing, they are talking about - essentially - creating "classes" to handle types with no runtime overhead, they want to be certain the optimizer got rid of it or save the optimizer a job. I'm not saying that's bad I just think it is separate. Typdefs are supposed to be an alias, yes in light of that the title of "type definition" seems a little misleading when put with that paper, but none the less a typedef is an alias. While reading the book "The design and evolution of C++" (I am not saying this to throw around "look, from the 'founder' of C++'s mouth!", I read it so I could learn why things are the way they are and errors which would have happened if things had of happened differently, wow that's a weird sentence, I mean failed attempts) I did enjoy reading about the strict typing that C++ introduced and that was to catch errors. The paper has a point, you would never try to multiply two game scores, so why have compiler tell you if you do? You'd surely mean it! What if you want to computer the geometric mean (or something, go with me) ultimately it's still an int! Why not go a step further and give the compiler the concept of a group (algebraic structure see [1]) this could stop divisions by zeros! Why not say you can no longer divide an integer by another integer? MOST of the time the result wont be an integer, with their example of cartesian(3) to spherical coordinates you shouldn't have to rigidly define such stuff that it throws an error when you do something as silly as mix them up and again, when they define x there is no one-size-fits-all definition for how x operates with other types. If you were to seriously try you'd just get so much spam, the only reason the idea doesn't totally implode is because you can "cast" back to the "base", so if all your definitions - which are more like conditions - don't allow something, you just side-step it, this is an own goal the point was you would never sidestep. There is a line between what I am proposing and what they are, I cannot define exactly where it is, by their own admitance they cant: /"This issue has been one of the consistent stumbling blocks in the design of an opaque typedef// //facility. In particular, we have come to realize that there is no one consistent approach to the// //return type issue such that it will meet all expectations under all circumstances//:"/ If they could this would be far more important than a proposed C++ feature and would have been 'discovered' during the Abstract Algebra boom during the times of Gauss. Back on topic! I always thought of a hard-typedef as an extension of this. I don't want it treated like a class, I don't want this to be valid: hard typdef int BookId; int x = 5; BookId my_book = x; //should fail BookId alternate = (BookId) x; //fine - no runtime overhead because it's just an alias, no compiling overhead really either. This (in the world of classes) is interesting because if anything int is the parent of BookId, but I shouldn't need a constructor or a reinterpret_cast (however it'd be applicable) because I had written "(BookId)" before the x, and that's probably not an accident the compiler should realize I meant to do it. Now what about the other way? hard typdef int BookId; BookId x = 5; int my_book = x; //should fail int alternate = (int) x; //fine - no runtime overhead because LOOK! Now in terms of inheritance we have it going both ways, so while you could look at this as typdef system as "a set of classes all storing one member of the same type with a different set of operations" you ca
Re: Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
On 23/01/13 19:38, Diego Novillo wrote: [ We have drifted way off the original subject. ] On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker wrote: Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Yes. This is an issue for the long term viability of GCC as a project. In fact, I sometimes think that we may be past the tipping point. Note that the very set of developers that can fix these problems are, traditionally, the least likely to do much about it. These developers are already comfortable with the codebase, they know how to do the things they are hired to do and employers are largely on the same boat. Additionally, established developers will generally resist change, because these changes lead to short-term instability and bugs (the releng/maintainer mindset). Evolving this codebase is largely a thankless and difficult job. It's technically interesting to me, but I know I can only do so much. We have other demands on our time and often this conflicts with the nature of these changes. Some developers have done some work here and there to improve the codebase, but GCC's accumulated technical debt is large. If this trend continues, the pool of experienced GCC developers will eventually start to dwindle. Without developer renewal, GCC will naturally die out. This cycle has happened many times before and it will continue to happen. Yet, it would be interesting to have two or more strong competing open source compilers. The cross-pollination that open source competition encourages is beneficial to all (users and developers). Diego. As I am happy to be finding out though, even from RTL (old pdfs and stuff :)) GCC wasn't what I thought it was, to quote earlier: -- I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. > I know now that most of them were wrong BTW! Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). Richard. < You see my point though right? Alec -- Is it not just bad press? The articles perpetuate the "Wow look how easy clang is" which no one expects of GCC. Alec
Re: gcc : c++11 : full support : eta?
On 23/01/13 19:43, Richard Biener wrote: On Wed, Jan 23, 2013 at 8:23 PM, Alec Teal wrote: On 23/01/13 19:16, Uday Khedker wrote: On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Uday. I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. I know now that most of them were wrong BTW! Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). Richard. You see my point though right? Alec
Re: gcc : c++11 : full support : eta?
On 23/01/13 19:16, Uday Khedker wrote: On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Uday. I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. I know now that most of them were wrong BTW! Alec
Re: gcc : c++11 : full support : eta?
On 23/01/13 19:05, Richard Biener wrote: Uday Khedker wrote: I have been trying to do my stuff for a few years. We conduct a programme called "Essential Abstractions in GCC" which is aimed at taking a novice to a level from where she can do independent experimentation with GCC internals. I put together a bunch of teaching assistants (about 15 of them) for about 60 participants. Carefully designed programming assignments are an integral part of the training. The program ends with us summarizing the essential abstractions in 17 or 18 pictures with the hope that if one can understand the concepts represented by the pictures, one can walk the maze of the GCC code. You can find the details of the latest offering at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( When I rule the world you will not have such problems. Seriously can you not reason with them? Can you hint at what they would consider adopting it? I suppose it is not simply linking to it from the wiki or the website? Richard. Uday. Aldy Hernandez wrote, On Wednesday 23 January 2013 08:07 PM: Uday Khedker writes: I think we need to come out of the "documentation" mindset. No amount This is being dragged up A LOT actually, and a lot of the clang-vs-gcc myths are just that, ALSO I was lead to believe GCC used some hand-coded stuff for final code output, one of the reasons I liked LLVM is because it seems sensible, I've just read a power-point presentation on RTL, GIMPLE cannot be a step back! Alec. of conventional documentation is going to help. What we need is a training material that included well defined assignments. FWIW, I initially learned GCC by an internal training program Jeff Law devised over a decade ago (*). So perhaps there is some truth to the above statement. Of course, it didn't hurt that I had a cadre of good and patient maintainers willing to answer questions. [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. But anyways, that's just me. Different folk learn differently. Aldy (*) I think Alex Oliva was also a student of the Law training program :). I just want to say you guys have been so nice! Totally not what I expected, so thanks for that!
Re: gcc : c++11 : full support : eta?
On 23/01/13 10:26, Richard Kenner wrote: I think we need to come out of the "documentation" mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. I agree. At one point, I had a large tutorial presentation. It's dated now, since it's before the tree-ssa era, but we definitely need something like that. High-quality documentation is critical, but isn't where people will be starting. Please link it, I enjoy reading it and it couldn't harm!
Better debugging with!
I've been thinking about this for a while and it can't hurt to share it
(it'd become shared eventually anyway) and someone might thing "good idea":
Obviously -g makes gcc embed a lot of information in the result that is
clear already why not that bit more? Arrays will always be integer sized
(4 bytes) (you could go long...) and it'd be really convenient if you
didn't have to tell gdb how big of an array to pretend it is, why not
tell it in code? This'd be great! It already knows about pointers so
this is just a simple step:
int n = 10;
#GDB_PAY_ATTENTION int n
MyType* arrayOfSorts = (MyType*) malloc(n*sizeof(MyType));
(not a word about calloc)
the int after ATTENTION is just if you had MASSIVE arrays beyond the
bounds of an unsigned int (could happen, who am I to prevent that, in
theory) perhaps int could be implicit, followed by the variable name or
constant size of the array.
This should just tell GDB to pay attention to the NEXT STATEMENT ONLY
and the first statement on that line (incase you can think of some weird
way this would mean re-writing something currently valid):
struct Vertex {
float x;
float y;
float z;
};
int n = 100*3;
#GDB_PAY_ATTENTION n
float* points = malloc(n*sizeof(float));
int k = n / 3;
#GDB_PAY_ATTENTION k
Vertex* vertices = (Vertex*) points;
Obviously not GDB_PAY_ATTENTION, that's supposed to be humour because I
have no ideas for a name yet.
I also see no reason not to allow "n" to be an expression? with the K
above an optimizer will have it's way with that anyway as k isn't used
after, you get the idea!
Alec
Re: hard typdef - proposal - I know it's not in the standard
On 23/01/13 08:55, Jonathan Wakely wrote: On 23 January 2013 06:53, Alec Teal wrote: Why not: make an "optional keyword", "hard", have a meaning if before "typedef", I suggest tokenising "hard" as a normal token (however it is processed now why change it? I am not sure on GCCs exact grammar for c languages) but if AND ONLY if it is before a "typdef" treat it differently, as far as I know a typedef can only occur at the beginning of a statement so this should mean it doesn't break anything. Like other specifiers such as const and static, typedef doesn't have to come first, i.e. this is legal, if unconventional: typedef int hard; hard typedef Int; I think Basile's suggestion to implement it as an attribute is a better idea, it makes it clearer it's something non-standard and compiler-specific, and the grammar already contains attributes in declarations. Problems: 1)Not all compilers would be happy with this. Fix: I'm sure gcc must define something for the preprocessor that'll exist if and only if GCC is the compiler? Nope, Compilers that claim GCC compatibility also define __GNUC__, and as has been discussed before on this list, if we added __REALLY_GCC__ then other compilers would just add that too. I was fearful of using the word attribute for fear of getting it wrong? What is "this part" of the compiler called (I'm doing this with gcc@gcc.gnu.org cced in for any future mes ;-))? Are there any decent-sized documents on it? I'd love a good read! Alec
Re: Compiling GCC problems
On 23/01/13 08:19, Alec Teal wrote: On 23/01/13 08:16, Alec Teal wrote: configure went well but I keep hitting: ../.././gcc/gengtype.c:963: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1098: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1154: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1164: error: undefined reference to 'lexer_line' ../.././gcc/gengtype-parse.c:53: error: undefined reference to 'yylex(char const**)' ../.././gcc/gengtype-parse.c:1044: error: undefined reference to 'yybegin(char const*)' ../.././gcc/gengtype-parse.c:1070: error: undefined reference to 'lexer_toplevel_done' ../.././gcc/gengtype-parse.c:1075: error: undefined reference to 'yyend()' I've installed flex, bison and yacc (should it use it, it seems to be using bison -y) (if I hadn't have installed flex would it's "missing" ones have worked? What's wrong? It does configure fine! Alec checking for version 0.11 of ISL... no The following languages will be built: c,c++,fortran,java,lto,objc *** This configuration is not supported in the following subdirectories: gnattools target-libada target-libgo target-libbacktrace (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug *** removing build-x86_64-unknown-linux-gnu/libiberty/Makefile to force reconfigure *** removing build-x86_64-unknown-linux-gnu/fixincludes/Makefile to force reconfigure Noticed this in the config output, should this really be silent? Alec /sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libisl.so.8.0.0-gdb.py is not an ELF file - it has the wrong magic bytes at the start. cannot fix this, even running it directly python has no module "gdb", is this the source?
Re: Compiling GCC problems
On 23/01/13 08:16, Alec Teal wrote: configure went well but I keep hitting: ../.././gcc/gengtype.c:963: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1098: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1154: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1164: error: undefined reference to 'lexer_line' ../.././gcc/gengtype-parse.c:53: error: undefined reference to 'yylex(char const**)' ../.././gcc/gengtype-parse.c:1044: error: undefined reference to 'yybegin(char const*)' ../.././gcc/gengtype-parse.c:1070: error: undefined reference to 'lexer_toplevel_done' ../.././gcc/gengtype-parse.c:1075: error: undefined reference to 'yyend()' I've installed flex, bison and yacc (should it use it, it seems to be using bison -y) (if I hadn't have installed flex would it's "missing" ones have worked? What's wrong? It does configure fine! Alec checking for version 0.11 of ISL... no The following languages will be built: c,c++,fortran,java,lto,objc *** This configuration is not supported in the following subdirectories: gnattools target-libada target-libgo target-libbacktrace (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug *** removing build-x86_64-unknown-linux-gnu/libiberty/Makefile to force reconfigure *** removing build-x86_64-unknown-linux-gnu/fixincludes/Makefile to force reconfigure Noticed this in the config output, should this really be silent? Alec
Compiling GCC problems
configure went well but I keep hitting: ../.././gcc/gengtype.c:963: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1098: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1154: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1164: error: undefined reference to 'lexer_line' ../.././gcc/gengtype-parse.c:53: error: undefined reference to 'yylex(char const**)' ../.././gcc/gengtype-parse.c:1044: error: undefined reference to 'yybegin(char const*)' ../.././gcc/gengtype-parse.c:1070: error: undefined reference to 'lexer_toplevel_done' ../.././gcc/gengtype-parse.c:1075: error: undefined reference to 'yyend()' I've installed flex, bison and yacc (should it use it, it seems to be using bison -y) (if I hadn't have installed flex would it's "missing" ones have worked? What's wrong? It does configure fine! Alec
Re: gcc : c++11 : full support : eta?
On 23/01/13 07:48, Uday Khedker wrote: On Wednesday 23 January 2013 01:12 PM, Alec Teal wrote: So in all seriousness, why GCC? I suppose the volume of LLVM/Clang stuff saying how great it is is misleading? Please link GCCs half or write a good few pages on it please. This is serious I'd love to read it and know more of how the two differ. I fear this coming across as sarcastic but really no, I'd love to read such a thing. LLVM is far easier to understand and use but perhaps not as extensive and comprehensive. BTW I plan to get involved, I'm new, GCC is massive Please visit http://www.cse.iitb.ac.in/grc/ and look at the training material (eg. http://www.cse.iitb.ac.in/grc/gcc-workshop-12/index.php?page=slides). I think we need to come out of the "documentation" mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. Uday. Thank you! Alec
Re: gcc : c++11 : full support : eta?
On 23/01/13 07:11, Uday Khedker wrote: On Tuesday 22 January 2013 10:27 PM, Richard Kenner wrote: Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. That is definitely a worthwhile goal, and one that's had mixed success in the past, but: - compilers are extremely complex programs and there's a limit to how much even the best-written internals documentation can explain - even fewer people are interested and competant to write such documentation as there are to do the necessary development work This is because no matter what one has done, unless one has contributed code, one is not considered a contributor to GCC. I had said in http://gcc.gnu.org/ml/gcc/2012-11/msg00270.html So while we continue to improve the technology, we have to also give due importance to making it easier for newer people to become contributors to the technology. GCC is not just about a code that works. It is also about building succinct explanations of what that code is and why it has been designed the way it is. The way code maintainers are appointed, I think we need to identify and appoint people who would be willing to take the responsibility so that the developers could rally around such activities to make them more meaningful. We need to build a group whose primary responsibility is not development but who understand the nuances of the development and can engage with academia and attract people who can contribute to GCC. And such a group cannot be identified using the criteria of code submitted. For every piece of code, there are dozens of people who take keen interest in it, express opinion on it, review it critically and contribute to improving it because eventually it could go in the compiler. Unless there is an express statement from the steering committee that tutorials and training material should be accorded a similar status, they would remain neglected and personal projects with limited reach. Of course even in the presence of an official mandate, there is no guarantee that things will change but we would not know until we have tried :-) Uday. Dr. Uday Khedker Professor Department of Computer Science & Engg. IIT Bombay, Powai, Mumbai 400 076, India. Email : u...@cse.iitb.ac.in Homepage: http://www.cse.iitb.ac.in/~uday Phone : Office - 91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) Res. - 91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct) So in all seriousness, why GCC? I suppose the volume of LLVM/Clang stuff saying how great it is is misleading? Please link GCCs half or write a good few pages on it please. This is serious I'd love to read it and know more of how the two differ. I fear this coming across as sarcastic but really no, I'd love to read such a thing. BTW I plan to get involved, I'm new, GCC is massive Alec
hard typdef - proposal - I know it's not in the standard
Hello,
This suggestion is obviously about typdefs and discusses a *theoretical*
implementation, well a few of them. Anyway please do read this though.
I'm really sorry for the poor structure, my hands are really cold and
I'm quite tired.
I understand that this issue has been discussed A LOT and there are ways
around the limitation, I suspect what I write is nothing new, I don't
claim to be the first ever.
Why not:
make an "optional keyword", "hard", have a meaning if before "typedef",
I suggest tokenising "hard" as a normal token (however it is processed
now why change it? I am not sure on GCCs exact grammar for c languages)
but if AND ONLY if it is before a "typdef" treat it differently, as far
as I know a typedef can only occur at the beginning of a statement so
this should mean it doesn't break anything.
It'd break something if put before "struct" obviously, because struct
need not occur at the beginning of a statement, I can't see the typdef
thing being a problem, it never occurs anywhere else, and this construct
need not be valid anywhere else.
Problems:
1)Not all compilers would be happy with this.
Fix:
I'm sure gcc must define something for the preprocessor that'll exist if
and only if GCC is the compiler? Use this to create a definition for
hard (as "hard") if and only if GCC is the compiler, else define "hard"
as an empty definition (nothing), this way any other compilers wont even
see the "hard" before a typedef. If GCC recognises half without a macro
this means those using just GCC would be fine but they need only put a
constant in a header file.
I am not sure how the preprocessor would handle a keyword named constant
("#define hard hard" is what I'm thinking? Wish I could try it now) but
I am certain "#define HARD hard" would work, while ugly this does make
compatibility easy.
Pros:
The joy of many.
Alec
Sorry again for the awful new-line structure, I'm tired and my fingers
are numb.
Re: gcc : c++11 : full support : eta?
On 22/01/13 18:00, Andrew Haley wrote: On 01/22/2013 05:51 PM, Alec Teal wrote: I really just wanted a serious discussion, it failed. I should clarify: I define bitching to be "pointlessly diffusing statements so nothing gets done". Like the error thing "well actually that's a myth from some deep dark place where they used a really old GCC and a new Clang", silly, if GCC is better why is it not said "Clang has useless error reports!" OK, OK, let's all take a deep breath and make this a serious discussion, then. It's not too late. So how could we (you, I know I'm not ready) remedy this? Start telling people GCC doesn't do this legendary "folding" thing and keeps track of tokens (I read somewhere, I think it was an old paper by Mozilla about Treehydra and Dehydra (now dead) that GCC cannot map things back to lines of source code, then somewhere else that Clang can track stuff though macro-expansions, GCC turns "x-x" to "0" which causes a problem for static analysis - this is a good optimization but it's being done too early). Folding is done very early in GCC, in the front ends. It would be possible to nullify fold() so that it didn't do anything, but a few places in the compiler require it. Have an option where GCC outputs stuff that's verbose and easier for an Ide to parse, I understand a lot of stuff relies on the current way, why not that? Macros are good (if not over-used, there are some VILE ones out there) but debugging macro-ed code is the bane of any programmers' day. We know. The move to C++ will help that. I meant "out there" not with GCC, I do think macros have a use, a report of the form "expanded from: " would be helpful, and some sort of callstack-like output? If you are going to bitch in reply at least include some links to things worth reading that are ideally quite long and dirty, if you'd respond seriously, it'd be much welcome. I was honestly hoping for a good "chat" about the pros and cons, what could be done about things, you know interesting stuff, not " Stop swearing and criticising people for responses you don't like. Let he who is without sin cast the first stone. Andrew.
Re: gcc : c++11 : full support : eta?
On 22/01/13 17:47, Jonathan Wakely wrote: On 22 January 2013 16:52, NightStrike wrote: On Tue, Jan 22, 2013 at 4:41 AM, Robert Dewar wrote: Anyway, it still comes down to figuring out how to find the resources. Not clear that there is commercial interest in rapid implementation of c++11, we certainly have not heard of any such interest, and in the absence of such commercial interest, we do indeed come down to hoping to find the volunteer help that is needed. This is a hard task. A volunteer has to be both willing (easy) and able (very hard). A lot of people that work on GCC have worked on it for a gazillion years. How much code contribution in 2012 came from people who did not work on it prior? Volunteers don't necessarily need to be new volunteers. We also rely on existing volunteers continuing to do the work. Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. Of course it's worthwhile, but it's the usual story. Who's going to do it? How do you force volunteers to work on simplifying existing code and documentation? Is that higher priority than "finishing" something like C++11? Perhaps, if simplifying + documenting the existing allows a higher power (work time / unit time, not work as in "lines of code" or something) to be applied to GCC then yes it could be, perhaps this should be discussed? I am eager (I doubt I am alone!) to help with GCC, I've read countless books on compiling, created a language (work stuff, not like "c++", a scripting language, wont bore you with it), looked at how other languages are created (to anyone searching [like I was once] look up "a no frills introduction to the 5.1 Lua VM" and looking up Lua's compliler, it's implemented in Lua, C, Java... probably some others), loved it. I'd love to help with GCC, without documentation (in fact, without instructions) I have no hope of doing so. Maybe instruct/ask people to do stuff? I digress, but this certainly should be considered in more detail.
Re: gcc : c++11 : full support : eta?
On 22/01/13 17:40, Jonathan Wakely wrote: On 22 January 2013 17:30, Alec Teal wrote: You totally missed the point there. Stop being Mr Defensive btw. Stop swearing and criticising people for responses you don't like. Bitching about the year the versions of GCC and Clang were made to try and diffuse just one person's (potentially wrong) perception clang has better error reports than GCC is not what I had in mind. What makes you think I'm bitching? My point was to draw your attention to an entire wiki page on the subject of diagnostic comparisons, with examples and links to relevant bug repots, to point out we're well aware of the issue and are doing something productive about it. Ranting about Clang's impressive features achieves what exactly? I really just wanted a serious discussion, it failed. I should clarify: I define bitching to be "pointlessly diffusing statements so nothing gets done". Like the error thing "well actually that's a myth from some deep dark place where they used a really old GCC and a new Clang", silly, if GCC is better why is it not said "Clang has useless error reports!" So how could we (you, I know I'm not ready) remedy this? Start telling people GCC doesn't do this legendary "folding" thing and keeps track of tokens (I read somewhere, I think it was an old paper by Mozilla about Treehydra and Dehydra (now dead) that GCC cannot map things back to lines of source code, then somewhere else that Clang can track stuff though macro-expansions, GCC turns "x-x" to "0" which causes a problem for static analysis - this is a good optimization but it's being done too early). Have an option where GCC outputs stuff that's verbose and easier for an Ide to parse, I understand a lot of stuff relies on the current way, why not that? Macros are good (if not over-used, there are some VILE ones out there) but debugging macro-ed code is the bane of any programmers' day. If you are going to bitch in reply at least include some links to things worth reading that are ideally quite long and dirty, if you'd respond seriously, it'd be much welcome. I was honestly hoping for a good "chat" about the pros and cons, what could be done about things, you know interesting stuff, not " Stop swearing and criticising people for responses you don't like. " Alec.
Re: gcc : c++11 : full support : eta?
Sorry for totally derailing this Mayuresh Kathe. On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Andrew.
Re: gcc : c++11 : full support : eta?
You totally missed the point there. Stop being Mr Defensive btw. Bitching about the year the versions of GCC and Clang were made to try and diffuse just one person's (potentially wrong) perception clang has better error reports than GCC is not what I had in mind. Not sure what I wanted, having said that, but I never thought a mailing list for something like GCC would be this immature. Alec On 22/01/13 17:24, Jonathan Wakely wrote: On 22 January 2013 17:12, Alec Teal wrote: On 22/01/13 17:00, Jonathan Wakely wrote: Crap reply, it's just wishful thinking. Who says GCC has to or will "finish" when Clang does? Are you going to do the missing work? Or get someone else to? Do you know something those of us actually working on it don't know? If not your answer has no value. I'd like to, that's why I'm here, GCC is a massive amount of code, it's like day 3 of looking at it I realize that right now I have hope of making a worth-while contribution. I do hate the volunteer card though, it's like talking to Vegans anything problem you talk about comes down to "Well the orphans I helped in Peru ... ". A technical reason of priorities or difficulty, a link to a road map, whatever, it'd be more productive than: "Don't winge, it's done by volunteers". There is no road map. The reasons for missing features are recorded in Bugzilla or the mailing list archives, or they're just not done yet because noone's had time. Feel free to propose documentation/website patches, or just update the wiki yourself, to gather that information into once place, *that* would be more productive. A significant proportion of the people using Clang are doing so with libstdc++ not libc++, so they're using our code anyway, how do you say which is "best" there? Clang has much better error messages, I disagree, I think G++'s template argument deduction failures are far more informative. Please report bugs where you find deficiences, but make sure you've read http://gcc.gnu.org/wiki/ClangDiagnosticsComparison and are using recent versions, not repeating the unhelpful fact that Clang from 2010 has better diagnostics than GCC from 2006. LLVM is a much better IR, Clang uses less memory, it's AST can be serialized, all these things are actually REALLY good, GCC is archaic coming from a time before I was born where computers didn't have the memory to store whole programs in ram (iffy point, yes, but just go with it), hence the source->transaction->compile to object->link all objects and makefiles ALL GOOD THINGS, I am not saying "abolish Make" or use tinyCC or some extreme form of this, but times have changed, programs are so huge now that a lifetime of devotion by one person wouldn't finish them, using LLVM with some other things for a JIT is a valid use, why write your own JIT compiler when LLVM exists? You seem to have gone off on a tangent. I thought we were talking about C++11 support? Anything you write wouldn't be as good. You're one person, so seriously, why all this bitching? Rather than "define best!" why not talk about the features that are GENERALLY agreed to be good in Clang and non-existent/not as good/bad in GCC and maybe how to add them? Welcome to the list, please search the archives before assuming you're saying anything new here, we can do without yet another "why doesn't GCC be more like Clang?" derailment.
Re: gcc : c++11 : full support : eta?
On 22/01/13 17:00, Jonathan Wakely wrote: On 22 January 2013 14:29, Alec Teal wrote: On 22/01/13 14:20, Andrew Haley wrote: On 01/22/2013 12:55 PM, Alec Teal wrote: On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Nice, play the volunteer card, while not wrong that was a crap reply. Feel free to produce a better one. About the time Clang does because GCC now has to compete." How about that? Clang is currently slightly ahead and GCC really needs to change if it is to continue to be the best. Crap reply, it's just wishful thinking. Who says GCC has to or will "finish" when Clang does? Are you going to do the missing work? Or get someone else to? Do you know something those of us actually working on it don't know? If not your answer has no value. I'd like to, that's why I'm here, GCC is a massive amount of code, it's like day 3 of looking at it I realize that right now I have hope of making a worth-while contribution. I do hate the volunteer card though, it's like talking to Vegans anything problem you talk about comes down to "Well the orphans I helped in Peru ... ". A technical reason of priorities or difficulty, a link to a road map, whatever, it'd be more productive than: "Don't winge, it's done by volunteers". OR! A child requesting pudding without finishing their dinner, "eat more dinner" -> "I'm full" -> "No room for pudding" again, technically true but really unproductive. Having implemented large chunks of the C++11 standard library unpaid in my spare time, for my own reasons, I'm not competing with anyone and I'm all for Andrew pointing out there's no schedule and progress depends on factors that can't be estimated. I'm not saying getting some project managers would be a good thing! A significant proportion of the people using Clang are doing so with libstdc++ not libc++, so they're using our code anyway, how do you say which is "best" there? Clang has much better error messages, LLVM is a much better IR, Clang uses less memory, it's AST can be serialized, all these things are actually REALLY good, GCC is archaic coming from a time before I was born where computers didn't have the memory to store whole programs in ram (iffy point, yes, but just go with it), hence the source->transaction->compile to object->link all objects and makefiles ALL GOOD THINGS, I am not saying "abolish Make" or use tinyCC or some extreme form of this, but times have changed, programs are so huge now that a lifetime of devotion by one person wouldn't finish them, using LLVM with some other things for a JIT is a valid use, why write your own JIT compiler when LLVM exists? Anything you write wouldn't be as good. You're one person, so seriously, why all this bitching? Rather than "define best!" why not talk about the features that are GENERALLY agreed to be good in Clang and non-existent/not as good/bad in GCC and maybe how to add them? Alec
Re: gcc : c++11 : full support : eta?
On 22/01/13 16:57, Diego Novillo wrote: On Tue, Jan 22, 2013 at 11:52 AM, NightStrike wrote: Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. Agreed. This is one of the motivators for the code evolution projects. New developers need to find a codebase that is easier to hack than the one we found (http://gcc.gnu.org/wiki/ImprovementProjects). Documentation is a big part of that. I've been disgruntled lately as I was reading GCC is supposed to be a bitch to read! This makes it harder to be used in non-free projects, they want to avoid "piping off" GCCs forms of data or "shimmying" it off to another program, I joined this mailing list in fact because I could find no information on the matter and if this is true this is quite depressing. The thought it is that political is the depressing part, but I can see the point. Urgh it's a nasty issue and has been talked to death - I am told - where can I read what's been said already! BTW I am an eager potential contributor but really GCC is BIG! As it was argued earlier, finding such volunteers is very hard. The job is not easy and it is generally thankless. Diego.
Re: gcc : c++11 : full support : eta?
On 22/01/13 14:20, Andrew Haley wrote: On 01/22/2013 12:55 PM, Alec Teal wrote: On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Nice, play the volunteer card, while not wrong that was a crap reply. Feel free to produce a better one. About the time Clang does because GCC now has to compete." How about that? Clang is currently slightly ahead and GCC really needs to change if it is to continue to be the best. Andrew.
Re: gcc : c++11 : full support : eta?
On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Nice, play the volunteer card, while not wrong that was a crap reply. Andrew.
