Re: ggc 3.3.2 on aix 5.2 long long type?
I am not sure, but it seems that this should have been sent to [EMAIL PROTECTED] (it seems to be off-topic). Is this scsi_buf.h a system header file? Is it enough to have an empty c file with a single #include to trigger the warning? >From an experience I had 2 weeks ago with gcc+aix, gcc can't work well on AIX-5.3 if it was compiled with AIX-5.1. It is probably correct for AIX-5.2 as well. It has something to do with fixincludes that copies system header files from AIX-5.1 (when installing gcc under AIX-5.1), and then if you try to mix it with AIX-5.3 things become weird. Are you sure that you have gcc compiled and installed on the same AIX version that gives you the warnings? You can get this information by running gcc -v (look for --host in the text). I don't have an AIX machine near me at the moment, so I can't validate your problem. It is also possible that fixincludes should be enhanced to fix your system's scsi_buf.h. -- Michael Quoting "sabreman (sent by Nabble.com)" <[EMAIL PROTECTED]>: > > I getting the following warning with unsigned long long world_wide_name; > (scsi_buf.h). > > warning : integer constant is too large for "long" type. > > Is there a swich I need to add? > > I am just using: gcc -o test test.c > > Thanks! > -- > View this message in context: > http://www.nabble.com/ggc-3.3.2-on-aix-5.2-long-long-type--t890504.html#a2308440 > Sent from the gcc - Dev forum at Nabble.com. > >
Cross compiling libstc++-v3 fails
In configure script, line 2580, there is a link test which checks if an executable can be generated. The config.log file emits the following errors: /usr/local/bin/rdos-ld: unrecognised emulation mode: -o Supported emulations: elf_i386 collect2: ld returned status 1 exit status. This error later in the configure scripts leads to an abort with "Link tests are not allowed after GCC_NO_EXECUTABLES". To try to figure out this problem, I manully compiled the same file with the same options using the same compiler (xgcc), and it returns the same error. I then tried to use the cross-compiler built using gcc-4.1-20051008, with which I can build other executables, and it returns the same error. Only if I remove the "-B/usr/src/toolchain/gcc-4.2-20060107/host-i686-pc-linux-gnu/gcc" option, does it generate the executable without any errors. How can this include give ld the wrong emulation mode? Apparently, there is no "-o" in any file in the build-directory. Is this a known problem? Leif Ekblad
Fwd: Re: matrix linking
Beg your pardon, I lost the CC. regards. - Forwarded message from [EMAIL PROTECTED] - Date: Wed, 11 Jan 2006 02:16:10 -0600 From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: Re: matrix linking To: Sean Callanan <[EMAIL PROTECTED]> Dear Sean. Thank you very much for you reply. I will try to answer for some of your questions. > In short, you are proposing that instead of linking an executable, it > be made into a bunch of shared libraries. The function calls > between these shared libraries be arbitrated by a "dispatcher" which > can dynamically reroute function calls. In short yes. > There already exists a technique to do this if you're willing to > restart your app: incremental linking. Many IDEs support something > like this (it's called ZeroLink in Apple's Xcode, for example), and > even GNU ld has the -r option, which makes an object file > relocatable, making it quicker to link. Incremental linking is quite different thing; it goes in parallel with idea of Matrix Linking. For instance those modules which take part in matrix linking might be linked incrementally, do not see any problems here. > If you want to be able to do this without restarting, there are some > challenges: A lot of challenges here. A mess of them. Therefore I raised a site, to collect everything I have got on the matter, therefore if you would not mind I will put these one you mentioned to the schedule. > 1) Static variables in modules would present problems, as these would > have to somehow be reinitialized to their values in the old module > (for instance, if you have a static pointer to a malloc()ed data > structure). > 2) If you plan to interpret code, the C interpreter would have to be > taught to access symbols in other modules if they are undefined in > the module it is interpreting. Interpreter is the weakest thing here, its communication with compiled code especially. By now I am trying to modify GCC (cc1) in such way it would be possible to apply matrix linking for .C modules only, C++ by now looks to be unsolvable task, that was the purpose of my writing, actually. > > 3) You would have to figure out how to interpose on functions called > via function pointers. > 4) In a multithreaded application, you'd have to make sure that > module replacement is atomic and you handle the case of replacing a > module at a time where a thread is executing a function in it. Some solutions I am putting here: http://docs.georgeshagov.com/twiki/tiki-index.php In a very brief. Let me get back to my initial purpose. I need some kind of assistance with cc1 sources. Videlicet I am trying to modify it in such way that during the compilation of .C module on function description it would automatically produce additional code (stub-function), and proxy function. These ones to be compiled by some template, its compiled code (I thing the assembler) is to be inserted in the original module. The entire calls to the function are to be redirected through the external matrix. This is my initial plan. I can not say I am not able to do it by myself, but if someone from GCC team would assist that would be just perfect. I mean both, the architectural approach and details of implementation. I have some specific question regarding GCC code, but by now the question is: will someone from GCC team cooperate or not? That is my initial purpose. Sincerely yours, George. Quoting Sean Callanan <[EMAIL PROTECTED]>: > In short, you are proposing that instead of linking an executable, it > be made into a bunch of shared libraries. The function calls > between these shared libraries be arbitrated by a "dispatcher" which > can dynamically reroute function calls. > > There already exists a technique to do this if you're willing to > restart your app: incremental linking. Many IDEs support something > like this (it's called ZeroLink in Apple's Xcode, for example), and > even GNU ld has the -r option, which makes an object file > relocatable, making it quicker to link. > > If you want to be able to do this without restarting, there are some > challenges: > > 1) Static variables in modules would present problems, as these would > have to somehow be reinitialized to their values in the old module > (for instance, if you have a static pointer to a malloc()ed data > structure). > > 2) If you plan to interpret code, the C interpreter would have to be > taught to access symbols in other modules if they are undefined in > the module it is interpreting. > > 3) You would have to figure out how to interpose on functions called > via function pointers. > > 4) In a multithreaded application, you'd have to make sure that > module replacement is atomic and you handle the case of replacing a > module at a time where a thread is executing a function in it. > > Perhaps others on this list can come up with more issues to resolve. > If you can come up with a solid system that addresses the issues > with dynamic r
Re: Missing GNAT docs
On 10 Jan 2006, Jonathan Wakely uttered the following: > I can't help to put the 3.4.5 docs there, but the 3.4.4 docs are > available, just change the 5 in the broken URLs to a 4. > > I don't know for certain, but I doubt the changes were very significant. A brief `svn diff' shows that there were no changes at all. -- `I must caution that dipping fingers into molten lead presents several serious dangers.' --- Jearl Walker
What should -fdump-tree-...-details include? (was Re: Patch ping)
[ Moved from gcc-patches ] On Tuesday 10 January 2006 11:26, Zdenek Dvorak wrote: > > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00670.html > > > -- a patch to make dumps in several loop optimization passes > > > (ivopts, vectorizer, ...) easier to read, by having scev & data > > > dependence analysis dumps disabled by default > > > > Not completely OK. When I specify -details, I want every piece of > > information produced by the pass. > > It's fine with me if you want to add a specific -analysis switch that > > is orthogonal from -details. But with your patch, -details would not > > print everything in the scev and data dependence dumps. > > > > A simple tweak to this patch would give us both things. Make > > TDF_DETAILS include TDF_ANALYSIS in its bitmask. In fact, we could > > even have: > > > > #define TDF_DETAILS (1<<3) | TDF_ANALYSIS | TDF_STATS > > the point of this patch is that I want to be able to show everything > -details shows now, except for what -analysis does (because the dumps > covered by -analysis are almost never useful, except for the case there > is a bug in one of those analyses). I do not really care whether > -analysis dumps are shown by default, I just want to have a simple way > how to disable them while still preserving the other -details dumps. Is > that possible in the solution you propose? > Well, my intent with -details has always been to have the pass dump *everything* it knows how to dump. I never really wanted to filter it out in anyway. When you brought this up, I noticed that we never had TDF_STATS included in TDF_DETAILS (perhaps because very few passes use TDF_STATS), that's why I proposed adding it. You bring an interesting point, though. Should we allow each pass dictate the meaning of TDF_DETAILS? Or would it be better to have a universal meaning for it? My inclination is to have -details always show everything there is to show without any filtering. This gives us a universal switch to use when someone is not sure what information to dump. One can start with everything and then work down from there. If a pass wants to do something less than "dump everything", it should have other TDF_* flags. Thoughts?
Re: What should -fdump-tree-...-details include? (was Re: Patch ping)
Hello, > [ Moved from gcc-patches ] > > On Tuesday 10 January 2006 11:26, Zdenek Dvorak wrote: > > > > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00670.html > > > > -- a patch to make dumps in several loop optimization passes > > > > (ivopts, vectorizer, ...) easier to read, by having scev & data > > > > dependence analysis dumps disabled by default > > > > > > Not completely OK. When I specify -details, I want every piece of > > > information produced by the pass. > > > It's fine with me if you want to add a specific -analysis switch that > > > is orthogonal from -details. But with your patch, -details would not > > > print everything in the scev and data dependence dumps. > > > > > > A simple tweak to this patch would give us both things. Make > > > TDF_DETAILS include TDF_ANALYSIS in its bitmask. In fact, we could > > > even have: > > > > > > #define TDF_DETAILS (1<<3) | TDF_ANALYSIS | TDF_STATS > > > > the point of this patch is that I want to be able to show everything > > -details shows now, except for what -analysis does (because the dumps > > covered by -analysis are almost never useful, except for the case there > > is a bug in one of those analyses). I do not really care whether > > -analysis dumps are shown by default, I just want to have a simple way > > how to disable them while still preserving the other -details dumps. Is > > that possible in the solution you propose? > > > Well, my intent with -details has always been to have the pass dump > *everything* it knows how to dump. I never really wanted to filter it out > in anyway. When you brought this up, I noticed that we never had > TDF_STATS included in TDF_DETAILS (perhaps because very few passes use > TDF_STATS), that's why I proposed adding it. > > You bring an interesting point, though. Should we allow each pass dictate > the meaning of TDF_DETAILS? Or would it be better to have a universal > meaning for it? > > My inclination is to have -details always show everything there is to show > without any filtering. This gives us a universal switch to use when > someone is not sure what information to dump. One can start with > everything and then work down from there. If a pass wants to do something > less than "dump everything", it should have other TDF_* flags. my opinion is that with -details, the passes should dump as much as possible while being readable, as this is the default level at that (at least) I work when debugging. If someone wants to see everything, he can use -all, I do not see much reasons to have -details duplicate this behavior. Zdenek
Re: What should -fdump-tree-...-details include? (was Re: Patch ping)
Hello, > > > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00670.html > > > > -- a patch to make dumps in several loop optimization passes > > > > (ivopts, vectorizer, ...) easier to read, by having scev & data > > > > dependence analysis dumps disabled by default > > > > > > Not completely OK. When I specify -details, I want every piece of > > > information produced by the pass. > > > It's fine with me if you want to add a specific -analysis switch that > > > is orthogonal from -details. But with your patch, -details would not > > > print everything in the scev and data dependence dumps. > > > > > > A simple tweak to this patch would give us both things. Make > > > TDF_DETAILS include TDF_ANALYSIS in its bitmask. In fact, we could > > > even have: > > > > > > #define TDF_DETAILS (1<<3) | TDF_ANALYSIS | TDF_STATS > > > > the point of this patch is that I want to be able to show everything > > -details shows now, except for what -analysis does (because the dumps > > covered by -analysis are almost never useful, except for the case there > > is a bug in one of those analyses). I do not really care whether > > -analysis dumps are shown by default, I just want to have a simple way > > how to disable them while still preserving the other -details dumps. Is > > that possible in the solution you propose? > > > Well, my intent with -details has always been to have the pass dump > *everything* it knows how to dump. I never really wanted to filter it out > in anyway. When you brought this up, I noticed that we never had > TDF_STATS included in TDF_DETAILS (perhaps because very few passes use > TDF_STATS), that's why I proposed adding it. > > You bring an interesting point, though. Should we allow each pass dictate > the meaning of TDF_DETAILS? Or would it be better to have a universal > meaning for it? > > My inclination is to have -details always show everything there is to show > without any filtering. This gives us a universal switch to use when > someone is not sure what information to dump. One can start with > everything and then work down from there. If a pass wants to do something > less than "dump everything", it should have other TDF_* flags. > > Thoughts? another point to consider is that perhaps there might be some common way how to specify "detail level"; we already have -fsched-verbose=num and -ftree-vectorizer-verbose=num, perhaps we should avoid having a separate flag for each pass. Zdenek
powerpc-rtems fails to build on head
With code updated this morning, powerpc-rtems fails to build. I am using binutils 2.16.1 with just a couple of patches. Is this a gcc or binutils error? Is there a known fix? == /home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/xgcc -B/home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/ -nostdinc -B/home/joel/gcc-work/head/b-powerpc-rtems4.7/powerpc-rtems4.7/newlib/ -isystem /home/joel/gcc-work/head/b-powerpc-rtems4.7/powerpc-rtems4.7/newlib/targ-include -isystem /home/joel/gcc-work/head/gcc/newlib/libc/include -B/home/joel/gcc-head-test//powerpc-rtems4.7/bin/ -B/home/joel/gcc-head-test//powerpc-rtems4.7/lib/ -isystem /home/joel/gcc-head-test//powerpc-rtems4.7/include -isystem /home/joel/gcc-head-test//powerpc-rtems4.7/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -mrelocatable-lib -mno-eabi -mstrict-align -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -Dinhibit_libc -fPIC -msdata=none \ -c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFS_O \ -o crtbeginS.o /tmp/cc5gvpW0.s: Assembler messages: /tmp/cc5gvpW0.s:36: Error: Relocation cannot be done when using -mrelocatable == -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: powerpc-rtems fails to build on head
> "Joel Sherrill writes: Joel> With code updated this morning, powerpc-rtems fails to build. I am Joel> using binutils 2.16.1 with just a couple of patches. Joel> Is this a gcc or binutils error? Is there a known fix? This is not a known problem. There have been a lot of patches committed this morning. You need to be more specific about the instruction producing the assembler error and the latest updates that you have merged in your tree. David
Re: ggc 3.3.2 on aix 5.2 long long type?
The general problem is probably the same as PR 13358 (one that I've wished was fixed for a while, myself). Unfortunately there is no way as of now to disable this warning, short of disabling warnings entirely. -Jack On Tue, Jan 10, 2006 at 01:18:11PM -0800, sabreman (sent by Nabble.com) wrote: > > I getting the following warning with unsigned long long world_wide_name; > (scsi_buf.h). > > warning : integer constant is too large for "long" type. > > Is there a swich I need to add? > > I am just using: gcc -o test test.c > > Thanks! > -- > View this message in context: > http://www.nabble.com/ggc-3.3.2-on-aix-5.2-long-long-type--t890504.html#a2308440 > Sent from the gcc - Dev forum at Nabble.com. >
Re: powerpc-rtems fails to build on head
David Edelsohn wrote:
"Joel Sherrill writes:
Joel> With code updated this morning, powerpc-rtems fails to build. I am
Joel> using binutils 2.16.1 with just a couple of patches.
Joel> Is this a gcc or binutils error? Is there a known fix?
This is not a known problem. There have been a lot of patches
committed this morning. You need to be more specific about the
instruction producing the assembler error and the latest updates that you
have merged in your tree.
SVN revision 109589. I don't know precisely where before that it broke.
I built my native on 8 Jan. The other RTEMS crosses built on 9 Jan but
I missed that the PowerPC didn't installed -- I was so excited to see
that Ada built I missed it. :)
I have cut it down to this command:
/home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/xgcc \
-B/home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/ \
-mrelocatable-lib -c j3.c
and the attached source file. It appears to be this line in
__do_global_dtors_aux.
static func_ptr *p = __DTOR_LIST__ + 1;
What else can I do to help narrow it down?
--joel
typedef void (*func_ptr) (void);
static func_ptr __DTOR_LIST__[1]
__attribute__((section(".dtors"), aligned(sizeof(func_ptr
= { (func_ptr) (-1) };
#if 0
static const char __EH_FRAME_BEGIN__[]
__attribute__((section(".eh_frame"), aligned(4)))
= { };
extern void *__deregister_frame_info (const void *)
__attribute__ ((weak));
#endif
static void __attribute__((used))
__do_global_dtors_aux (void)
{
static func_ptr *p = __DTOR_LIST__ + 1;
#if 0
func_ptr f;
static _Bool completed;
if (__builtin_expect (completed, 0))
return;
while ((f = *p))
{
p++;
f ();
}
if (__deregister_frame_info)
__deregister_frame_info (__EH_FRAME_BEGIN__);
completed = 1;
#endif
}
Re: ggc 3.3.2 on aix 5.2 long long type?
By adding the 'ULL' prefix I was able to get rid of the warning. Thanks, Steve Heck -- View this message in context: http://www.nabble.com/ggc-3.3.2-on-aix-5.2-long-long-type--t890504.html#a2324330 Sent from the gcc - Dev forum at Nabble.com.
Mapping C code to generated asm code
Is there a way to get some type of debugging output that tells me what line of C code produced what lines of asm code? Thank you, Perry
Re: [M16C-ELF] : Problem with double and float data types.
> I have observed the following behavior while using "float" and > "double" data types for m16c target. Any computation involving a > "float" or a "double" data type does not work on the m16c hardware. > However, the correct values can be observed using GDB simulator. I figured out what the root cause of this is. The SHL.L opcode (32 bit shift) has a maximum shift count of 16: * If src is a register and you selected (.W) or (.L) for the size specifier (.size), the number of shifts is -16 to +16. Although you can set 0, no bits are shifted and no flags are changed. If you set a value less than -16 or greater than +16, the result of shift is indeterminate. Indeed, the chip masks the shift count by 0x1f (it's signed) so a shift by (say) 23 ends up shifting by 7 instead. Hmmm, that would imply a count range of -16..15, not -16..16. I'll have to experiment and find out for sure. The simulator doesn't mask the count. Do any other chips have a shift opcode which cannot shift by the max size of the operand? Does gcc know how to deal with this? Note: the m32c chips don't have this limitation. The m16c is a 16 bit chip.
bootstrap broken
Bootstrap now fails for me with:
/cvs/gcc-svn/trunk/gcc/df-core.c: In function ‘df_compact_blocks’:
/cvs/gcc-svn/trunk/gcc/df-core.c:795: error: invalid lvalue in assignment
/cvs/gcc-svn/trunk/gcc/df-core.c:803: error: invalid lvalue in assignment
/cvs/gcc-svn/trunk/gcc/df-core.c: In function ‘df_bb_replace’:
/cvs/gcc-svn/trunk/gcc/df-core.c:833: error: invalid lvalue in assignment
792 i = NUM_FIXED_BLOCKS;
793 FOR_EACH_BB (bb)
794 {
795 BASIC_BLOCK (i) = bb;
796 bb->index = i;
797 i++;
798 }
799
800 gcc_assert (i == n_basic_blocks);
801
802 for (; i < last_basic_block; i++)
803 BASIC_BLOCK (i) = NULL;
804 }
Kazu, it seems that your patch did not take into account the new file
df-core.c
2006-01-11 Kazu Hirata <[EMAIL PROTECTED]>
* basic-block.h (control_flow_graph): Change the type of
x_basic_block_info to VEC(basic_block,gc) *.
(BASIC_BLOCK_FOR_FUNCTION, BASIC_BLOCK): Adjust the uses of
basic_block_info.
(SET_BASIC_BLOCK): New.
Could you fix this, please?
Andreas
--
Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
pgpf6QpneRZDs.pgp
Description: PGP signature
Re: Mainline build failure
On Wednesday 11 January 2006 21:44, Steven Bosscher wrote:
> Hi,
>
> I can't build the trunk today:
>
> gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
> -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I.
> -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include
> -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber
> -I../libdecnumber../../trunk/gcc/df-problems.c -o df-problems.o
> ../../trunk/gcc/df-core.c: In function ‘df_compact_blocks’:
> ../../trunk/gcc/df-core.c:795: error: invalid lvalue in assignment
> ../../trunk/gcc/df-core.c:803: error: invalid lvalue in assignment
> ../../trunk/gcc/df-core.c: In function ‘df_bb_replace’:
> ../../trunk/gcc/df-core.c:833: error: invalid lvalue in assignment
> make[2]: *** [df-core.o] Error 1
> make[2]: *** Waiting for unfinished jobs
From df-core.c:
free (problem_temps);
i = NUM_FIXED_BLOCKS;
FOR_EACH_BB (bb)
{
BASIC_BLOCK (i) = bb;
bb->index = i;
i++;
}
gcc_assert (i == n_basic_blocks);
for (; i < last_basic_block; i++)
BASIC_BLOCK (i) = NULL;
Now look at cfg.c:compact_blocks... df-core.c should use that function
instead of duplicating it.
Gr.
Steven
Mainline build failure
Hi,
I can't build the trunk today:
gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I.
-I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include
-I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber
-I../libdecnumber../../trunk/gcc/df-problems.c -o df-problems.o
../../trunk/gcc/df-core.c: In function ‘df_compact_blocks’:
../../trunk/gcc/df-core.c:795: error: invalid lvalue in assignment
../../trunk/gcc/df-core.c:803: error: invalid lvalue in assignment
../../trunk/gcc/df-core.c: In function ‘df_bb_replace’:
../../trunk/gcc/df-core.c:833: error: invalid lvalue in assignment
make[2]: *** [df-core.o] Error 1
make[2]: *** Waiting for unfinished jobs
Path to problem:
../trunk/configure --enable-languages=c
--disable-{libmudflap,nls,libssp,checking} --disable-bootstrap
make -j 2 CFLAGS="-O0 -g"
My host compiler is "gcc (GCC) 4.0.2 20050901".
Gr.
Steven
Re: Mainline build failure
Steven Bosscher wrote:
Hi,
I can't build the trunk today:
gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I.
-I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include
-I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber
-I../libdecnumber../../trunk/gcc/df-problems.c -o df-problems.o
../../trunk/gcc/df-core.c: In function ‘df_compact_blocks’:
../../trunk/gcc/df-core.c:795: error: invalid lvalue in assignment
../../trunk/gcc/df-core.c:803: error: invalid lvalue in assignment
../../trunk/gcc/df-core.c: In function ‘df_bb_replace’:
../../trunk/gcc/df-core.c:833: error: invalid lvalue in assignment
make[2]: *** [df-core.o] Error 1
make[2]: *** Waiting for unfinished jobs
Path to problem:
../trunk/configure --enable-languages=c --disable-{libmudflap,nls,libssp,checking} --disable-bootstrap
make -j 2 CFLAGS="-O0 -g"
My host compiler is "gcc (GCC) 4.0.2 20050901".
Gr.
Steven
I posted the obvious patch to this a few hours ago, but because of the
problems with the mail, no one has seen it. I just talked to david
edelsohn and he just told me to check it in.
It will be committed in a minute.
Re: bootstrap broken
Hi Andreas, /cvs/gcc-svn/trunk/gcc/df-core.c: In function ‘df_compact_blocks’: /cvs/gcc-svn/trunk/gcc/df-core.c:795: error: invalid lvalue in assignment /cvs/gcc-svn/trunk/gcc/df-core.c:803: error: invalid lvalue in assignment /cvs/gcc-svn/trunk/gcc/df-core.c: In function ‘df_bb_replace’: /cvs/gcc-svn/trunk/gcc/df-core.c:833: error: invalid lvalue in assignment I just fixed these. Kazu Hirata
Re: Cross compiling libstc++-v3 fails
On Wed, Jan 11, 2006 at 12:10:32PM +0100, Leif Ekblad wrote: > In configure script, line 2580, there is a link test which checks if > an executable can be generated. The config.log file emits the > following errors: > > /usr/local/bin/rdos-ld: unrecognised emulation mode: -o > Supported emulations: elf_i386 > collect2: ld returned status 1 exit status. > > This error later in the configure scripts leads to an abort > with "Link tests are not allowed after GCC_NO_EXECUTABLES". > > To try to figure out this problem, I manully compiled the same > file with the same options using the same compiler (xgcc), and > it returns the same error. I then tried to use the cross-compiler > built using gcc-4.1-20051008, with which I can build other > executables, and it returns the same error. Only if I remove > the "-B/usr/src/toolchain/gcc-4.2-20060107/host-i686-pc-linux-gnu/gcc" > option, does it generate the executable without any errors. How > can this include give ld the wrong emulation mode? Apparently, > there is no "-o" in any file in the build-directory. Sounds like there's an error in your specs. Run gcc -v and see what it's invoking. -- Daniel Jacobowitz CodeSourcery
Re: Mainline build failure
Steven, actually the last piece of mail I sent you was a lie.
The bug I fixed is different.
The problem is that between the time that I check my code in an now,
someone changed the representation of BASIC_BLOCK.
lorien:~/gccDFTest/gcc(27) diff basic-block.h ../../gccBaseline/gcc
370c370
< varray_type x_basic_block_info;
---
> VEC(basic_block,gc) *x_basic_block_info;
402c402
< (VARRAY_BB (basic_block_info_for_function(FN), (N)))
---
> (VEC_index (basic_block, basic_block_info_for_function(FN), (N)))
414c414,415
< #define BASIC_BLOCK(N)(VARRAY_BB (basic_block_info, (N)))
---
> #define BASIC_BLOCK(N)(VEC_index (basic_block,
basic_block_info, (N)))
> #define SET_BASIC_BLOCK(N,BB) (VEC_replace (basic_block,
basic_block_info, (N), (BB)))
I will change my code and submit something when I get it thru stage 1 build.
kenny
Steven Bosscher wrote:
On Wednesday 11 January 2006 21:44, Steven Bosscher wrote:
Hi,
I can't build the trunk today:
gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I.
-I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include
-I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber
-I../libdecnumber../../trunk/gcc/df-problems.c -o df-problems.o
../../trunk/gcc/df-core.c: In function ‘df_compact_blocks’:
../../trunk/gcc/df-core.c:795: error: invalid lvalue in assignment
../../trunk/gcc/df-core.c:803: error: invalid lvalue in assignment
../../trunk/gcc/df-core.c: In function ‘df_bb_replace’:
../../trunk/gcc/df-core.c:833: error: invalid lvalue in assignment
make[2]: *** [df-core.o] Error 1
make[2]: *** Waiting for unfinished jobs
From df-core.c:
free (problem_temps);
i = NUM_FIXED_BLOCKS;
FOR_EACH_BB (bb)
{
BASIC_BLOCK (i) = bb;
bb->index = i;
i++;
}
gcc_assert (i == n_basic_blocks);
for (; i < last_basic_block; i++)
BASIC_BLOCK (i) = NULL;
Now look at cfg.c:compact_blocks... df-core.c should use that function
instead of duplicating it.
Gr.
Steven
Re: Mapping C code to generated asm code
On Wednesday 11 January 2006 13:03, Perry Smith wrote: > Is there a way to get some type of debugging output that tells me > what line of C code produced what lines of asm code? > $ gcc -Wa,-ahlsdn -gstabs
Re: Mapping C code to generated asm code
On Wed, Jan 11, 2006 at 12:03:42PM -0600, Perry Smith wrote: > Is there a way to get some type of debugging output that tells me > what line of C code produced what lines of asm code? How about $TARGET-objdump --disassemble --source? Ron
Re: merges
On Wed, 11 Jan 2006, Bernd Schmidt wrote: Giovanni Bajo wrote: Bernd Schmidt <[EMAIL PROTECTED]> wrote: Your merges are spamming the bugzilla database and anybody who is on the CC list of the affected bugs. both 20470 and 19199 got 1.2 Megabytes of ChangeLog. Argh. That's a side effect of the merge script I wasn't expecting. What do I need to do to fix this, and what exactly is causing it? You can avoid quoting ChangeLogs of patches your merge within your branches' ChangeLog. When working in development branches, usually ChangeLog files are not updated for merges, and commit entries are mostly like "merging from trunk up to revision ". In other words, don't use svnmerge's generated commit text file. Is it the commit message that's causing the problem, or the merged ChangeLog contents themselves? Commit messages. The merge script relies only on the svnmerge-integrated property, not on the commit messages? Right. It's just trying to generate a nice message for you, but in our world, the messages are so huge as to be useless. Bernd
Re: merges
On Wed, 11 Jan 2006, Bernd Schmidt wrote: Joern RENNECKE wrote: Your merges are spamming the bugzilla database and anybody who is on the CC list of the affected bugs. both 20470 and 19199 got 1.2 Megabytes of ChangeLog. Argh. That's a side effect of the merge script I wasn't expecting. What do I need to do to fix this, and what exactly is causing it? Don't use the silly huge changelog commit message it generates (IE the -F svnmerge-commit.txt part), just do an svn commit and write a log message of "merged from mainline". > Bernd
Re: Mapping C code to generated asm code
On 1/11/06, Perry Smith <[EMAIL PROTECTED]> wrote: > Is there a way to get some type of debugging output that tells me > what line of C code produced what lines of asm code? Do the .loc directives in the .s files produced by gcc -S work for you? The arguments to .loc are the file number, line number, and column number.
Re: merges
Daniel Berlin wrote: On Wed, 11 Jan 2006, Bernd Schmidt wrote: The merge script relies only on the svnmerge-integrated property, not on the commit messages? Right. It's just trying to generate a nice message for you, but in our world, the messages are so huge as to be useless. I've fixed the wiki page to mention that. Sorry about the mess. Bernd
Re: Mapping C code to generated asm code
Ron McCall <[EMAIL PROTECTED]> writes: > On Wed, Jan 11, 2006 at 12:03:42PM -0600, Perry Smith wrote: > > Is there a way to get some type of debugging output that tells me > > what line of C code produced what lines of asm code? > > How about $TARGET-objdump --disassemble --source? That's totally useless since -funit-at-a-time -Andi
conversion warnings in c++
So, for calls in c++ we're warning unconditionally on something like:
int bar (int a, int b);
int main (void)
{
float foo = 5.0;
float baz = 10.0;
bar (foo, baz);
return 0;
}
int bar (int a, int b)
{
return a + b;
}
whereas in C we're warning depending on Wtraditional or Wconversion.
As far as I can tell there's no required diagnostic for this in C++,
though I could have missed it.
So, either a) did I miss something? or b) any objections to
conditionalizing the warnings on Wconversion (or some method of
turning them off)?
-eric
Re: conversion warnings in c++
Eric Christopher <[EMAIL PROTECTED]> writes:
| So, for calls in c++ we're warning unconditionally on something like:
|
| int bar (int a, int b);
|
| int main (void)
| {
|float foo = 5.0;
|float baz = 10.0;
|
|bar (foo, baz);
|
|return 0;
| }
|
| int bar (int a, int b)
| {
|return a + b;
| }
|
| whereas in C we're warning depending on Wtraditional or Wconversion.
| As far as I can tell there's no required diagnostic for this in C++,
| though I could have missed it.
|
| So, either a) did I miss something? or b) any objections to
| conditionalizing the warnings on Wconversion (or some method of
| turning them off)?
-Wconversion is a good idea. I don't think -Wtraditional is relevant.
-- Gaby
Re: [M16C-ELF] : Problem with double and float data types.
DJ Delorie <[EMAIL PROTECTED]> writes: > > I have observed the following behavior while using "float" and > > "double" data types for m16c target. Any computation involving a > > "float" or a "double" data type does not work on the m16c hardware. > > However, the correct values can be observed using GDB simulator. > > I figured out what the root cause of this is. The SHL.L opcode (32 > bit shift) has a maximum shift count of 16: > > * If src is a register and you selected (.W) or (.L) for the size > specifier (.size), the number of shifts is -16 to +16. Although you > can set 0, no bits are shifted and no flags are changed. If you set > a value less than -16 or greater than +16, the result of shift > is indeterminate. > > Indeed, the chip masks the shift count by 0x1f (it's signed) so a > shift by (say) 23 ends up shifting by 7 instead. Hmmm, that would > imply a count range of -16..15, not -16..16. I'll have to experiment > and find out for sure. The simulator doesn't mask the count. > > Do any other chips have a shift opcode which cannot shift by the max > size of the operand? Does gcc know how to deal with this? > > Note: the m32c chips don't have this limitation. The m16c is a 16 bit > chip. I don't know whether any other chip has this particular limitation, but it's not hard to handle. ashlsi3 and friends should be a define_expand which turn an overly large CONST_INT into two shifts, load the shift count into a register, whichever is likely to be better. The MIPS16 does this, for example (search for any_shift:GPR in mips.md). Then the real insn should use an operand predicate which only accepts CONST_INTs which are in range. Ian
Re: [M16C-ELF] : Problem with double and float data types.
> I don't know whether any other chip has this particular limitation, > but it's not hard to handle. ashlsi3 and friends should be a > define_expand which turn an overly large CONST_INT into two shifts, > load the shift count into a register, whichever is likely to be > better. The MIPS16 does this, for example (search for any_shift:GPR > in mips.md). Then the real insn should use an operand predicate which > only accepts CONST_INTs which are in range. I can handle the large constant shifts with multiple shift opcodes. The problem is, it can't handle large shifts counts in registers either. A 32 bit value can be shifted at most 16 bits in a single opcode, period. At the moment, the only solution I can see is to code constant shifts with multiple opcodes, and whenever I need a variable shift code a subroutine call instead which checks for out of range shifts. I was hoping there was an alternative, but I haven't seen anything that makes me think gcc will react nicely to failed shift expanders.
libgcc2.c help needed
I'm not sure how to present all this so bear with me: The problem: In the particular build I am trying to do, when libgcc2.c is compled with -DL_floatdidf, instead of defining a routine called _floatdidf or __floatdidf, it creates a routine called __floattidf which references __floatdidf. The call to compile as generated by configure is: ./xgcc -B./ -B/usr/local/powerpc-ibm-aix5.3.0.0/bin/ \ -isystem /usr/local/powerpc-ibm-aix5.3.0.0/include \ -isystem /usr/local/powerpc-ibm-aix5.3.0.0/sys-include \ -L/usr/local/src/build-gcc-4.0.2/gcc/../ld -O2 -DIN_GCC \ -W -Wall -Wwrite-strings -Wstrict-prototypes \ -Wmissing-prototypes -Wold-style-definition -isystem \ ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 \ -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-4.0.2/gcc \ -I../../gcc-4.0.2/gcc/. \ -I../../gcc-4.0.2/gcc/../include \ -I../../gcc-4.0.2/gcc/../libcpp/include -DSHARED \ -maix64 -msoft-float -DL_floatdidf -c \ ../../gcc-4.0.2/gcc/libgcc2.c \ -o libgcc/ppc64/soft-float/_floatdidf_s.o (It compiles fine.) This is on an RS/6000 AIX 5.3. I'm trying to compile gcc 4.0.2. I have mucked with t-aix52 to produce not only pthread and ppc64 but also libraries for soft-float. This particular compile is when it is trying to produce the ppc64/soft-float shared (libgcc_s.a) library. Of the eight different versions of libgcc_s.a, all of them link fine except for ppc64/soft-float and pthead/ppc64/soft-float. The link fails with __floatdidf, __fixdfdi, and __fixsfdi as undefined. I have not dug into the details of the other two but I assume they are all the same root cause. I've noticed in libgcc2.h, a macro is created called __NDW that appears may be doing this substitution. I'm currently looking into that part of the code but was hoping someone could help me out a bit. BTW, when the link for libgcc_s.a fails, the make does not stop. I just keeps going. I did not notice this until install time when the libraries did not exist. Thank you very much, Perry Smith
Re: merges
On Thu, 2006-01-12 at 00:55 +0100, Bernd Schmidt wrote: > Daniel Berlin wrote: > > On Wed, 11 Jan 2006, Bernd Schmidt wrote: > >> The merge script relies only on the svnmerge-integrated property, not > >> on the commit messages? > > > > > > Right. > > > > It's just trying to generate a nice message for you, but in our world, > > the messages are so huge as to be useless. > > I've fixed the wiki page to mention that. Sorry about the mess. > mysql> delete from longdescs where length(thetext) > 100; Query OK, 251 rows affected (2 min 12.11 sec) hehe You had added 250 meg in comments. I may just set up a pre-commit hook to check the log message length and hav eit not let you commit if it's ridiculously large. (These things happen, i really don't blame you :P)
Re: [M16C-ELF] : Problem with double and float data types.
DJ Delorie <[EMAIL PROTECTED]> writes: > > I don't know whether any other chip has this particular limitation, > > but it's not hard to handle. ashlsi3 and friends should be a > > define_expand which turn an overly large CONST_INT into two shifts, > > load the shift count into a register, whichever is likely to be > > better. The MIPS16 does this, for example (search for any_shift:GPR > > in mips.md). Then the real insn should use an operand predicate which > > only accepts CONST_INTs which are in range. > > I can handle the large constant shifts with multiple shift opcodes. > The problem is, it can't handle large shifts counts in registers > either. A 32 bit value can be shifted at most 16 bits in a single > opcode, period. Oh, I see. Bummer. > At the moment, the only solution I can see is to code constant shifts > with multiple opcodes, and whenever I need a variable shift code a > subroutine call instead which checks for out of range shifts. I was > hoping there was an alternative, but I haven't seen anything that > makes me think gcc will react nicely to failed shift expanders. Or, you could presumably code it inline if you wanted to, using a conditional branch. I don't know whether that would be any better. Or maybe in some cases you could do shift r1,r2 lshiftrt r2,4 shirt r1,r2 Ian
Re: libgcc2.c help needed
Perry Smith <[EMAIL PROTECTED]> writes: > The problem: In the particular build I am trying to do, when > libgcc2.c is compled with -DL_floatdidf, instead of defining a > routine called _floatdidf or __floatdidf, it creates a routine called > __floattidf which references __floatdidf. ... > This is on an RS/6000 AIX 5.3. I'm trying to compile gcc 4.0.2. I > have mucked with t-aix52 to produce not only pthread and ppc64 but > also libraries for soft-float. This particular compile is when it is > trying to produce the ppc64/soft-float shared (libgcc_s.a) library. The function is defined in config/rs6000/ppc64-fp.c. See, e.g., config/rs6000/t-linux64, which puts that file in LIB2FUNCS_EXTRA. Ian
Re: libgcc.a, et. al.
On Jan 10, 2006, at 9:46 PM, David Edelsohn wrote: Perry Smith writes: Perry> The call to _restf14 is not explicit so I assume the compiler is Perry> generating it for some reason. Yes, because one of the exception handling support functions can clobber all registers, but also can return upon error, so all registers need to be restored -- including FP registers. Perry> I believe the soft-float is the route I want to go. Right now, I Perry> took the t-aix52 file and changed it to have: Perry> MULTILIB_OPTIONS = pthread maix64 msoft-float Perry> MULTILIB_DIRNAMES = pthread ppc64 soft-float Perry> I could not find a way to do this via configure options. I'm Perry> rebuilding the whole compiler at this point. I didn't know any other Perry> way to get the new versions of the libraries to be created. Most users do not want or need that configuration because all AIX systems have floating point hardware support. Well, except any kernel extension like a device driver, virtual file system, etc, can not use the FP registers. So any use trying to write a device drive wants and needs a soft-float library. The kmstsave (the kernel mst save structure) does not save the fp registers like the mstsave (the per process mst save structure) does. This is to save time in system calls. So, my thought is that if it was provided and maybe some documentation as to why it is provided, then gcc could and would start to be used for AIX kernel extensions.
Re: [M16C-ELF] : Problem with double and float data types.
On Jan 11, 2006, at 10:11 PM, Ian Lance Taylor wrote: DJ Delorie <[EMAIL PROTECTED]> writes: I don't know whether any other chip has this particular limitation, but it's not hard to handle. ashlsi3 and friends should be a define_expand which turn an overly large CONST_INT into two shifts, load the shift count into a register, whichever is likely to be better. The MIPS16 does this, for example (search for any_shift:GPR in mips.md). Then the real insn should use an operand predicate which only accepts CONST_INTs which are in range. I can handle the large constant shifts with multiple shift opcodes. The problem is, it can't handle large shifts counts in registers either. A 32 bit value can be shifted at most 16 bits in a single opcode, period. Oh, I see. Bummer. At the moment, the only solution I can see is to code constant shifts with multiple opcodes, and whenever I need a variable shift code a subroutine call instead which checks for out of range shifts. I was hoping there was an alternative, but I haven't seen anything that makes me think gcc will react nicely to failed shift expanders. Or, you could presumably code it inline if you wanted to, using a conditional branch. I don't know whether that would be any better. Or maybe in some cases you could do shift r1,r2 lshiftrt r2,4 shirt r1,r2 Ian Sounds like the first shift "is undefined". So it would have to move r2 to r3 and mask it with 0xf -- actually that would not even work since it might be negative. I would be interested in looking at the data sheet for this chip. I didn't see which chip it was. The thing that has me curious is the negative shift counts. Can a right shift of a negative count (of some type (rotate?)) substitute for a left shift when the shift is greater than 16?
Re: [M16C-ELF] : Problem with double and float data types.
> I would be interested in looking at the data sheet for this chip. I > didn't see which chip it was. The thing that has me curious is the > negative shift counts. Can a right shift of a negative count (of > some type (rotate?)) substitute for a left shift when the shift is > greater than 16? This chip (m16c/m32c) does not have separate left/right shift opcodes. All shifts take signed counts; positive shifts one way, negative shifts the other way. Shifts are defined for counts in the range -16..16. Outside that range, they're undefined. Experimentation has shown that above that, counts wrap (i.e. counts are 0, 1, ..., 15, 16, 1, 2, ...).
