Bootstrap failure on ppc64
Hello, The following error is received on ppc64. Thanks, Revital symtab.o -MT symtab.o -MMD -MP -MF .deps/symtab.Po ../../gcc/libcpp/symtab.c /home/eres/mainline_lim/build/./prev-gcc/xgcc -B/home/eres/mainline_lim/build/./prev-gcc/ -B/home/eres/mainline_lim/build/powerpc64-unknown-linux-gnu/bin/ -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -O3 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -c -o traditional.o -MT traditional.o -MMD -MP -MF .deps/traditional.Po ../../gcc/libcpp/traditional.c cc1: warnings being treated as errors ../../gcc/libcpp/traditional.c: In function ג_cpp_scan_out_logical_lineג: ../../gcc/libcpp/traditional.c:349: error: גfmacro.argsג may be used uninitialized in this function ../../gcc/libcpp/traditional.c:349: error: גfmacro.nodeג may be used uninitialized in this function ../../gcc/libcpp/traditional.c:349: error: גfmacro.offsetג may be used uninitialized in this function ../../gcc/libcpp/traditional.c:349: error: גfmacro.argcג may be used uninitialized in this function ../../gcc/libcpp/traditional.c:349: error: גfmacro.lineג may be used uninitialized in this function make[3]: *** [traditional.o] Error 1 make[3]: Leaving directory `/home/eres/mainline_lim/build/libcpp' make[2]: *** [all-stage2-libcpp] Error 2 make[2]: Leaving directory `/home/eres/mainline_lim/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/eres/mainline_lim/build' make: *** [bootstrap] Error 2
Re: A reload inheritance bug
Mark Shinwell wrote:
> As you say, one unusual thing about this situation must be the fact
> that the reload register is getting chosen by the code in
> push_reload heralded by "If this is an input reload and the operand
> contains a register that dies in this insn and is used nowhere else,
> see if it is the right class to be used for this reload. Use it if so."
Not that unusual - this happens all the time.
> etc. I suspect it is the conjunction of this code and the behaviour of
> reload in choosing r9 for pseudo 4082 in insn 5314 above that causes the
> problem.
>
> I don't entirely follow your example below...
>
>> Still, assume a similar sequence
>>
>> insn 5301: (set (reg/f:SI 4082) (reg/f:SI 3275))
>>
>> insn 5291 (set (reg:DF 4078])
>>(unspec:DF (mem/s:DF (plus:SI (reg/f:SI 3275)
>> (reg:SI 3812)))
>> (reg:SI 3275)))
>> REG_DEAD 3275
>>
>>
>>
>> insn 5314 (set (reg:DF 4096)
>> (mem/s:DF (plus:SI (reg/f:SI 4082) (reg:SI 4084
>>
>> Here, we wouldn't use R9 as reload register in 5291
>
> ...since here, as far as I understand it, the clause mentioned above
> in push_reload wouldn't select r9 to use as a reload register for
> 5291.
That, and the subsequent code won't use a reg that's also used in the
insn. However, ...
> My gut feeling is that this example will work as a consequence.
... note that I inserted which could conceivably use
R9 as an input reload, as the hard reg is dead. Where would we
invalidate previous information about R9? I assume it would be the loop
at the end of emit_reload_insns, specifically
/* First, clear out memory of what used to be in this
spill reg.
If consecutive registers are used, clear them all. */
for (k = 0; k < nr; k++)
{
CLEAR_HARD_REG_BIT (reg_reloaded_valid, i + k);
CLEAR_HARD_REG_BIT (reg_reloaded_call_part_clobbered,
i + k);
Why isn't this triggering?
> (Perhaps you're getting at the fact that the decision procedure leading
> us to choose r9 for pseudo 4082 in insn 5314 might be at fault instead?
No, that seems fine.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: A reload inheritance bug
Bernd Schmidt wrote:
My gut feeling is that this example will work as a consequence.
... note that I inserted which could conceivably use
R9 as an input reload, as the hard reg is dead. Where would we
invalidate previous information about R9? I assume it would be the loop
at the end of emit_reload_insns, specifically
/* First, clear out memory of what used to be in this
spill reg.
If consecutive registers are used, clear them all. */
for (k = 0; k < nr; k++)
{
CLEAR_HARD_REG_BIT (reg_reloaded_valid, i + k);
CLEAR_HARD_REG_BIT (reg_reloaded_call_part_clobbered,
i + k);
Why isn't this triggering?
This code is guarded by
/* I is nonneg if this reload used a register.
If rld[r].reg_rtx is 0, this is an optional reload
that we opted to ignore. */
if (i >= 0 && rld[r].reg_rtx != 0)
and in this [my original] case, i is negative (see my original patch).
I don't understand the "I is nonneg ..." comment above: the surrounding
code seems to say that i is actually non-negative if the reload used a
_spill_ register (rather than just any register). Bernd, could you
clarify the precise meaning of "spill register" in this context? I've
not yet managed to completely pin this down.
Mark
Re: Help in understanding ccp propagator
> I can modify it to catch it pretty easily, just walk back a few vuses > if the current set of vuses is defined by something that does not > actually touch our offset. This sounds like what I am trying to do in ccp... > > > > I am not sure I understand. The new patch uses the infrastructure of > > the propagator and I do not see an indication in the dumps for vdefs > > update after the lattice value is changed: > > > > 19930 > > 19931 Visiting statement: > > 19932 D.61410.first = i0_62; > > 19933 > > 19934 Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. > > 19935 > > > > Thanks again fo your help, > > Revital > > So uh, how do you expect the propagator to notice when the used > variables have changed if the things the vdefs produced by > D.61410.first are not marked as change (so that the immediate uses of > it get processed). > > You will need to add this if it is not there already. > > > Normally, the propagator says "oh, the lattice value of D_64 changed, > let me mark all it's immediate uses for reprocessing". The only thing > that links memory defs to memory uses is the vdef/vuses, so you will > have to be able to process and mark those I thought the engine suppose to take care of that. I do not understand why this case is different from other cases where we propagate for vdefs... Thanks again, Revital
Re: A reload inheritance bug
Mark Shinwell wrote: > This code is guarded by > > /* I is nonneg if this reload used a register. > If rld[r].reg_rtx is 0, this is an optional reload > that we opted to ignore. */ > > if (i >= 0 && rld[r].reg_rtx != 0) > > and in this [my original] case, i is negative (see my original patch). > > I don't understand the "I is nonneg ..." comment above: the surrounding > code seems to say that i is actually non-negative if the reload used a > _spill_ register (rather than just any register). Bernd, could you > clarify the precise meaning of "spill register" in this context? I've > not yet managed to completely pin this down. The term "spill register" is a bit of a historical artifact, and I think we may be getting close to the root cause here (and it seems to be my fault.) In the early days of gcc, when a register was spilled, it was spilled for the whole function and became a spill register that reload could use freely. That means that none of these spill registers would be selected during find_reloads, as they don't appear in the insn anymore. These days, we are more selective and don't spill hard regs for the entire function. It appears that spill_reg_index is only set up for registers that go through the choose_reload_regs process, not for the ones selected during find_reloads. That's probably a bad thing, as a reg_rtx chosen in find_reloads could be used as a spill reg in a previous insn (as in your example). Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: A reload inheritance bug
Bernd Schmidt wrote: It appears that spill_reg_index is only set up for registers that go through the choose_reload_regs process, not for the ones selected during find_reloads. That's probably a bad thing, as a reg_rtx chosen in find_reloads could be used as a spill reg in a previous insn (as in your example). Yes, I think that is indeed what's going on. I wonder if this issue of spill_reg_index is also manifesting itself in: /* The following if-statement was #if 0'd in 1.34 (or before...). It's reenabled in 1.35 because supposedly nothing else deals with this problem. */ /* If a register gets output-reloaded from a non-spill register, that invalidates any previous reloaded copy of it. But forget_old_reloads_1 won't get to see it, because it thinks only about the original insn. So invalidate it here. Also do the same thing for RELOAD_OTHER constraints where the output is discarded. */ if (i < 0 ... and the code following in emit_reload_insns? Perhaps if spill_reg_index took account of registers selected during find_reloads then this could be simplified too. So what do you think is the best approach to fix all of this? :-) Mark
vector compare
Hi gcc group, I added vector compare and mov insns in gcc for our architecture (cross_gcc), but when I use these insns in c, I have to use builtin functions instead of generic vector compare. for example: typedef short int v2hi __attribute__ ((vector_size (4))); // vector of two short v2hi pix_x, pix_y, xy_max; xy_max = (pix_x > pix_y) ? pix_x : pix_y; cross_gcc give the following error: invalid operands to binary > I have to use builtin compare_mov instruction. Could someone tell me how to do vector compare in generic way? Look forward to hearing from you Maggie
Re: vector compare
> Could someone tell me how to do vector compare in generic way? AFAICT every target which supports vector operations has it's own list of built-in function for vector comparison. For example, Altivec has vec_cmpgt and other built-ins for vector compare instructions. (see altivec.h file for the list of built-ins) Revital > > > Look forward to hearing from you > > > Maggie > >
Re: A reload inheritance bug
Mark Shinwell wrote: > and the code following in emit_reload_insns? Perhaps if spill_reg_index > took account of registers selected during find_reloads then this could > be simplified too. > > So what do you think is the best approach to fix all of this? :-) Sounds like you gave the answer yourself in the first paragraph. At least that's what I'd try. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: Bootstrap failure on ppc64
[EMAIL PROTECTED] wrote: Hello, The following error is received on ppc64. Thanks, Revital symtab.o -MT symtab.o -MMD -MP -MF .deps/symtab.Po ../../gcc/libcpp/symtab.c /home/eres/mainline_lim/build/./prev-gcc/xgcc -B/home/eres/mainline_lim/build/./prev-gcc/ -B/home/eres/mainline_lim/build/powerpc64-unknown-linux-gnu/bin/ -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -O3 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -c -o traditional.o -MT traditional.o -MMD -MP -MF .deps/traditional.Po ../../gcc/libcpp/traditional.c cc1: warnings being treated as errors ../../gcc/libcpp/traditional.c: In function ג_cpp_scan_out_logical_lineג: ../../gcc/libcpp/traditional.c:349: error: גfmacro.argsג may be used uninitialized in this function ../../gcc/libcpp/traditional.c:349: error: גfmacro.nodeג may be used uninitialized in this function ../../gcc/libcpp/traditional.c:349: error: גfmacro.offsetג may be used uninitialized in this function ../../gcc/libcpp/traditional.c:349: error: גfmacro.argcג may be used uninitialized in this function ../../gcc/libcpp/traditional.c:349: error: גfmacro.lineג may be used uninitialized in this function make[3]: *** [traditional.o] Error 1 make[3]: Leaving directory `/home/eres/mainline_lim/build/libcpp' make[2]: *** [all-stage2-libcpp] Error 2 make[2]: Leaving directory `/home/eres/mainline_lim/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/eres/mainline_lim/build' make: *** [bootstrap] Error 2 So it looks like you must remove the -Werror option. Several of the Makefile.in files have WERROR macros which can be nulled out to avoid setting -Werror.
Re: A reload inheritance bug
Bernd Schmidt wrote: Mark Shinwell wrote: and the code following in emit_reload_insns? Perhaps if spill_reg_index took account of registers selected during find_reloads then this could be simplified too. So what do you think is the best approach to fix all of this? :-) Sounds like you gave the answer yourself in the first paragraph. At least that's what I'd try. OK, I'll have a go -- it seems like a good thing to clean up anyway, even modulo fixing this bug. Mark
Re: Bootstrap failure on ppc64
Tim Prince <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > ../../gcc/libcpp/traditional.c: In function â_cpp_scan_out_logical_lineâ: > > ../../gcc/libcpp/traditional.c:349: error: âfmacro.argsâ may be used > > uninitialized in this function > > ../../gcc/libcpp/traditional.c:349: error: âfmacro.nodeâ may be used > > uninitialized in this function > > ../../gcc/libcpp/traditional.c:349: error: âfmacro.offsetâ may be used > > uninitialized in this function > > ../../gcc/libcpp/traditional.c:349: error: âfmacro.argcâ may be used > > uninitialized in this function > > ../../gcc/libcpp/traditional.c:349: error: âfmacro.lineâ may be used > > uninitialized in this function > > make[3]: *** [traditional.o] Error 1 > > make[3]: Leaving directory `/home/eres/mainline_lim/build/libcpp' > > make[2]: *** [all-stage2-libcpp] Error 2 > > make[2]: Leaving directory `/home/eres/mainline_lim/build' > > make[1]: *** [stage2-bubble] Error 2 > > make[1]: Leaving directory `/home/eres/mainline_lim/build' > > make: *** [bootstrap] Error 2 > So it looks like you must remove the -Werror option. Several of the > Makefile.in files have WERROR macros which can be nulled out to avoid > setting -Werror. No, please initialize the fields in fmacro instead. The warning is probably wrong but the cost of adding an explicit initialization is low. Ian
Something weird with cp/decl.c switch statement
There is something weird with the switch statement in cp/decl.c:7105. GITWeb :- http://git.infradead.org/?p=gcc.git;a=blob;f=gcc/cp/decl.c;h=407e5db8d650f1d19c618c7b67566407c2d35fce;hb=master#l7105 Can someone verify this. Take a close look in a text editor at the bracketting and indentation. I dont think it will effect the decl.c's logic, but what does it say about the GCC's C parser, is this legal C ? Aaron
Re: Something weird with cp/decl.c switch statement
Aaron Gray writes: > There is something weird with the switch statement in cp/decl.c:7105. > > GITWeb :- > > http://git.infradead.org/?p=gcc.git;a=blob;f=gcc/cp/decl.c;h=407e5db8d650f1d19c618c7b67566407c2d35fce;hb=master#l7105 > > Can someone verify this. > > Take a close look in a text editor at the bracketting and indentation. Please be specific. I don't think we have time for guessing games. :-) Andrew.
Re: Something weird with cp/decl.c switch statement
On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:
There is something weird with the switch statement in cp/decl.c:7105.
I dont think it will effect the decl.c's logic, but what does it say about
the GCC's C parser, is this legal C ?
Yes this is legal C :).
Just for everyone else the code looks like:
switch( a)
{
case b:
{
...
break
case c:
.
}
}
case are just special kind of labels.
-- Pinski
Re: Something weird with cp/decl.c switch statement
Andrew Pinski writes:
> On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:
> > There is something weird with the switch statement in cp/decl.c:7105.
> > I dont think it will effect the decl.c's logic, but what does it say about
> > the GCC's C parser, is this legal C ?
>
> Yes this is legal C :).
> Just for everyone else the code looks like:
> switch( a)
> {
> case b:
> {
> ...
> break
> case c:
> .
> }
> }
>
> case are just special kind of labels.
Well done. You have more patience than me, clearly. :-)
Perhaps we should change this...
Andrew.
RE: How to enable Mudflap in gcc 4.x?
On 4th June 2007 at 07:24:37 Frank Eigler wrote: >First thing is to get past that autoconf error. Check your linker >script for the default entry point symbol's name, and give it to >libmudflap/configure.ac (then regenerate configure). >Next, overcome build problems (if any) to the extent that a >libmudflap.a gets compiled. I was successful in generating libmudflap.a for sh-elf target by adding "_start" as entry point symbol's name in configure.ac. >Then, start running the test suite. Running "make check" in /gcc/sh-elf/libmudflap/ directory present in the build folder results in: / . . /home/naveenh/build/gcc/sh-elf/./libmudflap/.libs/libmudflap.a(mf-heuris tics.o): In function `__mf_heuristic_check':^M /home/naveenh/src/gcc-4.3-20070302/libmudflap/mf-heuristics.c:161: Undefined reference to `__start'^M /home/naveenh/src/gcc-4.3-20070302/libmudflap/mf-heuristics.c:161: Undefined reference to `__end'^M collect2: ld returned 1 exit status^M compiler exited with status 1 output is: /home/naveenh/build/gcc/sh-elf/./libmudflap/.libs/libmudflap.a(mf-heuris tics.o): In function `__mf_heuristic_check':^M /home/naveenh/src/gcc-4.3-20070302/libmudflap/mf-heuristics.c:161: Undefined reference to `__start'^M /home/naveenh/src/gcc-4.3-20070302/libmudflap/mf-heuristics.c:161: Undefined reference to `__end'^M collect2: ld returned 1 exit status^M Executing on host: /home/naveenh/build/gcc/gcc/xgcc -B/home/naveenh/build/gcc/gcc/ -ggdb3 -DDEBUG_ASSERT -I/home/naveenh/src/gcc-4.3-20070302/libmudflap/testsuite -I/home/naveenh/src/gcc-4.3-20070302/libmudflap/testsuite/.. -I.. -L/home/naveenh/build/gcc/sh-elf/./libmudflap/.libs /home/naveenh/src/gcc-4.3-20070302/libmudflap/testsuite/libmudflap.c/ fail1-frag.c -fmudflap -lmudflap -L/home/naveenh/build/gcc/sh-elf/./libmudflap/testsuite -lm -m1 -o ./fail1-frag.exe(timeout = 300) /home/naveenh/src/gcc-4.3-20070302/libmudflap/testsuite/libmudflap.c/ fail1-frag.c:1:19: error: stdio.h: No such file or directory^M /home/naveenh/src/gcc-4.3-20070302/libmudflap/testsuite/libmudflap.c/ fail1-frag.c:2:20: error: stdlib.h: No such file or directory^M /home/naveenh/src/gcc-4.3-20070302/libmudflap/testsuite/libmudflap.c/ fail1-frag.c:3:20: error: string.h: No such file or directory^M compiler exited with status 1 output is: /home/naveenh/src/gcc-4.3-20070302/libmudflap/testsuite/libmudflap.c/ fail1-frag.c:1:19: error: stdio.h: No such file or directory^M /home/naveenh/src/gcc-4.3-20070302/libmudflap/testsuite/libmudflap.c/ fail1-frag.c:2:20: error: stdlib.h: No such file or directory^M /home/naveenh/src/gcc-4.3-20070302/libmudflap/testsuite/libmudflap.c/ fail1-frag.c:3:20: error: string.h: No such file or directory^M . . . // >[..]so at this point you might as well start compiling >your own smaller code with -fmudflap and see what happens. Compiling a simple C code with -fmudflap and -lmudflap options gives following errors: /// /home/naveenh/prefix/lib/gcc/sh-elf/4.3.0/../../../../sh-elf/lib/libc.a( lib_a-syscalls.o): In function `__setup_argv_for_main': /home/naveenh/src/newlib-1.15.0/newlib/libc/sys/sh/syscalls.c:210: undefined reference to `___wrap_main' /home/naveenh/prefix/lib/gcc/sh-elf/4.3.0/../../../../sh-elf/lib/libc.a( lib_a-syscalls.o): In function `__setup_argv_and_call_main': /home/naveenh/src/newlib-1.15.0/newlib/libc/sys/sh/syscalls.c:218: undefined reference to `___wrap_main' collect2: ld returned 1 exit status How to remove these errors? Regards, Deepen Mantri KPIT Cummins InfoSystems Ltd. Pune, India ~ Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C and M32C Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on February 6, 07 ~~
segmentation fault
With apologies for being new: In porting a hardware configuration from gcc-3.4.1 to gcc-4.2.0, I'm getting the following error message: In file included from /cygdrive/c/gcc-4.2.0/gcc/crtstuff.c:68: /cygdrive/c/gcc-4.2.0/gcc/tsystem.h:53: internal compiler error: Segmentation fault. Lines 52-54 of tsystem.h are: #ifndef malloc extern void *malloc (size_t); #endif If I remove these lines, all the other extern statements fail also. What precisely does Segmentation fault mean in this context? Is it referring to the underlying Windows XP? What sort of compiler, configuration or operating system parameters could be the cause? Where should I be looking? Thanks, Fred Cotton
Re: libjava is a train wreck.
Steve Kargl wrote: Can someone explain why libjava *must* commit binary files to the repository? It is due to a couple of factors: We are now using an java -> class compiler (ecj) that is written in java. The creates a bootstrap problem in that java files cannot be compiled until the compiler is built. Having the class files pre-built allows us to build gcj/libgcj without relying on an external java runtime. Another factor IIRC, is a decision of a non-technical nature made by RMS and the Steering Committee that the ecj source could not be incorporated into GCCs sources. David Daney
Re: Something weird with cp/decl.c switch statement
On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:
There is something weird with the switch statement in cp/decl.c:7105.
I dont think it will effect the decl.c's logic, but what does it say
about
the GCC's C parser, is this legal C ?
Yes this is legal C :).
Just for everyone else the code looks like:
switch( a)
{
case b:
{
...
break
case c:
.
}
}
case are just special kind of labels.
MS Visual Studio does not parse it. Are you sure its legal C ?
Aaron
Re: libjava is a train wreck.
Steve Kargl writes: > Can someone explain why libjava *must* commit binary files to the > repository? A merge of trunk to the fortran-experiments branch > generated 70 conflicts that I need to resolve. This is a complete > waste of time that would have been spent towards cutting a diff > of the branch against trunk for patch submission! In addition to David Daney's comments, I don't really understand why you've got conflicts on your branch. You won't have changed anything in libjava/ there, so the problem shouldn't arise. Andrew.
Re: Something weird with cp/decl.c switch statement
On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:
MS Visual Studio does not parse it. Are you sure its legal C ?
Yes I am. Try this:
int f(int a)
{
switch (a)
{
case 1:
{
int b = 2;
break;
case 2:
break;
}
}
}
This is valid C90 and C99, though invalid C++98.
If you are using visual studio, make sure it is being compiled as C
and not C++. C++ is not a true superset of C; anyone who thinks needs
to tell their CS teacher (or book author) that they are wrong and they
should relearn about the two languages.
Thanks,
Andrew Pinski
Re: Something weird with cp/decl.c switch statement
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
> On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:
> > There is something weird with the switch statement in cp/decl.c:7105.
> > I dont think it will effect the decl.c's logic, but what does it say about
> > the GCC's C parser, is this legal C ?
>
> Yes this is legal C :).
> Just for everyone else the code looks like:
> switch( a)
> {
> case b:
> {
> ...
> break
> case c:
> .
> }
> }
>
> case are just special kind of labels.
And Simon already sent in a tested patch for a couple of days ago:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00199.html
Ian
Re: Something weird with cp/decl.c switch statement
Ian Lance Taylor wrote: > And Simon already sent in a tested patch for a couple of days ago: > > http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00199.html This patch is OK, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: vector compare
On Tuesday 05 June 2007, Ying Yi wrote: > Hi gcc group, > > I added vector compare and mov insns in gcc for our architecture > (cross_gcc), but when I > use these insns in c, I have to use builtin functions instead of > generic vector compare. >... > Could someone tell me how to do vector compare in generic way? You can't. GCC does not support this. Vector comparisons don't easily/usefully map onto standard C operators. Adding them would probably want to be part of a larger extension for generic vector operations (element access, reduction operations, etc). Paul
Re: Fixed-point branch?
Fu, Chao-Ying wrote: >> 2. Joseph, at that point, would you please invest a a little >> bit of time >> (a couple of hours) to look at the branch, and provide some feedback? >> Please provide comments to Chao-Ying, and also please let me know >> whether you think the work is nearly ready for inclusion? > > Maybe you could first check if new machine modes, new TREE structures > (a saturating bit, fixed-point type, fixed-point constant), > new RTL structures (fixed-point constant and operators) are ok. I had not realized that there were so many changes outside of the C front end. I think that it does indeed make sense to have someone look at some of that stuff. I will be happy to take a look. Will you please send me a patch (and CC the list) for the middle-end changes? It doesn't have to apply to mainline cleanly, but that will give me -- and people who know better than I! -- a chance to look over the infrastructure changes. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
linking problem with boost
Hello, This is the first time I'm posting so sorry if I have posted this in the wrong forum... I'm been developing an application on SUSE 9.3, gcc 3.3.5 and within my makefile I have the following for the CPPFLAGS "-g -O0" and the code complied and linked fine. I reached the end of the development and decided to up the optimisation so I changed the line to "-O2" and removed the "-g". When I got the linking stage I got the following error: /usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld: `.gnu.linkonce.t._ZN5boost2io6detail22parse_printf_directiveIcSt11char_traitsIcESaIcEN9__gnu_cxx17__normal_iteratorIPKcSsEESt5ctypeIcEEEbRT2_RKSD_PNS1_11format_itemIT_T0_T1_EERKT3_jh' referenced in section `.rodata' of sg_gui_export_dialog.o: defined in discarded section `.gnu.linkonce.t._ZN5boost2io6detail22parse_printf_directiveIcSt11char_traitsIcESaIcEN9__gnu_cxx17__normal_iteratorIPKcSsEESt5ctypeIcEEEbRT2_RKSD_PNS1_11format_itemIT_T0_T1_EERKT3_jh' of sg_gui_export_dialog.o For what I can figure out its complaining about boost. I got the above error for 4 files and within all 4 files I use the "" library. I have used other boost libraries in other files but the linker didn't complain about them it was only the files where I used "format.hpp". I had a play around and if the CPPFLAGS line within the makefile and if it reads "-g -O2" then it links fine but if I don't have the "-g" it comes up with error above. Does anyone have any clue as to what I'm doing wrong? Thanks, Kiran -- View this message in context: http://www.nabble.com/linking-problem-with-boost-tf3873137.html#a10974006 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Something weird with cp/decl.c switch statement
On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:
MS Visual Studio does not parse it. Are you sure its legal C ?
Yes I am. Try this:
int f(int a)
{
switch (a)
{
case 1:
{
int b = 2;
break;
case 2:
break;
}
}
}
This is valid C90 and C99, though invalid C++98.
If you are using visual studio, make sure it is being compiled as C
and not C++. C++ is not a true superset of C; anyone who thinks needs
to tell their CS teacher (or book author) that they are wrong and they
should relearn about the two languages.
Your right :)
Aaron
Re: linking problem with boost
On Jun 5, 2007, at 10:26 AM, ronnie_raj wrote: This is the first time I'm posting so sorry if I have posted this in the wrong forum... I'd recommend the boost users list, then gcc-help... 3.3.5 is kinda old, I'd probably recommend upgrading to 4.1.x if you can, it may well just work better (though, I'd follow the recommendations of the boost people over this advice :-) ). Hope that helps. Good luck.
Re: libjava is a train wreck.
On Jun 5, 2007, at 9:40 AM, Andrew Haley wrote: Steve Kargl writes: Can someone explain why libjava *must* commit binary files to the repository? A merge of trunk to the fortran-experiments branch generated 70 conflicts that I need to resolve. This is a complete waste of time that would have been spent towards cutting a diff of the branch against trunk for patch submission! In addition to David Daney's comments, I don't really understand why you've got conflicts on your branch. You won't have changed anything in libjava/ there, so the problem shouldn't arise. I agree. I do lots of merges, including 4.2 merging and trunk merging that included all the recent binary files in libjava. A conflict as you describe (barring the integration of the fortran runtime with the java runtime) means that you asked it to do something non-sensical, or some other fundamental problem. You should seek to understand it, and then `fix' it. I'd be happy to help you out. The first step to tracking it down is to examine the end of the last merge and the start of the merge that produced the conflicts. Either, they are the exact same string with a version number, or a tag that was unchanged, or, a diff between the two should yield the empty set. I'd check that first. You can diff any file that conflicted that should not have to understand what went wrong. The best file to do would be a ChangeLog file, as it is self-describing.
Re: Something weird with cp/decl.c switch statement
Thanks for the review. Commited as revision 125339: r125339 | simonb | 2007-06-05 11:29:42 -0700 (Tue, 05 Jun 2007) | 4 lines * decl.c (grokdeclarator): Readability change. Moved case labels into direct switch statement scope. --S Mark Mitchell wrote: Ian Lance Taylor wrote: > And Simon already sent in a tested patch for a couple of days ago: > > http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00199.html This patch is OK, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Help in understanding ccp propagator
On 6/5/07, Revital1 Eres <[EMAIL PROTECTED]> wrote: > I can modify it to catch it pretty easily, just walk back a few vuses > if the current set of vuses is defined by something that does not > actually touch our offset. This sounds like what I am trying to do in ccp... > > > > I am not sure I understand. The new patch uses the infrastructure of > > the propagator and I do not see an indication in the dumps for vdefs > > update after the lattice value is changed: > > > > 19930 > > 19931 Visiting statement: > > 19932 D.61410.first = i0_62; > > 19933 > > 19934 Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. > > 19935 > > > > Thanks again fo your help, > > Revital > > So uh, how do you expect the propagator to notice when the used > variables have changed if the things the vdefs produced by > D.61410.first are not marked as change (so that the immediate uses of > it get processed). > > You will need to add this if it is not there already. > > > Normally, the propagator says "oh, the lattice value of D_64 changed, > let me mark all it's immediate uses for reprocessing". The only thing > that links memory defs to memory uses is the vdef/vuses, so you will > have to be able to process and mark those I thought the engine suppose to take care of that. I do not understand why this case is different from other cases where we propagate for vdefs... The engine only knew how to propagate cases that always make the same set of vdef/vuses, so it was safe to only tell it to use the first vdef. /* Note that for propagation purposes, we are only interested in visiting statements that load the exact same memory reference stored here. Those statements will have the exact same list of virtual uses, so it is enough to set the output of this statement to be its first virtual definition. */ You are changing this, AFAIK, so you will need to make it handle multiple output values. Thanks again, Revital
Re: segmentation fault
On Tue, 2007-06-05 at 11:49 -0400, [EMAIL PROTECTED] wrote: > With apologies for being new: > In porting a hardware configuration from gcc-3.4.1 to gcc-4.2.0, I'm getting > the > following error message: > > In file included from /cygdrive/c/gcc-4.2.0/gcc/crtstuff.c:68: > /cygdrive/c/gcc-4.2.0/gcc/tsystem.h:53: internal compiler error: Segmentation > fault. It is probably Cygwin that is reporting the segmentation fault. If you're a Windows user, this term refers to a memory access fault due to accessing an unmapped address or de-referencing the null pointer. The compiler is crashing while you're compiling one of the earliest source files in the runtime library. This usually suggests a fairly simple and obvious problem -- and I don't think the compiler is properly reporting the fault location to you, based on what you've pasted into your message. I would take the xgcc command executed by the Makefile, add -save-temps to the command line, generate a preprocessed file and then run cc1 under a debugger with crtstuff.i as its input source file. Then you can work out what is going on. Good luck, Ben -- Ben Elliston <[EMAIL PROTECTED]> Australia Development Lab, IBM
