Re: gcc 3.2 compile issue when initialize value

Yixuan Huang writes: > I wrote following code: > #include > #include > #include > int main() > { > struct dirent **namelist; > int numberOfProcDirs; > numberOfProcDirs=scandir("/proc", &namelist, 0, alphasort); > //std::string temp(std::string(namelist[0]->d_name)+std::string("fdsfds")); > //s

Re: Workaround for error: ??? cannot appear in a constant-expression

Jan Tusch writes: > I observed the following issue with g++-4.3.4: > > I can work around the restriction of initializing a static const integral > class member with a non-constant expression. > This violates the standard and should be rejected by "-pedantic". > Correct me, if I'm wrong. > > I cu

Re: Where does the time go?

Steven Bosscher writes: > And finally: expand. This should be just a change of IR format, from > GIMPLE to RTL. I have no idea why this pass always shows up in the top > 10 of slowest parts of GCC. Lowering passes on e.g. WHIRL, or GENERIC > lowering to GIMPLE, never show up in the compile time

Re: Code compilation with GCC and GFORTRAN

Muhammad Akbar writes: > I have a FORTRAN code that uses some c routines. I compile it with gcc > and gfortran in RedHat Linux without any problem. Recently I bought a > laptop with Ubuntu. I have gcc and gfortran version 4.4.3 in it. When > I compile the code, I see the following warning: > > wa

Re: Fw: quesitons about gcc 4.4.1

lin li writes: > I have some questions about GCC/G++ 4.4.1. The first questions is > that we find that the gcc compiler support some C99 extensions by > default. For example, the gcc 4.4 document says "New character data > types, per TR 19769: New character types in C, are now supported for > the

Re: Build error with USE_MD_CONSTRAINTS vs. CONST_OK_FOR_CONSTRAINT_P

Jeff Kuskin writes: > I'm trying to remove *all* single-letter constraints from my cpu.md > file and replace them with define_constraint entries that define > *multi-letter* constraint names. Example: (define_constraint "aFOO" > ...) > Am I *required* to define at least some of the single-lett

Re: unrecognizable insn ICE in latticemico32 (lm32-elf) when building Linux kernel

Philip Pemberton writes: > 1) Who's the current maintainer for the lm32 port? Jon Beniston? > I can't see anything on the gcc website that says definitively "target > X is maintained by $PERSON", and I really don't want to step on > his/her toes and start a flame war, turf war or any other kind o

Re: A question about _udivdi3.o in libgcc.a on Loongson platform

Ling Kun writes: >    when deeply looking into the libgcc.a of > mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file > _udivdi3.o. but when objdump this object file, no entry for function > _udivdi3 is found, only a __udivti3 function entry, and there are also > some other *di3.o file whi

Re: unrecognizable insn ICE in latticemico32 (lm32-elf) when building Linux kernel

Philip Pemberton writes: >> The address is unusual: >> >> (subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ]) >> (const_int 64 [0x40])) [0 S8 A64]) 4) >> >> Why isn't that simply >> >> (mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ]) >> (const_int 68 [0x40]))

Re: Help needed: banishing RTL from the front ends

Steven Bosscher writes: > OK, the patch at the end of this mail appears to do what I've been > trying to achieve. > Does it look correct, and acceptable for the trunk after proper testing? I'll approve the patch to system.h if testing succeeds. The patch to Makefile.in looks fine to me but I'd

Re: GFDL/GPL issues

Joern Rennecke writes: > Quoting Russ Allbery : > >> "Alfred M. Szmidt" writes: >> >>> It should be noted that Debian considers the GFDL a non-free >>> /software/ license; which it is, but then the GFDL is not a software >>> license to begin with. >> >> The official Debian position is that the d

Re: optimizing a DSO

Quentin Neill writes: > A little off topic, but by what facility does the compiler know the > linker (or assembler for that matter) is gnu? When you run configure, you can specify --with-gnu-as and/or --with-gnu-ld. If you do, the compiler will assume the GNU assembler or linker. If you do not

Re: Request for suppressing "warn_unused_result" warnings

"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes: > Can this design please be changed (or, dare I say without being > considered impolite, improved) to better accommodate for the cases > where there is indeed no reason for checking the return value? > > Making the developers jump through more complicat

Re: Request for suppressing "warn_unused_result" warnings

"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes: > Ian Lance Taylor wrote: > >> We should handle must_use_result and warn_unused_result similarly, except >> that adding a cast to (void) disables the warn_unused_result warning. >> Perhaps there should also b

Re: optimizing a DSO

Tim Prince writes: > On 5/28/2010 11:14 AM, Ian Lance Taylor wrote: >> >> When you run configure, you can specify --with-gnu-as and/or >> --with-gnu-ld. If you do, the compiler will assume the GNU assembler >> or linker. If you do not, the compiler will assum

Re: Request for suppressing "warn_unused_result" warnings

"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes: > The problem with the suggested scenario with one trusted developer > that uses this option is that other developers won't see these > warnings at all. However, IMO we can have our cake and eat it too -- > and, leave most of the involved parties genera

Re: Request for suppressing "warn_unused_result" warnings

Dave Korn writes: > On 28/05/2010 19:32, Ian Lance Taylor wrote: > >> As the compiler documentation states, warn_unused_result was intended >> for cases where failing to check the return value is always a security >

Re: Request for suppressing "warn_unused_result" warnings

Dave Korn writes: > On 28/05/2010 22:25, Ian Lance Taylor wrote: > >> The warn_unused_result extension was implemented specifically to catch >> security problems. Permitting developers to just add a cast to void >> would make it a very weak facility. > > But

Re: trampolines handling, important copyright question

Basile Starynkevitch writes: > What I am very scared of, is to make someone at FSF unhappy or angry > against me. I have a very fuzzy perception of the FSF [I'm living on a > different continent, I am not a native English speaker, etc..]. I don't > know who is an influent member of FSF and did me

Re: GCC documentation in .info

christophe.ja...@ouvaton.org writes: > I browsed your html documentation at http://gcc.gnu.org/onlinedocs/ > and would like to know if there is a way to obtain GCC documentation > in .info format from your website, as is proposed by almost all other > software projects from GNU (see > http://www.g

Re: Using C++ in GCC is OK

Mark Mitchell writes: > I am pleased to report that the GCC Steering Committee and the FSF have > approved the use of C++ in GCC itself. Of course, there's no reason for > us to use C++ features just because we can. The goal is a better > compiler for users, not a C++ code base for its own sake

Re: Using C++ in GCC is OK

Paolo Bonzini writes: > Also, in general compiler IRs are used in so many places that a > "pattern matching" style (similar to ML) actually works better than a > "class hierarchy" style. In other words, I doubt that C++ would > remove many of the switch statements we have in the code. With > re

Re: Using C++ in GCC is OK

Mark Mitchell writes: > Ian Lance Taylor wrote: > >> I have written a proposed set of C++ coding conventions on the wiki at >> http://gcc.gnu.org/wiki/CppConventions >> >> This is only a preliminary proposal. It requires fleshing out and >> discussion.

Re: Using C++ in GCC is OK

Mark Mitchell writes: > Richard Guenther wrote: > >> Btw - can we intially just link with libsup++ omitting libstdc++ so >> that we do not get the expected flood of convert-to-STL patches? >> Or is the idea of an STL free gcc bad? > > I view STL as one of the bits of low-hanging C++ fruit. I thi

Re: Using C++ in GCC is OK

Richard Guenther writes: > Overall the wiki document looks good. I'd like to disallow > > * Operators may only be overloaded for types which implement numeric > values, where the overloaded operators implement the usual numeric > semantics. > > though. My thinking here is that it would be reaso

Re: Include files search order of cross build gcc

Dongsheng Song writes: > When I cross build gcc on linux-amd64 box, I got a include files > search order error: This question is not appropriate for the mailing list g...@gcc.gnu.org. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. > /root/obj/

Re: Using C++ in GCC is OK

Rich Wallick writes: > I hope you don't mind my comment as I an not a project member, just a > long term multi-platform GCC user. With all due respect, I fail to > understand the decision to switch to C++ without being able to elucidate > the specific features of C++ that will benefit the GCC

Re: Using C++ in GCC is OK

Basile Starynkevitch writes: > On Tue, 2010-06-01 at 10:33 -0700, Ian Lance Taylor wrote: >> Here are the slides from my presentation on the topic at the 2008 GCC >> Summit: http://airs.com/ian/cxx-slides.pdf . > > > Ian, what is that status of your GCC in C++ branch? Wh

Re: Using C++ in GCC is OK

DJ Delorie writes: > My suggestions: > > * When it is appropriate to use a child class with virtual functions, >the virtual functions should all be declared as protected in the >parent class. > > At first reading, I thought you meant "all virtual functions should be > protected", but I t

Re: Using C++ in GCC is OK

DJ Delorie writes: >> I did mean that all virtual functions should be protected. > > This forbids the most useful thing about virtual functions - letting > child classes implement a public ABI defined by the base class. There are really two cases to consider, and actually the coding standard sho

Re: Using C++ in GCC is OK

Jonathan Wakely writes: > Nothing in C++ prevents a "struct" from having member functions, > constructors, base classes, virtual functions, private members etc. > If the intention is to impose a distinction between structs and > classes, based on which keyword is used to define the type, the > co

Re: Using C++ in GCC is OK

Bernd Schmidt writes: > On 06/02/2010 01:42 AM, Ian Lance Taylor wrote: >>> The 'this->' is needed when the current class and base class are both >>> templates and the name is declared in the base class, and not if it's >>> declared in the c

Re: Using C++ in GCC is OK

Gabriel Dos Reis writes: > As I matter of fact, I have comments about the conventions being put forward, > I do not know the proper way to get them reflected in the proposal. As I said earlier, send e-mail here, or update the wiki page. When updating the wiki page, please put your name on all c

Re: Using C++ in GCC is OK

DJ Delorie writes: >> 2) The parent class does not consist only of pure virtual methods. >> In that case I am arguing that all virtual methods should be >> protected. > > What about the case where the parent provides default implementations > of methods that are infrequently overridden by childre

Re: Using C++ in GCC is OK

Basile Starynkevitch writes: > On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote: >> (2) we should prefer standard solution over home-grown hacks, unless >> there is a clear demonstration of value. For example, it would be >> unwise to prefer our current VEC_xxx ove

Re: Using C++ in GCC is OK

Laurynas Biveinis writes: > 2010/6/2 Ian Lance Taylor : >> As you say, gengtype includes specific support for VEC.  Using >> std::vector instead will require some work in gengtype, but not too >> much.  Currently gengtype generates code like this for a VEC: >> >>

Re: Using C++ in GCC is OK

Jakub Jelinek writes: > But do we really want to use std::vector? The vec.h, appart from > having ugly syntactic sugar, seems to be more space efficient, has better > aliasing properties (given that it is just one pointer, you can e.g. use > restrict on it easily) and seems to have more operatio

Re: Using C++ in GCC is OK

Laurynas Biveinis writes: > 2010/6/2 Ian Lance Taylor : >>> Ian, do you have an idea on how to avoid _M_impl dependency in >>> gengtype or what else to do about it? >>> >>> Because we can trivially make gengtype mark the vector itself and mark >>&g

Re: Using C++ in GCC is OK

Richard Guenther writes: > On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylor wrote: >> Richard Guenther writes: >> >>> Overall the wiki document looks good.  I'd like to disallow >>> >>> * Operators may only be overloaded for types which imp

Re: Using C++ in GCC is OK

Robert Dewar writes: > A rather global comment. I think trying to do language > design by the flood-of-email method is dubious. I would > create a specific committee to reccommend a C++ coding > standard (preferably based on one of the standard ones > available, such as Google). And then when the

Re: Question about Machine Description

yazdanbakhsh writes: > I want to exclude XORI from the instruction set of a cpu. I deleted all the > XORI in md file. But when I compiled my program some XORI operation still > exist. how this would be possible? It could be printed directly from a .c file in your config/CPU directory. Ian

Re: Using C++ in GCC is OK

Steinar Bang writes: >> Mark Mitchell : > >> I think virtual functions are on the edge; quite useful, but do result >> in the compiler adding a pointer to data objects and in uninlinable >> indirect calls at run-time. Therefore, I would avoid them in the >> initial subset of C++ used in GCC.

Re: Puzzle about macro MIPS_PROLOGUE_TEMP_REGNUM

"Amker.Cheng" writes: >I found the temp register used for saving registers when expanding > prologue is defined by > macro MIPS_PROLOGUE_TEMP_REGNUM on mips target, like: > > #define MIPS_PROLOGUE_TEMP_REGNUM \ > (cfun->machine->interrupt_handler_p ? K0_REG_NUM : GP_REG_FIRST + 3) > > I don

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

Nathan Froyd writes: > * config/i386/i386-protos.h (ix86_print_operand): Declare. > * config/i386/i386.c (ix86_print_operand): Make non-static. > * config/i386/sol2.h (ASM_OUTPUT_CALL): Call ix86_print_operand. > * rtl.h (output_operand): Declare. > * final.c (output

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

Nathan Froyd writes: > On Fri, Jun 04, 2010 at 07:45:20AM -0700, Ian Lance Taylor wrote: >> Nathan Froyd writes: >> >* config/i386/i386-protos.h (ix86_print_operand): Declare. >> >* config/i386/i386.c (ix86_print_operand): Make non-static. >> >*

Re: Using C++ in GCC is OK

"Joseph S. Myers" writes: > On Wed, 2 Jun 2010, Bingfeng Mei wrote: > >> Converting to C++ is a major change. Does that justify to have a major >> release (5.0.0)? > > No. It's not in any way user-visible. In principle I agree with what > Zack said in

Re: Question about Machine Description

yazdanbakhsh writes: > I want to exclude all immediate or instruction. I did this by the following > define_insn > > /-- > (define_insn "iorsi3" > [(set (match_operand:SI 0 "register_operand" "=d,d") > (ior:SI (m

Re: Question about Machine Description

yazdanbakhsh writes: > I did what you said, and the same error happened :( I'm sorry you're having trouble, but if you want us to be able to help you you need to show us precisely what you did, precisely what happened, and what you expected to happen. Ian

Re: Patch pinging

NightStrike writes: > On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo wrote: >> On Wed, Jun 2, 2010 at 14:09, NightStrike wrote: >> >>> threads that haven't been addressed.  I offered to Ian to do the same >>> thing for the whole mailing list if we can make it a policy that >>> people who commit

Re: Patch pinging

Paolo Carlini writes: > On 06/07/2010 09:23 PM, NightStrike wrote: >> Annoying or not, I wasn't offering to sift through svn commit logs. >> It's very trivial for me to read through a mailing list that I already >> read, and scan for messages that say "committed to branch B at >> revision R." It

Re: Patch pinging

Paolo Carlini writes: > On 06/07/2010 10:31 PM, Ian Lance Taylor wrote: >> The question we face now is: are we willing to change our process in >> order to improve it? > Maybe. Currently, I have zero problems with it. I understand that you have no problems with the current p

Re: Patch pinging

Paolo Carlini writes: > This makes sense. Thinking out loud myself, even for irregular > contributors, the idea of a ping-man doesn't really sound right, it's a > boring and error-prone task. Can anybody think of a way to automate the > job? For patches corresponding to Bugzilla entries we alread

Re: Patch pinging

Paolo Carlini writes: > On 06/07/2010 11:16 PM, Ian Lance Taylor wrote: >> Can you expand? What kinds of process changes would be reasonable to >> make? >> > Following the terminology "irregular contributor", per Jeff message, I > would not consider unreas

Re: Pseudo frame pointer register in assembly code

"Naveen H. S" writes: > The FRAME_POINTER_REGNUM is defined a pseudo register in header file. > I am using the following macros in header file to eliminate the pseudo > arg pointer and frame pointer. > However, there are some instances of frame pointer in the assembly code. > #define ELIMINABLE

Re: Experimental Patchwork setup

"Segher Boessenkool" writes: > Jeremy has set up a Patchwork instance for us at > >http://patchwork.ozlabs.org/project/gcc/list/ . > > It is feeding from gcc-patches; the plan is to make it > automatically recognise what patches went into the tree, > probably by snooping the gcc-cvs list. > >

Re: Variadic functions

Jonas Bonn writes: > I am forwarding to you a mail that I sent to the uClibc mailing list as > I think it is actually a compiler issue. Please see below for the > original. Any tips would be greatly appreciated. This message would be more appropriate for the mailing list gcc-h...@gcc.gnu.org.

Re: internal compiler error in elim_reg_cond

Boris Boesler writes: > I get an internal compiler error with gcc-4.2.1 and my own back-end > when I support conditional execution: > > ../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c > > bug.c: In function ‘cond_assign_les0’: > bug.c:13: internal compiler error: in elim_reg_cond, at flow.c:3486 Wh

Re: internal compiler error in elim_reg_cond

Boris Boesler writes: > Am 10.06.2010 um 15:27 schrieb Ian Lance Taylor: > >> Boris Boesler writes: >> >>> I get an internal compiler error with gcc-4.2.1 and my own back-end >>> when I support conditional execution: >>> >>> ../build/

Re: GCC porting questions

"Radu Hobincu" writes: > I have written here a few weeks ago regarding some tutorials on GCC > porting and got some very interesting replies. However, I seem to have > gotten stuck with a couple of issues in spite of my massive Googling, and > I was wondering if anyone could spare a couple of min

Re: Please support coo.h

yuanbin writes: > typedef struct CBase { int i; } CBase; > typedef struct CT1 { EXTENDS(CBase) ... } CT1; > typedef struct CT2 { EXTENDS(CT1) ... } CT2; > ... > typedef struct CTN { EXTENDS(CTN_1) ... } CTN; > CTN t; > t.i=1; //need not t.CTN_1CT2.CT1.CBase.i ---complex > CBase* p=&t.CBase; /

Re: Issue with LTO/-fwhole-program

Manuel López-Ibáñez writes: > On 11 June 2010 15:26, Jan Hubicka wrote: >>> Ah, so the problem is the missing -flto in the second compilation >>> step? I think this is a bug in the compiler for not reporting this >>> somehow. Is there are PR open for this? >> >> Compiler can not report it becaus

Re: Issue with LTO/-fwhole-program

Manuel López-Ibáñez writes: > On 11 June 2010 15:04, Bingfeng Mei wrote: >> Well, mixed LTO/non-LTO is quite useful. For example, we have mixed >> C/assembly >> Application. Gold support for our target is still far away. I found >> -fwhole-program >> is very important for our size optimization

Re: GCC porting questions

"Radu Hobincu" writes: > Thanks for the reply. I scrolled a lot through the i386 md and c files. I > notice that the i386 architecture has dedicated > instructions for comparing values and ALU instructions only specify > (clobber (reg:CC FLAGS_REG)). What I do not understand is how they specify >

Re: Issue with LTO/-fwhole-program

Manuel López-Ibáñez writes: > This also means that linking your program with non-LTO+whole-program > code may lead to miscompilations without any warning, which is really > bad. I don't think it is a reasonable limitation and we will get bad > press when programs start breaking for users. They wo

Re: ld linking behaviour

Edward Peschko writes: > When I link with a shared library, for example: > > env LD_RUN_PATH="/usr/lib" /usr/bin/gcc -shared -fPIC > -L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o > blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib > /usr/lib/libconfig.so > > the ld

Re: Scheduling x86 dispatch windows

Andi Kleen writes: > But if you need more why can't you just link the whole assembler > into gcc? That would hopefully speed up compilation too > (e.g. over time the text generation of instructions could > be bypassed) It would help compilation time a little bit, but generating the assembly code

Re: Issue with LTO/-fwhole-program

David Brown writes: > Assuming I'm correct here, then perhaps there could be a warning or > error message that is triggered by breaking the ODR, and which could > be enabled automatically by the -flto flag. Perhaps existing checking > mechanisms from C++ can be used here. It's a good idea but u

Re: Issue with LTO/-fwhole-program

David Brown writes: > If -flto were to activate the -fno-common flag, would that then catch > these potential problems with a linker error? We could perhaps do that for C/C++ code, but Fortran relies on common symbols. Ian

Re: how to get instruction codes in gcc passes?

Ilya K writes: > My main aim is to build platform-dependent optimization based on the > minimizing of hamming distance between the instructions. Take a look at http://code.google.com/p/mao/ . Ian

Re: Issue with LTO/-fwhole-program

David Brown writes: > After doing a bit more reading and thinking, it seems to me that > -fwhole-program will be used in most cases where LTO is used. You use > -flto when compiling each source file, then link them with gcc with > -flto and -fwhole-program. Except in the case of libraries or ot

Re: [inliner] g++ -O[123] generates undefined symbol

Дмитрий Дьяченко writes: > Trunk g++/x86/160655 with -O0 compile test w/o errors, but with > -O[123] generates undefined symbol > Need i file a PR? It certainly looks like a bug. Please do open a bug report. Thanks. Ian

Re: Issue with LTO/-fwhole-program

"Bingfeng Mei" writes: > Actually, gold plugin is used in the original example. However, resolution > produced by plugin is bypassed due to a bug-fix by Richard. Do you have any > comment on that: > http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01116.html Sorry, I missed that. There is a bug in

Re: Issue with LTO/-fwhole-program

Richard Guenther writes: > Commons between shared libraries and a program can't work. Technically speaking, shared libraries never have common symbols. They can have defined symbols which are labelled as, in essence, "formerly common," and those can be made to work correctly under certain restr

Re: subreg against register allocation?

"Amker.Cheng" writes: > Wondering whether possible to handle multi-word mode with more accuracy, > in either subreg or IRA pass? Yes, it is possible. What you need to do is to write a split which turns the mult:DI insn into an insn which sets two separate subregs. The values for the two subregs

Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

"Paulo J. Matos" writes: > In gcc4.3.4, for my architecture: 16 BITS_PER_UNIT, 1 UNIT_PER_WORD, > with INT_TYPE_SIZE = 16 and FLOAT_TYPE_SIZE = 32, then an unsigned int > is QImode and a float is HFmode. > > However with: > float uitof(unsigned int x) { return x; } > > I get a call to the functio

Re: subreg against register allocation?

Bernd Schmidt writes: > On 06/14/2010 07:58 PM, Ian Lance Taylor wrote: >> "Amker.Cheng" writes: >> >>> Wondering whether possible to handle multi-word mode with more accuracy, >>> in either subreg or IRA pass? >> >> Yes, it is possible.

Re: subreg against register allocation?

Bernd Schmidt writes: > On 06/15/2010 12:06 AM, Ian Lance Taylor wrote: > >> Well, as you know, subregs have two meanings which look similar but >> are in fact entirely different. It's valid to set subregs of the same >> pseudo in parallel if the subregs repre

Re: subreg against register allocation?

"Amker.Cheng" writes: > here are three more questions > 1 , If I am talking the right thing, there are two insns like >"*mulsi3_1" and "*smulsi3_highpart_insn", > which set two parts of DImode pseudo regs of DImode mult. > > Since both parts pf result are used in the original

Re: subreg against register allocation?

Jeff Law writes: > Note that lower-subreg is rather conservative when determining what > subregs to lower, particularly when the pseudo appears in different > modes (ie, some accesses are via SUBREGs, others are naked REGs). So > this approach may not necessarily work. Right; it only works if a

Re: Question about Machine Description

yazdanbakhsh writes: > I'm working with GCC 2.7. I think I see your problem. > I think, It doesn't support define_predict. > I define a c function in the mips.c file and add the following lines: > > int > new_arith_operand (op, mode) > rtx op; > enum machine_mode mode; > { > if (GE

Re: GCC porting questions

"Radu Hobincu" writes: > The compiler crashes with "Segmentation fault". > 2. When I try "char c = 'c';", the compiler fails an assert: It's time to break out the debugger and look at the source code and figure out what the compiler is doing. Neither of these problems ring any sort of bell for

Re: Can GCC emit debug information to support debug uninitialized local variables

asmwarrior writes: > My question is: Is there any possible that GCC can emit some debug > information to indicate that one variable is initialed or not.(at > least in the DEBUG build mode) You didn't mention which version of gcc you are testing. With current gcc see if the -fvar-tracking option

Re: what are exactly GCC core types?

Basile Starynkevitch writes: > What are exactly GCC code types, defined in gcc/coretypes.h? They are types for which there was no obvious place to put them. > Of course, they are very important types used in GCC. And there are > probably wired in gengtype (but maybe not all of them; I didn't ch

Re: invalid insn generated

roy rosen writes: > In my port I get to gen_reload to the lines > > /* If IN is a simple operand, use gen_move_insn. */ > else if (OBJECT_P (in) || GET_CODE (in) == SUBREG) > { > static int xxx; > xxx = OBJECT_P (in); > tem = emit_insn (gen_move_insn (out, in)); >

Re: invalid insn generated

roy rosen writes: > In my port I get to gen_reload to the lines > > /* If IN is a simple operand, use gen_move_insn. */ > else if (OBJECT_P (in) || GET_CODE (in) == SUBREG) > { > static int xxx; > xxx = OBJECT_P (in); > tem = emit_insn (gen_move_insn (out, in)); >

Re: question about if_marked construct

Tom de Vries writes: > static int prop(const_tree type) > { > return type == A; > } > > static int type_hash_marked_p (const void *p) { > const_tree const type = ((const struct type_hash *) p)->type; > return ggc_marked_p (type) || prop (type); > } I would like to question your premise. The

Re: question about if_marked construct

Tom de Vries writes: > What I am really trying to do, is a bootstrap debug build of 4.3.5. > However, I ran into bug 31230. I minimized the testcase, did an > analysis, created a naive patch to test my hypothesis, tested the > patch and put it in the bug report. Now I'm looking for feedback. > >

Re: question about if_marked construct

Basile Starynkevitch writes: > On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote: >> Tom de Vries writes: >> >> > What I am really trying to do, is a bootstrap debug build of 4.3.5. >> > However, I ran into bug 31230. I minimized the testcase, did

Re: Accessor macros for target-specific types / enum reg_class -> int changes

Joern Rennecke writes: > Would patches to introduce these accessor macros be considered separately, > or should I only submit them as part of the big patch for PR44566? > Would patches for this be considered separately? I would always prefer to see smaller patches. I can't imagine any case whe

Re: About stack protector

Tomás Touceda writes: > I'm starting to dig a little bit in what gcc does to protect the stack > from overflows and attacks of that kind. I've found some docs and > patches, but they aren't really up to date. See the -fstack-protector and -fstack-check options. Ian

Re: vector register allocation

BLUE 3TOO writes: > Can anybody explain how the register allocation is handled in GCC? > Is it done together with the general register allocation? or GCC > has a separate phase to handle them separately? There is no separate vector register allocator. All classes of registers are al

Re: vector register allocation

BLUE 3TOO writes: > Ian, thanks a lot for the help. Is there any document > about IRA (e.g. how the SIMD registers of a > specific architecture is exposed to the allocation > process)? or the only option is the read the code? Vlad described IRA in a paper published in the 2007 GCC Summit proc

Re: gengtype needs for C++?

Basile Starynkevitch writes: > * I don't know exactly what should be wished with respect to templates. > Tom Tromey (in CC) have a wonderful insight in > http://gcc.gnu.org/ml/gcc/2010-06/msg00143.html but I probably did not > understood all the details & the consequences. In particular I don't >

Re: Patch pinging

NightStrike writes: > On Mon, Jun 28, 2010 at 7:39 AM, David Edelsohn wrote: >> On Mon, Jun 28, 2010 at 12:10 AM, NightStrike wrote: >> >>> Ian had confidence in me.  He also liked the proposal I set for how to >>> go about it. >> >> So who actually said no? >> >> David >> > > The Frederic guy

Re: test-suite question, dg-final/scan-file on objects?

IainS writes: > In the Obj{C,C++} testsuite we have cases where we want to check for > reasonably long ascii strings in generated data. > > At present, this is done in some places by dg-final/scan-assembler > constructs, but these can (and do) fail when the target assembler > breaks long strings

Re: Generic return types in built-in functions (C frontend)

Artem Shinkarov writes: > I'm trying to implement a support for vector shuffling. For this > purpose I would like to introduce a built-in function and lower it > down in the veclower pass. However the problem is, that I don't want > to introduce a separate built-in function for each type. So the

Re: role of executable_checksum & LTO?

Basile Starynkevitch writes: > What is the role of executable_checksum from c-common.h & generated by > genchecksum. It is used for precompiled headers. It verifies that the precompiled header was generated by precisely the same compiler as the one trying to use the precompiled header. This ap

Re: Patch pinging

NightStrike writes: > It would have been courteous for you -- or Frederic, or anyone else -- > to have communicated that to me instead of just ignoring me. Yes. I was not part of the conversation stream. I apologize on behalf of Frank (not Frederic). He should have replied. >> Giving somebo

Re: role of executable_checksum & LTO?

Basile Starynkevitch writes: > However, I see a slightly more general use of executable_checksum (or > something similar) in plugins. Imagine a plugin that store some > information somewhere (e.g. in a database) and which might reload that > information later. It could be very useful (for that

Re: role of executable_checksum & LTO?

Basile Starynkevitch writes: > Do we have a programmatical way to access configuration information from > inside plugins? (and not only version information) The configuration arguments, and the version number, are passed to the plugin in struct plugin_gcc_version. > The scenario I am considerin

<    13   14   15   16   17   18   19   20   21   22   >