Re: MyGCC and whole program static analysis
Daniel Berlin wrote: > >As some few people might already know, the GGCC (globalgcc) project is > >just starting (partly funded within the ITEA framework by french, > >spanish, swedish public money) - its kick off meeting is next week in > >Paris. > > > >GGCC aims to provide a (GPL opensource) extension to GCC for program > >wide static analysis (& optimisations) and coding rules > >validation. But this mail is not a formal announcement of it... > > > >I am also extremely interested in the LTO framework, in particular > >their persistence of GIMPLE trees. Could LTO people explain (if > >possible) if their framework is extensible (to some new Gimple nodes) > >and usable in some other setting (for example, storing program wide > >static analysis partial results, perhaps in a "project" related > >database or file). > > This is one of the goals of LTO. > > To steer this thread onto another topic, if you ever plan on getting > your "globalgcc" changes back into gcc proper, I highly suggest you do > your design and implementation discussions on gcc's mailing lists, and > coordinate with GCC people who work in those areas. GCC itself is > gearing up to start doing program wide analysis and optimization, and > I guarantee you that if you guys go off and do it on your own in > seclusion you will > 1. duplicate work > 2. make it incredibly hard to get your work back into gcc. > > Of course, if getting work into gcc is not a goal of globalgcc, than > by all means, ... The aim of globalgcc is to contribute all the new code to GCC. I think I'm also supposed to work on this project, as Albert Cohen is one of those who wrote a part of the proposal. However I still have not received any news on this project, except for the proposal that I reviewed long time ago. Sebastian
building cross-libmudflap not possible because of libtool bug?
I'm experiencing building libmudflap cross, as libtool seems not to pass --sysroot arguments to the compiler driver in link mode: /bin/sh ./libtool --mode=link /usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-linux/./gcc/xgcc -B/usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-linux/./gcc/ -B/opt/cross/sh4-linux/bin/ -B/opt/cross/sh4-linux/lib/ -isystem /opt/cross/sh4-linux/include -isystem /opt/cross/sh4-linux/sys-include -Wall -ffunction-sections -fdata-sections -O2 -g -O2 --sysroot=/opt/cross/sh4-linux -o libmudflap.la -rpath /opt/cross/lib/gcc/sh4-linux/4.1.2 -version-info `grep -v '^#' ../../../libmudflap/libtool-version` mf-runtime.lo mf-heuristics.lo mf-hooks1.lo mf-hooks2.lo -ldl /usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-linux/./gcc/xgcc -B/usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-linux/./gcc/ -B/opt/cross/sh4-linux/bin/ -B/opt/cross/sh4-linux/lib/ -isystem /opt/cross/sh4-linux/include -isystem /opt/cross/sh4-linux/sys-include -shared .libs/mf-runtime.o .libs/mf-heuristics.o .libs/mf-hooks1.o .libs/mf-hooks2.o -ldl -Wl,-soname -Wl,libmudflap.so.0 -o .libs/libmudflap.so.0.0.0 /opt/cross/bin/sh4-linux-ld: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status make[4]: *** [libmudflap.la] Error 1 Is there a recommended way to either fix libtool or libmudflap? Thanks, Richard. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs
gcc 4.2.0-20060826 - successful build and install - i386-pc-mingw32 (msys at a WinXP box)
Follows the build info: config.guess: i386-pc-mingw32 $ gcc -v Using built-in specs. Target: mingw32 Configured with: ../../source/gcc-4.2-20060826/configure --prefix=/mingw --host=mingw32 --target=mingw32 --program-prefix="" --with-as=/mingw/bin/as.exe --with-ld=/mingw/bin/ld.exe --with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared --without-x --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 4.2.0 20060826 (experimental) $ uname -a MINGW32_NT-5.1 THERGOTHON 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown host system: WinXP Pro SP2 i686 /me: Marcelo A B Slomp - Brazil -- __ Now you can search for products and services http://search.mail.com Powered by Outblaze
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote: > I think this is probably moot, since I believe that Kenny feels DWARF is > not suitable for reasons other than the abbreviation table issue, but > this is a clever technique. ... for GIMPLE; when I discussed with him, I got the impression he was still open to using it for other things, like types. I may have been mistaken. -- Daniel Jacobowitz CodeSourcery
Modifying the LABEL for functions emitted by the GCC Compiler
Hello Everyone,
I am trying to link the object file emitted by a Cross Compiler IDE
with the GCC Coldfire Linker and its libraries.
The Problem that i faced was:
The gcc-coldfire compiler spits out the labels as it is in the
assembly file (main, printf etc), where as the IDE compiler spits out
the labels prefixed with a '_' (_main, _printf etc).
Is there any way i can make gcc-coldfire compiler emit the lables
prefixed with an underscore (' _ ').Can anyone Help me OUT of this
mess!!!
Thanks in Advance,
Rohit
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Daniel Jacobowitz wrote: > On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote: > >> I think this is probably moot, since I believe that Kenny feels DWARF is >> not suitable for reasons other than the abbreviation table issue, but >> this is a clever technique. >> > > ... for GIMPLE; when I discussed with him, I got the impression he was > still open to using it for other things, like types. I may have been > mistaken. > > Given that Mark, and for that matter no one else, did not really push back, I am pretty much committed not to use dwarf. Kenny
Re: Modifying the LABEL for functions emitted by the GCC Compiler
Rohit Arul Raj wrote:
The gcc-coldfire compiler spits out the labels as it is in the
assembly file (main, printf etc), where as the IDE compiler spits out
the labels prefixed with a '_' (_main, _printf etc).
Is there any way i can make gcc-coldfire compiler emit the lables
prefixed with an underscore (' _ ').Can anyone Help me OUT of this
mess!!!
How about reconciling the -fleading-underscore options?
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Kenneth Zadeck wrote on 08/28/06 09:57:
> I have not done this because I do not rule the earth. That was not
> what I was assigned to do, and I agreed that DWARF3 sounded like a
> reasonable way to go. Now that I understand the details of DWARF3, I
> have changed my mind about the correct direction. Now is the time to
> make that change before there is a lot of infrastructure built that
> assumes the DWARF3 encoding.
>
FWIW. I agree with your conclusion. I do not know DWARF3 very well,
but it always felt a bit heavy handed to me.
At first, I was under the impression that we were going to use DWARF3 to
describe the types and symbol table, and embed our bytecode alongside.
It sounds to me like we want to either invent our own bytecode or adapt
an existing one to our needs. Inventing our own is probably the best
long-term alternative.
A few comments on the code:
> Index: lto-tree-flags.def
> [ ... ]
> +/* This file is designed to be inlined into both the writing and the
> + reading of the lto information. What it does depends on the glue
> + that put in front and at the end of this and how ADD_BASE_FLAG is
> + defined.
> +
> + For those interested in extra credit, this could also be used as
> + the checking code to see if each flag is used correctly. 10 extra
> + credit points will be given for the intrepid programmer who does
> + this and is able to removes the comment that this was generated
> + from in tree.h. */
>
Nothing in this comment helps in understanding what the file is supposed
to do. What is this used for?
> + switch (code)
> +{
> +case ABS_EXPR:
> + break;
> +
> +case ADDR_EXPR:
> + break;
> +
> + ADD_BASE_FLAG (static_flag)
>
This code is unreachable. There are many instances of this here.
> +/* Return the master clone node of N if it is available and if
> + CHECK_OVERWRITE is true, not overwritable. */
> +
What does it mean to be overwritable? You never seem to call this
function with check_overwrite == false.
> +struct char_ptr_base
> +{
> + char *ptr;
> +};
> +
Hmm? Why? Planning to have something different in the future?
> +/* An incore byte stream to buffer the various parts of the
> +function. The entire structure should be zeroed when created. The
> +record consists of a set of blocks. The first sizeof (ptr) bytes are
> +used as a chain, and the rest store the bytes to be written. */
> +
> +struct output_stream
> +{
> + /* The pointer to the first block in the stream. */
> + struct char_ptr_base * first_block;
> + /* The pointer to the last and current block in the stream. */
> + struct char_ptr_base * current_block;
> + /* The pointer to where the next char should be written. */
> + char * current_pointer;
> + /* The number of characters left in the current block. */
> + unsigned int left_in_block;
> + /* The block size of the last block allocated. */
> + unsigned int block_size;
> + /* The total number of characters written. */
> + unsigned int total_size;
> +};
> +
Maybe there's code out there for paging/caching data streams? Though we
would probably want to tweak it quite a bit, it may save some effort for
the base functionality.
Even if we end up not using DWARF3 as output, the streaming aspect of
this code will remain, I guess?
> +#if STUPID_TYPE_SYSTEM
>
STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant.
> +/* Find, or generate, if there is not one already, the abbrev table
> + entries for the various stmt_table forms. The forms in the case
> + statement here must EXACTLY MATCH the forms in the case statement
> + in output_stmt_operands. */
> +
> +static int
> +get_stmt_form (unsigned int tag)
> +{
> + int index = tag - DW_TAG_gimple_stmt_table_first;
> + int entry = stmt_form_abbrev_table[index];
> +
> + if (entry)
> +return entry;
> +
> + switch (tag)
> +{
> +case DW_TAG_gimple_asm_expr:
>
Hmm. Interesting. We can use this as a verification tool, as well.
>From here we could synthesize an up-to-date GIMPLE grammar and keep it
self-consistent. Nice.
As we find problems with the writer/reader, we should update either the
grammar or GIMPLE (or both).
> @@ -168,12 +167,6 @@ struct eh_region GTY(())
>int filter;
> } GTY ((tag ("ERT_ALLOWED_EXCEPTIONS"))) allowed;
>
> -/* The type given by a call to "throw foo();", or discovered
> - for a throw. */
> -struct eh_region_u_throw {
> - tree type;
> -} GTY ((tag ("ERT_THROW"))) throw;
> -
> /* Retain the cleanup expression even after expansion so that
> we can match up fixup regions. */
> struct eh_region_u_cleanup {
> @@ -706,13 +699,6 @@ remove_unreachable_regions (rtx insns)
> bool kill_it = true;
> switch (r->type)
> {
> - case ERT_THROW:
> - /* Don't remove ERT_THROW regions if their outer region
> - is reachable. */
> - if (r->outer && reachable[r->outer->re
Re: Modifying the LABEL for functions emitted by the GCC Compiler
Rohit Arul Raj wrote:
The gcc-coldfire compiler spits out the labels as it is in the
assembly file (main, printf etc), where as the IDE compiler spits out
the labels prefixed with a '_' (_main, _printf etc).
Is there any way i can make gcc-coldfire compiler emit the lables
prefixed with an underscore (' _ ').Can anyone Help me OUT of this
mess!!!
How about reconciling the -fleading-underscore options?
-
Yeah Thanks!!!
That works for the compiler But the problem is that how can i
force my linker to accept the labels with an '_'.
If i link with an '_' prefix i get the following error message
metro.o: In function `_main':
(.text+0xe): undefined reference to `_printf'
metro.o: In function `_main':
(.text+0x8): relocation truncated to fit: R_68K_16 against [EMAIL PROTECTED]'
sim-crt0.o: In function `start':
sim-crt0.S:(.text+0x56): undefined reference to `main'
Is there any option available in the Linker part to get round this???
ttyl,
Rohit
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote: > Given that Mark, and for that matter no one else, did not really push > back, I am pretty much committed not to use dwarf. Then... what are you going to do about things like types? Invent a new serialization for those too? I think that confusing dwarf-for-types and dwarf-for-gimple would be a mistake. -- Daniel Jacobowitz CodeSourcery
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Daniel Jacobowitz wrote: > On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote: > >> Given that Mark, and for that matter no one else, did not really push >> back, I am pretty much committed not to use dwarf. >> > > Then... what are you going to do about things like types? Invent a new > serialization for those too? I think that confusing dwarf-for-types > and dwarf-for-gimple would be a mistake. > > My part is only the function bodies, we are still going to use dwarf for the types and the global variables. There are people at codesoucery who, even as we speak, are busily enhancing that part to get all of the pieces output, not just the parts used for the debugger. Kenny
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
On Fri, Sep 01, 2006 at 10:19:07AM -0400, Kenneth Zadeck wrote: > Daniel Jacobowitz wrote: > > On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote: > > > >> Given that Mark, and for that matter no one else, did not really push > >> back, I am pretty much committed not to use dwarf. > >> > > > > Then... what are you going to do about things like types? Invent a new > > serialization for those too? I think that confusing dwarf-for-types > > and dwarf-for-gimple would be a mistake. > > > > > My part is only the function bodies, we are still going to use dwarf for > the types and the global variables. There are people at codesoucery > who, even as we speak, are busily enhancing that part to get all of the > pieces output, not just the parts used for the debugger. OK, violent agreement. Thanks for clarifying. -- Daniel Jacobowitz CodeSourcery
Re: Inserting function calls
First of all, thanx all for all your help, I'm finally seeing the light at the end of this long tunnel ;-) one possibility is that the t[i-1] load got moved out of the loop by PRE; could you check that the load is still present in the loop? Zdenek You're right, the load was moved to the outer loop... I still have 2 more questions : - How can I get the address of the load in question and pass it to the function. I've looked around in the code but haven't found anything similar. DR_MEMTAG seems to give an alias but how can I use that ? - I am currently working on loop modification, is it difficult to expand to the whole program, thus looking at each loop and at what level should I include my PASS in the passes.c file ? Jc - Degskalle There is no point in arguing with an idiot, they will just drag you down to their level and beat you with experience Référence: http://www.bash.org/?latest -
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Diego Novillo wrote:
> Kenneth Zadeck wrote on 08/28/06 09:57:
>
>
>> I have not done this because I do not rule the earth. That was not
>> what I was assigned to do, and I agreed that DWARF3 sounded like a
>> reasonable way to go. Now that I understand the details of DWARF3, I
>> have changed my mind about the correct direction. Now is the time to
>> make that change before there is a lot of infrastructure built that
>> assumes the DWARF3 encoding.
>>
>>
> FWIW. I agree with your conclusion. I do not know DWARF3 very well,
> but it always felt a bit heavy handed to me.
>
> At first, I was under the impression that we were going to use DWARF3 to
> describe the types and symbol table, and embed our bytecode alongside.
> It sounds to me like we want to either invent our own bytecode or adapt
> an existing one to our needs. Inventing our own is probably the best
> long-term alternative.
>
> A few comments on the code:
>
>
>> Index: lto-tree-flags.def
>> [ ... ]
>> +/* This file is designed to be inlined into both the writing and the
>> + reading of the lto information. What it does depends on the glue
>> + that put in front and at the end of this and how ADD_BASE_FLAG is
>> + defined.
>> +
>> + For those interested in extra credit, this could also be used as
>> + the checking code to see if each flag is used correctly. 10 extra
>> + credit points will be given for the intrepid programmer who does
>> + this and is able to removes the comment that this was generated
>> + from in tree.h. */
>>
>>
> Nothing in this comment helps in understanding what the file is supposed
> to do. What is this used for?
>
When I get the other side of the code finished and enhance the comments,
you will see.
>
>> + switch (code)
>> +{
>> +case ABS_EXPR:
>> + break;
>> +
>> +case ADDR_EXPR:
>> + break;
>> +
>> + ADD_BASE_FLAG (static_flag)
>>
>>
> This code is unreachable. There are many instances of this here.
>
>
>
I would have found that when I wrote the code that reads this back.
>> +/* Return the master clone node of N if it is available and if
>> + CHECK_OVERWRITE is true, not overwritable. */
>> +
>>
> What does it mean to be overwritable? You never seem to call this
> function with check_overwrite == false.
>
>
I have no idea what overwritable is used for. This is something that
honza and I went around many times on when I was writing my ipa code.
It appears that you can put attributes on some functions that allow the
function to replaced late, like at link or even runtime.
For instance, when I was doing my pure-const analysis, I have to mark
these as not being pure or const even if they looked like they could be
since they could be replaced by versions that were not pure or const.
However, here, I need the master clone node, but I do not care if it is
overwritable, I have to put it out anyway.
I do call it that way now. Thanks for noticing.
>
>> +struct char_ptr_base
>> +{
>> + char *ptr;
>> +};
>> +
>>
> Hmm? Why? Planning to have something different in the future?
>
>
>
>> +/* An incore byte stream to buffer the various parts of the
>> +function. The entire structure should be zeroed when created. The
>> +record consists of a set of blocks. The first sizeof (ptr) bytes are
>> +used as a chain, and the rest store the bytes to be written. */
>> +
>> +struct output_stream
>> +{
>> + /* The pointer to the first block in the stream. */
>> + struct char_ptr_base * first_block;
>> + /* The pointer to the last and current block in the stream. */
>> + struct char_ptr_base * current_block;
>> + /* The pointer to where the next char should be written. */
>> + char * current_pointer;
>> + /* The number of characters left in the current block. */
>> + unsigned int left_in_block;
>> + /* The block size of the last block allocated. */
>> + unsigned int block_size;
>> + /* The total number of characters written. */
>> + unsigned int total_size;
>> +};
>> +
>>
> Maybe there's code out there for paging/caching data streams? Though we
> would probably want to tweak it quite a bit, it may save some effort for
> the base functionality.
>
> Even if we end up not using DWARF3 as output, the streaming aspect of
> this code will remain, I guess?
>
>
Yes, the streaming remains, I need to do it this way so that I can then
pass some of the buffers into a compressor.
I had thought of using obstacks, they were close but they were a little
wierd.
>> +#if STUPID_TYPE_SYSTEM
>>
>>
> STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant.
>
>
>> +/* Find, or generate, if there is not one already, the abbrev table
>> + entries for the various stmt_table forms. The forms in the case
>> + statement here must EXACTLY MATCH the forms in the case statement
>> + in output_stmt_operands. */
>> +
>> +static int
>> +get_stmt_form (unsigned int tag)
>> +{
>> + int index = tag -
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
On Fri, 2006-09-01 at 09:51 -0400, Diego Novillo wrote: > > > +#if STUPID_TYPE_SYSTEM > > > STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant. Well it right now it is stupid, this is just a work around anyways until people fix the type mismatches really. Is it more insulting than having stupid.c which existed in GCC before 3.0.0? Also this is very temporary and will go away when the problem in the rest of the compiler is fixed. -- Pinski
Re: building cross-libmudflap not possible because of libtool bug?
On Fri, 2006-09-01 at 13:08 +0200, Richard Guenther wrote: > I'm experiencing building libmudflap cross, as libtool seems not to > pass --sysroot arguments to the compiler driver in link mode: > /opt/cross/bin/sh4-linux-ld: crti.o: No such file: No such file or > directory > collect2: ld returned 1 exit status > make[4]: *** [libmudflap.la] Error 1 > > Is there a recommended way to either fix libtool or libmudflap? I don't understand why you are having so much problem with cross builds. I just did one yesterday with the trunk with --with-sysroot and it worked without any issue. You really should show your structure and options you passed to GCC to get anymore attention to this because there is not enough information to figure out what is going wrong. Oh and I did not need any hacks to get it building too. -- Pinski
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Andrew Pinski wrote: > On Fri, 2006-09-01 at 09:51 -0400, Diego Novillo wrote: > >>> +#if STUPID_TYPE_SYSTEM >>> >>> >> STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant. >> > > Well it right now it is stupid, this is just a work around anyways until > people fix the type mismatches really. Is it more insulting than having > stupid.c which existed in GCC before 3.0.0? Also this is very temporary > and will go away when the problem in the rest of the compiler is fixed. > > -- Pinski > > I will tone it down, the point has been made. kenny
gimple tuples branch?
Hi folks! You might have thought I've been drinking pi~na coladas in the sun, but alas, I've been beating my head mercilessly with this gimple tuple business. What I have so far is getting so big (280k), it's getting hard to manage and keep track of things in my brain. What do you guys think about creating a branch for the tuples work? This will help me keep track of things, plus others can see/comment/contribute on what I'm doing. If this is ok, I would think a branch from mainline would be best, but I'm open for suggestions (lto?). Aldy
Re: gimple tuples branch?
On Fri, 2006-09-01 at 11:21 -0400, Aldy Hernandez wrote: > If this is ok, I would think a branch from mainline would be best, but > I'm open for suggestions (lto?). Yes PLEASE. LTO is broken for most unusual languages so it is hard to test on weird parts of gimple so I would use the mainline. Also branches can be opened by anyone who has write access and does not need permission to have a branch. Thanks, Andrew Pinski
Re: gimple tuples branch?
Aldy Hernandez wrote on 09/01/06 11:21: > If this is ok, I would think a branch from mainline would be best, but > I'm open for suggestions (lto?). > I too prefer a branch off of mainline. Even though LTO will probably benefit from this, this is fairly independent and will probably be in mergeable shape before LTO. We should notice memory saving improvements (if there are any to be found). If needed, LTO could take patches out of this branch.
gcc-4.2 snapshot build problem
Hi! I like to test the weekly snapshots of the active development branch against code that I am particularly interested in. I realize that snapshots are just that - and so do not worry unless I see the same failure a couple of weeks in row. However for the past several weeks, I have not been able to get gcc-4.2 to even BUILD on some of the architectures that I am interested in: alphaev68-dec-osf5.1b ia64-unknown-linux-gnu i386-pc-solaris2.10 i386-pc-solaris2.9 I had no problem building gcc-4.1.1 on these architectures. I have tried reporting the build failures to bugzilla (see #27843) but have not gotten any response. Perhaps I did not label my bug report correctly? (There always seem to be so many labels with bugzilla.) Any help would be gratefully received. Kate Minola University of Maryland, College Park
[Ada] Cross-compiling with gprmake
Hi, I'd like to use gprmake to cross-compile a mixed language project, but I don't know how to pass the RTS directory (--RTS=abc) to gprmake. BTW, where can I find the documentation for gprmake? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: gcc-4.2 snapshot build problem
On Fri, Sep 01, 2006 at 11:51:54AM -0400, Kate Minola wrote: > Hi! > > I like to test the weekly snapshots of the active development > branch against code that I am particularly interested in. > > I realize that snapshots are just that - and so do not > worry unless I see the same failure a couple of weeks in row. > > However for the past several weeks, I have not been able > to get gcc-4.2 to even BUILD on some of the architectures > that I am interested in: > >alphaev68-dec-osf5.1b >ia64-unknown-linux-gnu >i386-pc-solaris2.10 >i386-pc-solaris2.9 > > I had no problem building gcc-4.1.1 on these architectures. > > I have tried reporting the build failures to bugzilla (see #27843) > but have not gotten any response. Perhaps I did not > label my bug report correctly? (There always seem to be so > many labels with bugzilla.) > > Any help would be gratefully received. The installation instructions strongly recommend not building in the source directory, and using a full pathname for configure. I don't know if this is related to your problems, but failures due to building in the source tree take lots of unexpected forms. Also take a look at the target-specific installation instructions, which might recommend using specific tools. Janis
Re: gets is not too dangerous
Miguel Angel Champin Catalan wrote: Hello: We are students of computer sciences in the Santa Maria University, Chile. We just want to know if the function "gets" it's too dangerous for a warning. The fact is that our teacher's assistant give us a homework, and one restriction was to use gcc to compile our code, without warnings. We ask you for a simple explanation (if it's possible) about our warning, telling that "gets" is not too dangerous, because in our case, works perfectly, under some restrictions obviously. Instead of using gets(), use fgets(). It's similar in function and easy to use, but doesn't permit overwriting the input buffer. As a university student, I would hope that you would want to learn the best way to do a task. Your teacher's assistant seems to be encouraging you to use best practices. The difference between poor practice and good practice usually comes down to that poor practice "works perfectly, in our case, under some restrictions", while good practice just "works perfectly". -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: gets is not too dangerous
Michael Eager wrote: Miguel Angel Champin Catalan wrote: Hello: We are students of computer sciences in the Santa Maria University, Chile. We just want to know if the function "gets" it's too dangerous for a warning. The fact is that our teacher's assistant give us a homework, and one restriction was to use gcc to compile our code, without warnings. We ask you for a simple explanation (if it's possible) about our warning, telling that "gets" is not too dangerous, because in our case, works perfectly, under some restrictions obviously. Instead of using gets(), use fgets(). It's similar in function and easy to use, but doesn't permit overwriting the input buffer. ^^^ overrunning As a university student, I would hope that you would want to learn the best way to do a task. Your teacher's assistant seems to be encouraging you to use best practices. The difference between poor practice and good practice usually comes down to that poor practice "works perfectly, in our case, under some restrictions", while good practice just "works perfectly". -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Help running a SPARC/Ada test case?
Is there anyone out there who might have a SPARC environment with Ada support who could run the attached Ada testcase on a version of gcc patched with the attached patch? I'd like to verify whether the test behaves correctly when compiled at -O0, -O1, and -O2. The expected (correct) behavior is the following output: a_value= 10 b_value= 20 This was a little vague so I used "gcc version 4.2.0 20060805" which is the most recent compiler with Ada support I have on SPARC. The testcase runs correctly at -O0, -O1 and -O2 when compiled with the patched compiler. The size of the frame went down from 216 to 200 bytes at -O2. -- Eric Botcazou
Re: Help running a SPARC/Ada test case?
Eric Botcazou wrote: >> Is there anyone out there who might have a SPARC environment with Ada >> support who could run the attached Ada testcase on a version of gcc >> patched with the attached patch? I'd like to verify whether the test >> behaves correctly when compiled at -O0, -O1, and -O2. The expected >> (correct) behavior is the following output: >> >> a_value= 10 b_value= 20 > > This was a little vague so I used "gcc version 4.2.0 20060805" which is > the most recent compiler with Ada support I have on SPARC. The > testcase runs correctly at -O0, -O1 and -O2 when compiled with the > patched compiler. The size of the frame went down from 216 to 200 bytes > at -O2. Great - thanks. I really appreciate your help. - Josh
gcc-4.1-20060901 is now available
Snapshot gcc-4.1-20060901 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060901/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 116642 You'll find: gcc-4.1-20060901.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060901.tar.bz2 C front end and core compiler gcc-ada-4.1-20060901.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060901.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060901.tar.bz2 C++ front end and runtime gcc-java-4.1-20060901.tar.bz2 Java front end and runtime gcc-objc-4.1-20060901.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060901.tar.bz2The GCC testsuite Diffs from 4.1-20060825 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
GCC 4.3 Projects Page
Since we're making some headway on GCC 4.2, it's now time to start thinking about GCC 4.3. As for the past couple of releases, let's start by trying to gather information about what people are planning to contribute for GCC 4.3. Please add your project page to the bottom of: http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning In this cycle, I'm going to try to prioritize projects for Stage 1 by readiness (e.g., has your patch already been tested fully? is it current with mainline? has the patch already been approved?), and then by time of original submission to gcc-patches. I want to make sure that anything that fell through the cracks for 4.2 gets first priority for 4.3. Since the idea is that you prepare major patches for Stage 1 during the previous release cycle, if you haven't started writing it now, and you want it in 4.3, please type quickly. The 4.2 branch will not be created before September 18th, even if we make enough progress to make that possible, so that everyone has plenty of time to list their projects. The 4.2 branch may be created later than September 18th, if either (a) 4.2 isn't looking solid enough, or (b) we need more time to get 4.3 organized. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3 Projects Page
On Fri, Sep 01, 2006 at 03:56:30PM -0700, Mark Mitchell wrote: > Please add your project page to the bottom of: > > http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning BTW, that page provides a link to "SampleProjectPage" which does not exist.
Re: gcc.target/powerpc vs -m64
FAIL: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm [0-9]+, [0-9]+,0,0,30 FAIL: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm [0-9]+, [0-9]+,0,29,30 FAIL: gcc.target/powerpc/ppc-negeq0-1.c scan-assembler-not cntlzw are a tad confusing because if I do... gcc-4 -O2 -m64 -S -c ppc-and-1.c grep rlwinm ppc-and-1.s rlwinm r4,r4,0,0,30 rlwinm r4,r4,0,29,30 grep rldicr ppc-and-1.s (no results) This is confusing because it suggests the test *should* be passing! The Darwin assembler expects GPR references to be written like "r4", every other assembler wants just "4". The regexp in this scan-assembler stmt seems to accept only the latter. This testcase has been failing on Darwin since forever I expect? Segher
Re: GCC 4.3 Projects Page
Joe Buck wrote: On Fri, Sep 01, 2006 at 03:56:30PM -0700, Mark Mitchell wrote: Please add your project page to the bottom of: http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning BTW, that page provides a link to "SampleProjectPage" which does not exist. Thanks! I forgot which Wiki syntax I was using; that's now fixed. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Many new ICEs in the libstdc++-v3 testsuite
Hi, a very recent compiler change (less than 24 hours: compare, for example, the testresults for i386-unknown-netbsdelf3.0) is causing many ICEs in the ext/pb_ds testcases: FAIL: ext/pb_ds/example/basic_map.cc (test for excess errors) WARNING: ext/pb_ds/example/basic_map.cc compilation failed to produce executable FAIL: ext/pb_ds/example/basic_multimap.cc (test for excess errors) WARNING: ext/pb_ds/example/basic_multimap.cc compilation failed to produce executable FAIL: ext/pb_ds/example/basic_multiset.cc (test for excess errors) WARNING: ext/pb_ds/example/basic_multiset.cc compilation failed to produce executable FAIL: ext/pb_ds/example/basic_priority_queue.cc (test for excess errors) WARNING: ext/pb_ds/example/basic_priority_queue.cc compilation failed to produce executable FAIL: ext/pb_ds/example/basic_set.cc (test for excess errors) WARNING: ext/pb_ds/example/basic_set.cc compilation failed to produce executable FAIL: ext/pb_ds/example/erase_if.cc (test for excess errors) WARNING: ext/pb_ds/example/erase_if.cc compilation failed to produce executable FAIL: ext/pb_ds/example/hash_find_neg.cc (test for excess errors) FAIL: ext/pb_ds/example/hash_illegal_resize.cc (test for excess errors) WARNING: ext/pb_ds/example/hash_illegal_resize.cc compilation failed to produce executable FAIL: ext/pb_ds/example/hash_initial_size.cc (test for excess errors) WARNING: ext/pb_ds/example/hash_initial_size.cc compilation failed to produce executable FAIL: ext/pb_ds/example/hash_load_set_change.cc (test for excess errors) WARNING: ext/pb_ds/example/hash_load_set_change.cc compilation failed to produce executable FAIL: ext/pb_ds/example/hash_mod.cc (test for excess errors) WARNING: ext/pb_ds/example/hash_mod.cc compilation failed to produce executable FAIL: ext/pb_ds/example/hash_resize.cc (test for excess errors) WARNING: ext/pb_ds/example/hash_resize.cc compilation failed to produce executable FAIL: ext/pb_ds/example/hash_shift_mask.cc (test for excess errors) WARNING: ext/pb_ds/example/hash_shift_mask.cc compilation failed to produce executable FAIL: ext/pb_ds/example/priority_queue_dijkstra.cc (test for excess errors) WARNING: ext/pb_ds/example/priority_queue_dijkstra.cc compilation failed to produce executable FAIL: ext/pb_ds/example/priority_queue_erase_if.cc (test for excess errors) WARNING: ext/pb_ds/example/priority_queue_erase_if.cc compilation failed to produce executable FAIL: ext/pb_ds/example/priority_queue_split_join.cc (test for excess errors) WARNING: ext/pb_ds/example/priority_queue_split_join.cc compilation failed to produce executable FAIL: ext/pb_ds/example/priority_queue_xref.cc (test for excess errors) WARNING: ext/pb_ds/example/priority_queue_xref.cc compilation failed to produce executable FAIL: ext/pb_ds/example/ranged_hash.cc (test for excess errors) WARNING: ext/pb_ds/example/ranged_hash.cc compilation failed to produce executable FAIL: ext/pb_ds/example/store_hash.cc (test for excess errors) WARNING: ext/pb_ds/example/store_hash.cc compilation failed to produce executable FAIL: ext/pb_ds/example/tree_intervals.cc (test for excess errors) WARNING: ext/pb_ds/example/tree_intervals.cc compilation failed to produce executable FAIL: ext/pb_ds/example/tree_join.cc (test for excess errors) WARNING: ext/pb_ds/example/tree_join.cc compilation failed to produce executable FAIL: ext/pb_ds/example/tree_order_statistics.cc (test for excess errors) WARNING: ext/pb_ds/example/tree_order_statistics.cc compilation failed to produce executable FAIL: ext/pb_ds/example/tree_order_statistics_join.cc (test for excess errors) WARNING: ext/pb_ds/example/tree_order_statistics_join.cc compilation failed to produce executable FAIL: ext/pb_ds/example/trie_dna.cc (test for excess errors) WARNING: ext/pb_ds/example/trie_dna.cc compilation failed to produce executable FAIL: ext/pb_ds/example/trie_prefix_search.cc (test for excess errors) WARNING: ext/pb_ds/example/trie_prefix_search.cc compilation failed to produce executable FAIL: ext/pb_ds/example/trie_split.cc (test for excess errors) WARNING: ext/pb_ds/example/trie_split.cc compilation failed to produce executable FAIL: ext/pb_ds/regression/associative_containers.cc (test for excess errors) WARNING: ext/pb_ds/regression/associative_containers.cc compilation failed to produce executable FAIL: ext/pb_ds/regression/hash_data_map_rand.cc (test for excess errors) WARNING: ext/pb_ds/regression/hash_data_map_rand.cc compilation failed to produce executable FAIL: ext/pb_ds/regression/hash_no_data_map_rand.cc (test for excess errors) WARNING: ext/pb_ds/regression/hash_no_data_map_rand.cc compilation failed to produce executable FAIL: ext/pb_ds/regression/priority_queue_rand.cc (test for excess errors) WARNING: ext/pb_ds/regression/priority_queue_rand.cc compilation failed to produce executable FAIL: ext/pb_ds/regression/priority_queues.cc (test for excess errors) WARNING: ext/pb_ds/regression/priority_queues.cc compi
Re: Many new ICEs in the libstdc++-v3 testsuite
> > Hi, > > a very recent compiler change (less than 24 hours: compare, for example, > the testresults for i386-unknown-netbsdelf3.0) is causing many ICEs in > the ext/pb_ds testcases: And this part of the log helps us how? We really need to know the ICE to figure out what is going wrong. -- Pinski
Re: Many new ICEs in the libstdc++-v3 testsuite
Andrew Pinski wrote: And this part of the log helps us how? But I don't want to help you, I want you to fix it ;) Just run the testsuite to the end and you will see everything: all plain Segmentation faults. Paolo.
Re: Many new ICEs in the libstdc++-v3 testsuite
> > Andrew Pinski wrote: > > >And this part of the log helps us how? > > > > > But I don't want to help you, I want you to fix it ;) Just run the > testsuite to the end and you will see everything: all plain Segmentation > faults. This was caused by: http://gcc.gnu.org/viewcvs?view=rev&revision=116623 Because revision 116619 worked but revision 11623 failed. 116619's testresults: http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00023.html 116623's testresults: http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00036.html -- Pinski
Re: libstdc++, -m64 and can't find atom for N_GSYM stabs
Once the noise from those linker warnings is removed from the libstdc++-v3 testsuite results at -m64 on Darwin PPC, we find that the failures drop from 54 to just 6. So we actually only have four additional libstdc++-v3 testsuite failures at -m64 compared to -m32. These are... FAIL: 21_strings/basic_string/cons/char/1.cc execution test FAIL: 21_strings/basic_string/cons/wchar_t/1.cc execution test FAIL: 21_strings/basic_string/insert/char/1.cc execution test FAIL: 21_strings/basic_string/insert/wchar_t/1.cc execution test which certainly would appear as if they are all related bugs. Can you try the above check on x86_64 and see how many regressions you have when the linker warnings suppressed? For i386 vs x86_64 I'm getting a different set of pass/fail between the two. I do, however, have those 4 failures on x86_64 and not on i386. -eric
