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/bi
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 i
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
> 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
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 (se
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
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
v
> 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
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 your
[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/powe
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
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
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.
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 tex
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 l
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
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
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
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 compile
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
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
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
"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
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
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 i
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 inclu
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 developm
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
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 bett
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 b
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 wrot
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
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/g
33 matches
Mail list logo
