Re: gengtype & many GTY tags for same union component?
Hi, Sorry for the delayed reply. > Do you think it is only my misunderstanding (as everyone noticed, my > English language is poor since it is not my native language), or a bug > of the gengtype documentation, or a bug in gengtype code? Can several > GTY tags appear for the same union component as I thought previously? The gengtype code assumes only the single tag case. It is possible to extend it to handle several tags, but I'm not sure if it's worth the effort (look at the tagid variable in the gengtype.c:walk_type). I guess that a patch for documentation to clear up this confusion would be accepted quickly, would you mind producing one? -- Laurynas
Re: Error in GCC documentation page
On 8 July 2010 07:12, Nils Schlemminger wrote: > Am 08.07.2010 00:56, schrieb Jonathan Wakely: >> >> The usage is correct in "standardese" and English. >> My dictionary gives one definition of "integral" as "denoting a number >> that is an integer". >> > > Thats correct but not all non native speaker know that. The word integer is > more common. But in the C++ standard "integral expression" is more common.
Re: complete list of emulated TLS targets.
IainS writes: > I'd like to compile a complete list of targets affected by changes in > emulated TLS. [...] > could people please add to the list/confirm as appropriate? I can add * *-*-solaris2.[89] I've got a patch almost ready that enables native TLS if a couple of prerequisites are met. While one could force that now with --enable-tls, it's completely broken. * mips-sgi-irix6.5 Will never have native TLS. * alpha-dec-osf5.1 Likewise. Hope this helps. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Error in GCC documentation page
Am 08.07.2010 10:49, schrieb Jonathan Wakely: On 8 July 2010 07:12, Nils Schlemminger wrote: Am 08.07.2010 00:56, schrieb Jonathan Wakely: The usage is correct in "standardese" and English. My dictionary gives one definition of "integral" as "denoting a number that is an integer". Thats correct but not all non native speaker know that. The word integer is more common. But in the C++ standard "integral expression" is more common. Ok point. But shall the writers of the C++ standard read the document or all developers on the world? Trust me not all c++ programmers had read the standard.
Re: Error in GCC documentation page
Nils Schlemminger wrote: Am 08.07.2010 10:49, schrieb Jonathan Wakely: On 8 July 2010 07:12, Nils Schlemminger wrote: Am 08.07.2010 00:56, schrieb Jonathan Wakely: The usage is correct in "standardese" and English. My dictionary gives one definition of "integral" as "denoting a number that is an integer". Thats correct but not all non native speaker know that. The word integer is more common. But in the C++ standard "integral expression" is more common. Ok point. But shall the writers of the C++ standard read the document or all developers on the world? Trust me not all c++ programmers had read the standard. I think integral expression is perfectly clear, and preferable
Re: Error in GCC documentation page
> > > But in the C++ standard "integral expression" is more common. "integral" is an adjective and "integer" is a noun. "integer expression", though gramatically wrong (or, at best, an elision of two nouns), is perfectly clear and unambiguous, whereas "integral expression", though gramatically correct, hits some people as "built-in expression" and trips others up as an unfamiliar and rare word whose meaning is uncertain - for what gain? Personally, I like "integral expression", but then I'm a native-English speaker and UK academic with an extended vocabulary. For world-class dovumentation, it depends whether it's more important to be clear and unambiguous to all readers or an object lesson in type-correct advanced English. I'd say our friend has pointed out a tiny place where it could be made a little more effective in the first of these purposes. M
Re: Error in GCC documentation page
... I only want to add - I said this to the OP in private email too - that we also have in widespread use expressions like 'integral constant' and even 'is_integral' (standardized in the C++0x library). Thus I don't see the point of changing now, after so many years, that specific integral in the docs where most users are likely to find *many* more integral in documentation elsewhere, in the C++ standards, etc. Paolo.
Re: Error in GCC documentation page
Paolo Carlini wrote: ... I only want to add - I said this to the OP in private email too - that we also have in widespread use expressions like 'integral constant' and even 'is_integral' (standardized in the C++0x library). Thus I don't see the point of changing now, after so many years, that specific integral in the docs where most users are likely to find *many* more integral in documentation elsewhere, in the C++ standards, etc. Integral is a perfectly good word, and furthermore I think it is better usage to choose the appropriate adjective when one is available, rather than a noun serving as an adjective. The latter is fine when there is no convenient adjective, but in this case, integral is a smoother and more natural style. For another take, though the Ada standard extensively uses the word integral, it does prefer integer type, by analogy with array type, record type etc, where no adjective is available. But as noted the C++ standard prefers integral type, so might as well standardize on that when talking about C or C++.
Re: Error in GCC documentation page
Quoting Robert Dewar : But as noted the C++ standard prefers integral type, so might as well standardize on that when talking about C or C++. I think it also helps clarity to speak of integral types. I.e. in the C family of languages, 'char' is an integral type, but you may not use the 'int' keyword for a 'char' declaration.
Re: question about if_marked construct
I can image a few ways to go from here: - leave as is, fix this when it really bothers us (risk: exchange a known problem for unknown hard-to-debug and/or hard-to-reproduce problems) - instrument if_marked functions like the one for value_expr_for_decl to assert if the from field is live and the to field is not live, and fix the asserts - extend garbage colllector to handle the problematic case (problem: more runtime and/or memory usage for garbage collection) Any suggestions on which way to go? Or make sure to walk all if_marked roots last (isn't the problem an ordering one only?) That is already done. The problem is not what happens after that walk, but during that walk. The code at that point assumes that the set of marked non-hashtable-entry objects is already stable, while the problematic if_marked functions have the effect that that set is enlarged during that walk. Hm, indeed - I know that this happens and it is not easy to avoid. If we want to fix that in the garbage collector, we could walk the problematic if_marked roots iteratively (without deleting unmarked entries), until fixed point is reached. After that we would walk (and delete unmarked entries) for both problematic and normal if_marked roots. However, I don't have good idea how we can iterate to fixed-point efficiently. Me neither. I suppose it would be nice to avoid the situation by dropping if_marked from problematic hashes. Can we at least somehow figure out which one are those? (for example by doing inefficient iteration with ENABLE_CHECKING and ICEing if the 2nd iteration changes anything?) I also considered that check, and implemented it, but later wondered whether that method would only detect problems which surface given the actual order of traversal of hash-tables and entries, and leave other problems lurking. So I created the following check: besides in_use_p and save_in_use_p, I created two other per page_entry bitmaps: root_marked_p and mark_locked_p. in_use_p is copied to root_marked_p after traversal of the root tab. During traversal of the if_marked roots, whenever an if_marked field is tested and found unmarked, it is locked to unmarked by setting mark_locked_p. This allows us to detect: - when an object that is locked to unmarked, is marked (an entry is found dead and deleted, but later found live) - when if_marked field is tested and found marked, but not root marked (an entry is live only thanks to the specific order in which we traverse over hash tables and hash table entries) Tom
Re: Error in GCC documentation page
Joern Rennecke wrote: Quoting Robert Dewar : But as noted the C++ standard prefers integral type, so might as well standardize on that when talking about C or C++. I think it also helps clarity to speak of integral types. I.e. in the C family of languages, 'char' is an integral type, but you may not use the 'int' keyword for a 'char' declaration. that's actually a good *technical* argument for systematically using integral instead of integer. If we have a glossary somewhere, we could even have an entry for integral type that pointed out that this includes char.
Re: complete list of emulated TLS targets.
On Tue, Jul 6, 2010 at 4:39 PM, IainS wrote: > I'd like to compile a complete list of targets affected by changes in > emulated TLS. > > *-*-darwin* > hppa64-hp-hpux11.11 > cris-*-elf > > I think also; > > *-*-mingw > *-*-cygwin > > could people please add to the list/confirm as appropriate? powerpc-*-aix* - David
Re: complete list of emulated TLS targets.
On 07/06/2010 10:39 PM, IainS wrote: > I'd like to compile a complete list of targets affected by changes in > emulated TLS. > > *-*-darwin* > hppa64-hp-hpux11.11 > cris-*-elf > > I think also; > > *-*-mingw > *-*-cygwin > > could people please add to the list/confirm as appropriate? I'm pretty sure bfin* is on the list. Bernd
Re: complete list of emulated TLS targets.
On Thu, Jul 8, 2010 at 9:28 PM, Bernd Schmidt wrote: > On 07/06/2010 10:39 PM, IainS wrote: >> I'd like to compile a complete list of targets affected by changes in >> emulated TLS. >> >> *-*-darwin* >> hppa64-hp-hpux11.11 >> cris-*-elf >> >> I think also; >> >> *-*-mingw >> *-*-cygwin >> >> could people please add to the list/confirm as appropriate? > > I'm pretty sure bfin* is on the list. > Yes. bfin-uclinux and bfin-linux-uclibc. Jie
Re: Error in GCC documentation page
On 8 July 2010 13:45, Robert Dewar wrote: > Joern Rennecke wrote: >> >> Quoting Robert Dewar : >> >>> But as noted the C++ standard prefers integral type, so might as well >>> standardize on that when talking about C or C++. >> >> I think it also helps clarity to speak of integral types. I.e. in the C >> family of languages, 'char' is an integral type, but you may not use the >> 'int' keyword for a 'char' declaration. > > that's actually a good *technical* argument for systematically using > integral instead of integer. If we have a glossary somewhere, we could > even have an entry for integral type that pointed out that this includes > char. There's a "Spelling, terminology and markup" section in http://gcc.gnu.org/codingconventions.html (Hoorah, I'm glad some good will come of this otherwise pretty pointless thread!)
Compilation time in gcc-4.4.0
Hi, I am writing a paper about instruction-set architecture simulators. In first time, I used gcc-4.4.0 and the compilation time reached 33 minutes (with -O3) for my simulator and the performance reached 270 MIPS (Million instruction per second). When I used the gcc-4.4.4, in the same code, the compilation time reached 39 seconds and the performance reached 600 MIPS. My code have many "switchs" with 512 "cases" and the library is in use. How to explain this behavior in the compilation and performance in my paper? Thx, -- Maxiwell Salvador Garcia MSc Computer Science Student Institute of Computing - UNICAMP "In a world without walls and fences, who needs windows and gates"
gcc-4.5-20100708 is now available
Snapshot gcc-4.5-20100708 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100708/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 161977 You'll find: gcc-4.5-20100708.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100708.tar.bz2 C front end and core compiler gcc-ada-4.5-20100708.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100708.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100708.tar.bz2 C++ front end and runtime gcc-java-4.5-20100708.tar.bz2 Java front end and runtime gcc-objc-4.5-20100708.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100708.tar.bz2The GCC testsuite Diffs from 4.5-20100701 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Two debug entries for one local variables, is it a bug in GCC or GDB
I have post this message to both GCC and GDB, because I'm not sure it
is a bug in GDB or GCC.
Hi, I have just find two dwarf debug entries for one local variables.
For example, the sample code is just like:
-
wxString ParserThread::ReadAncestorList()
{
wxString ccc;
wxString templateArgument;
wxString aaa;
aaa = m_Tokenizer.GetToken(); // eat ":"
templateArgument = aaa;
while (!TestDestroy())
{
//Peek the next token
wxString next = m_Tokenizer.PeekToken();
if (next.IsEmpty()
|| next==ParserConsts::opbrace
|| next==ParserConsts::semicolon ) // here, we are at the end of
ancestor list
{
break;
}
else if (next==ParserConsts::lt) // class AAA : BBB< int, float>
{
wxString arg = SkipAngleBraces();
if(!arg.IsEmpty()) // find a matching<>
{
templateArgument< find. Error!!!") );
}
}
...
---
But I found that GDG can show the wxString aaa correctly, but wxString
templateArgument incorrectly.
I have just check the debug information in the object file.
and found that there are two entries for local variable "argumentTemplate", but only one
entry for "aaa".
<2><40a9f>: Abbrev Number: 182 (DW_TAG_variable)
<40aa1>DW_AT_name: (indirect string, offset: 0x1095):
templateArgument
<40aa5>DW_AT_decl_file : 19
<40aa6>DW_AT_decl_line : 2593
<40aa8>DW_AT_type:<0xd168>
<40aac>DW_AT_accessibility: 3 (private)
<40aad>DW_AT_location: 2 byte block: 53 6 (DW_OP_reg3;
DW_OP_deref)
<2><40ab0>: Abbrev Number: 164 (DW_TAG_lexical_block)
<40ab2>DW_AT_ranges : 0x168
<3><40ab6>: Abbrev Number: 165 (DW_TAG_variable)
<40ab8>DW_AT_name: ccc
<40abc>DW_AT_decl_file : 19
<40abd>DW_AT_decl_line : 2592
<40abf>DW_AT_type:<0xd168>
<40ac3>DW_AT_location: 2 byte block: 91 50(DW_OP_fbreg: -48)
<3><40ac6>: Abbrev Number: 179 (DW_TAG_variable)
<40ac8>DW_AT_name: (indirect string, offset: 0x1095):
templateArgument
<40acc>DW_AT_decl_file : 19
<40acd>DW_AT_decl_line : 2593
<40acf>DW_AT_type:<0xd168>
<40ad3>DW_AT_location: 2 byte block: 91 4c(DW_OP_fbreg: -52)
<3><40ad6>: Abbrev Number: 165 (DW_TAG_variable)
<40ad8>DW_AT_name: aaa
<40adc>DW_AT_decl_file : 19
<40add>DW_AT_decl_line : 2594
<40adf>DW_AT_type:<0xd168>
<40ae3>DW_AT_location: 2 byte block: 91 48(DW_OP_fbreg: -56)
<3><40ae6>: Abbrev Number: 170 (DW_TAG_lexical_block)
--
Also, you can see the screen shot in my Codeblocks forums' post:
http://forums.codeblocks.org/index.php/topic,12873.msg86906.html#msg86906
So, my question is:
Is this a bug in GCC or GDB? ( I have just test the MinGW GCC 4.5 and MinGW
4.4.4, they get the same result)
Thanks
Asmwarrior (ollydbg from codeblocks' forum)
a few beginner questiosn
Hi, I have following questions and would appreciate any comment. Thanks you very much. 1. How to build a debugable version of GCC? I tried to set CFLGAS & CXXFLAGS to "-O0 -g -fno-inline" in my configure command line, but it seems it doesn't work. I manually modify all the Makefiles in gcc sub-directories and replace "-O2" with "-O0 -g", it is dumb but works. I guess there is a better way that I am not aware of. Can anybody tell me how to do it? 2. during the "make" process, i noticed it enters gcc-4.5.0/host-i686-pc-cygwin/gcc and build the same source files three times: E.g. first time: gcc .././gcc/c-typeck.c -o c-typeck.o 2nd time: xgcc -O2 -gtoggle .././gcc/c-typeck.c -o c-typeck.o 3rd time:xgcc -O2 -DIN_GCC .././gcc/c-typeck.c -o c-typeck.o Can anybody tells me what these compilation for? Seems that the first one is building gcc, how about 2nd and 3rd one? thanks 3. what is libgcc and newlib for? 4. what are these directories for? prev-i686-pc-cygwin/ stage1-i686-pc-cygwin/ 5. what is libssp for? what is lto-plugin for? thank you very much. _
Re: Two debug entries for one local variables, is it a bug in GCC or GDB
I reported something similar back in January:
http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html
As I recall, GCC creates duplicates.
Nenad
On 7/8/10 7:33 PM, asmwarrior wrote:
I have post this message to both GCC and GDB, because I'm not sure it
is a bug in GDB or GCC.
Hi, I have just find two dwarf debug entries for one local variables.
For example, the sample code is just like:
-
wxString ParserThread::ReadAncestorList()
{
wxString ccc;
wxString templateArgument;
wxString aaa;
aaa = m_Tokenizer.GetToken(); // eat ":"
templateArgument = aaa;
while (!TestDestroy())
{
//Peek the next token
wxString next = m_Tokenizer.PeekToken();
if (next.IsEmpty()
|| next==ParserConsts::opbrace
|| next==ParserConsts::semicolon ) // here, we are at the
end of ancestor list
{
break;
}
else if (next==ParserConsts::lt) // class AAA : BBB<
int, float>
{
wxString arg = SkipAngleBraces();
if(!arg.IsEmpty()) // find a matching<>
{
templateArgument< find. Error!!!") );
}
}
...
---
But I found that GDG can show the wxString aaa correctly, but wxString
templateArgument incorrectly.
I have just check the debug information in the object file.
and found that there are two entries for local variable
"argumentTemplate", but only one entry for "aaa".
<2><40a9f>: Abbrev Number: 182 (DW_TAG_variable)
<40aa1>DW_AT_name: (indirect string, offset: 0x1095):
templateArgument
<40aa5>DW_AT_decl_file : 19
<40aa6>DW_AT_decl_line : 2593
<40aa8>DW_AT_type:<0xd168>
<40aac>DW_AT_accessibility: 3(private)
<40aad>DW_AT_location: 2 byte block: 53 6 (DW_OP_reg3;
DW_OP_deref)
<2><40ab0>: Abbrev Number: 164 (DW_TAG_lexical_block)
<40ab2>DW_AT_ranges : 0x168
<3><40ab6>: Abbrev Number: 165 (DW_TAG_variable)
<40ab8>DW_AT_name: ccc
<40abc>DW_AT_decl_file : 19
<40abd>DW_AT_decl_line : 2592
<40abf>DW_AT_type:<0xd168>
<40ac3>DW_AT_location: 2 byte block: 91 50 (DW_OP_fbreg: -48)
<3><40ac6>: Abbrev Number: 179 (DW_TAG_variable)
<40ac8>DW_AT_name: (indirect string, offset: 0x1095):
templateArgument
<40acc>DW_AT_decl_file : 19
<40acd>DW_AT_decl_line : 2593
<40acf>DW_AT_type:<0xd168>
<40ad3>DW_AT_location: 2 byte block: 91 4c (DW_OP_fbreg: -52)
<3><40ad6>: Abbrev Number: 165 (DW_TAG_variable)
<40ad8>DW_AT_name: aaa
<40adc>DW_AT_decl_file : 19
<40add>DW_AT_decl_line : 2594
<40adf>DW_AT_type:<0xd168>
<40ae3>DW_AT_location: 2 byte block: 91 48 (DW_OP_fbreg: -56)
<3><40ae6>: Abbrev Number: 170 (DW_TAG_lexical_block)
--
Also, you can see the screen shot in my Codeblocks forums' post:
http://forums.codeblocks.org/index.php/topic,12873.msg86906.html#msg86906
So, my question is:
Is this a bug in GCC or GDB? ( I have just test the MinGW GCC 4.5 and
MinGW 4.4.4, they get the same result)
Thanks
Asmwarrior (ollydbg from codeblocks' forum)
Re: Two debug entries for one local variables, is it a bug in GCC or GDB
On 2010-7-9 13:58, Nenad Vukicevic wrote:
I reported something similar back in January:
http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html
As I recall, GCC creates duplicates.
Nenad
Thanks for the reply. I also found your message,
This bug has been fixed,see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
You bug report is related to global variables.
My problem is related to a auto variables. Especially the variable will
be returned.
Something like:
T foo()
{
T a;
T b;
T c;
...
return b;
}
then, the unreturned variable "a" and "c" works well.
But the returned variable "b" will have two debug information entries.
