Hi Mike,
[I'm replying in this thread to the Objective-C patch you posted in
the type-traits discussion, because both that post and this one are
about reducing the number of tree codes]
On 3/13/07, Mike Stump <[EMAIL PROTECTED]> wrote:
I just converted the Objective-C front-end to free up enoug
[EMAIL PROTECTED] (Mike Stump) writes:
> ../../gcc/gcc/var-tracking.c: In function âvariable_tracking_mainâ:
> ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not
> occur when assuming that (X - c) >= X is always true
> ../../gcc/gcc/var-tracking.c:2961: warning: ass
On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrote:
> Interestingly, while...
>
> gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp
> -lstdc++ -lm -m32 -o ./pr30703.exe
> /usr/bin/ld: Undefined symbols:
> __Unwind_Resume
> collect2: ld returned 1 exit statu
On 3/13/07, Jim Wilson <[EMAIL PROTECTED]> wrote:
Sunzir Deepur wrote:
> My wish is to generate a CFG in which I would know, for each basic block
> and RTL command, what is the virtual address this command will be at
> in the binary..
You can already find much of this info in the gcov profiling
Hello group,
any idea where I can find a (free) graphical VCG viewer suitable
for gcc's vcg outputs ?
seems like the old 1995 package is not applicable on newest linux systems
(am working on fedora).
Thank You
sunzir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 13, 2007 at 11:15:27AM -0700, Brian Dessent wrote:
> Kai Tietz wrote:
> > Ok, I will try for this. I have to find a different editor, which is
> > not too smart as to remove trailing whitespaces ...
>
> Or just add -w to the diff options w
Hello!
Recent committed patch breaks i386ssefp-2.c testcase, where maxsd is
not generated anymore.
I have looked a bit into this failure and noticed that for some reason
we don't perform ifcvt transformations during ce1 RTL pass. The second
transformation is still performed during ce2 pass, but
On 3/14/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
Hi Mike,
[I'm replying in this thread to the Objective-C patch you posted in
the type-traits discussion, because both that post and this one are
about reducing the number of tree codes]
On 3/13/07, Mike Stump <[EMAIL PROTECTED]> wrote:
> I just
> > I'll find a way to fix that.
>
> Revital, please try this. I've tested it but know better than to check
> things in at the end of the day; I'll post it tomorrow.
It fixes the problem.
Thanks,
Revital
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
On Tue, Mar 13, 2007 at 02:22:06PM -0700, Jim Wilson wrote:
> Revital1 Eres wrote:
> >ERROR: tcl error sourcing
> >/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp.
> >ER
Hello,
I have used -da and -dv to produce vcg files of the CFG of this simple program:
int main(int argc, char**argv)
{
if(argc)
printf("positive\n");
else
printf("zero\n");
return 0;
}
I have expected to get a CFG as follows:
Hi all,
first of all i want to thank you for the aid that i have receveid from
this mailing list. I have another little question:
if i have a statemente that is an expression, for example x+5 , how
can i know if the operation is plus (+), or minus (-), or equal(=) or
less (<) etc..
Can you give me
Hi,
in some cases, a breakpoint can't be set on a continue or break
statement. Here is a simple example:
void foc (void)
{
int a, i;
for (i = 1; i <= 10; i++) {
if (i < 3)
a = 1;
else
break; // line 9
a = 5;
}
}
int main(void)
{
foc ();
}
The reason is quie
Andrea Callia D'Iddio wrote on 14/03/2007 12:36:59:
> Hi all,
> first of all i want to thank you for the aid that i have receveid from
> this mailing list. I have another little question:
> if i have a statemente that is an expression, for example x+5 , how
> can i know if the operation is plus (
Jakub,
So shouldn't we either XFAIL pr30703.C on *-apple-darwin* or
specify that the -shared-libgcc flag should be used on that
target for pr30703.C?
Jack
On Wed, Mar 14, 2007 at 10:11:35AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrot
Hi,
We have a '{2,2}' expression (vector initializer) propagated by dom into a
BIT_FIELD_REF:
before (bug.c.105t.vrp2):
vector long int vect_cst_.47;
vect_cst_.47_66 = {2, 2};
D.2103_79 = BIT_FIELD_REF ;
after (bug.c.106t.dom3):
"
Optimizing block #7
Optimi
On 13 March 2007 19:56, Ian Lance Taylor wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> The intermediate cause is that lreg considers all the special-purpose reg
>> classes when allocating, and for some reason decides that several of the
>> special-purpose classes have equal cost (zero)
On 3/14/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
Hi,
We have a '{2,2}' expression (vector initializer) propagated by dom into a
BIT_FIELD_REF:
before (bug.c.105t.vrp2):
vector long int vect_cst_.47;
vect_cst_.47_66 = {2, 2};
D.2103_79 = BIT_FIELD_REF ;
after (bug.c.106t.
On 3/14/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
#define LANG_TYPE_CODE (t) (TREE_CODE (t) == LANG_TYPE ?
LANG_TYPE_SUBCODE (t) : INVALID_SUBCODE)
and then INVALID_SUBCODE will fall through to the default case as well.
But that doesn't put the subcodes and the codes into the same
"names
Tristan Gingold <[EMAIL PROTECTED]> writes:
> in some cases, a breakpoint can't be set on a continue or break
> statement. Here is a simple example:
> The reason is quiet simple: even at -O0 -g, there is no insn (and no
> BB) corresponding to the break/continue statement.
> Here is a small patch
Dorit Nuzman <[EMAIL PROTECTED]> writes:
> D.2103_79 = BIT_FIELD_REF <{2, 2}, 64, 0>;
>
>
> ...which causes he following ICE:
> "
>bug.c:8: error: invalid reference prefix
>{2, 2}
>bug.c:8: internal compiler error: verify_stmts failed
> "
Maybe fold-const.c needs to recognize
On 14 Mar 2007 07:22:10 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Dorit Nuzman <[EMAIL PROTECTED]> writes:
> D.2103_79 = BIT_FIELD_REF <{2, 2}, 64, 0>;
>
>
> ...which causes he following ICE:
> "
>bug.c:8: error: invalid reference prefix
>{2, 2}
>bug.c:8: internal comp
"Doug Gregor" <[EMAIL PROTECTED]> writes:
> Of course, one could use TREE_CODE to see through the difference
> between these two, e.g.,
>
> #define TREE_CODE(NODE)
> ((enum tree_code) (NODE)->base.code == LANG_TYPE?
> (enum tree_code)((TYPE_LANG_SPECIFIC (NODE)->base.subcode +
> LAS
>From: Ben Elliston <[EMAIL PROTECTED]>
>> gcc --coverage appears to be broken on x86_64 in gcc 4.1.1 on FC6
>> (works fine with Trunk). I'm almost certain that this is a known
>> issue, but cannot find a reference in Bugzilla.
>
>I implemented that option, so can probably help you. Contact me in
"Doug Gregor" <[EMAIL PROTECTED]> writes:
> Of course, one could use TREE_CODE to see through the difference
> between these two, e.g.,
>
> #define TREE_CODE(NODE)
> ((enum tree_code) (NODE)->base.code == LANG_TYPE?
> (enum tree_code)((TYPE_LANG_SPECIFIC (NODE)->base.subcode +
> LAS
On Wed, Mar 14, 2007 at 11:36:24AM +0200, Sunzir Deepur wrote:
> Hello group,
>
> any idea where I can find a (free) graphical VCG viewer suitable
> for gcc's vcg outputs ?
>
> seems like the old 1995 package is not applicable on newest linux systems
> (am working on fedora).
See http://www.grap
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote:
> On Tue, 13 Mar 2007, Andrew Pinski wrote:
>
> > Anyways the best way to fix this is just to fix the bug. Someone
>
> We should have 0 unexpected FAILs in 4.2.0 on common platforms (in
> particular the primary release criteria one
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote:
> > It's not punishing the testcase; it's recognising that we have a bug
> > tracking system to track regressions and having "expected unexpected
> > FAILs" is helpful neither to users wishing to know if their compiler built
> > a
Bootstrapping the trunk (Revision: 122847) on a mipsel-linux system
configured thusly:
$ ../gcc/configure --with-arch=mips32 --with-float=soft
--disable-java-awt --without-x --disable-tls --enable-__cxa_atexit
--disable-jvmpi --disable-static --disable-libmudflap
--enable-languages=c,c++,java
Joe Buck <[EMAIL PROTECTED]> writes:
> On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote:
> > > It's not punishing the testcase; it's recognising that we have a bug
> > > tracking system to track regressions and having "expected unexpected
> > > FAILs" is helpful neither to users w
On 3/14/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote:
Hello,
I have used -da and -dv to produce vcg files of the CFG of this simple program:
int main(int argc, char**argv)
{
if(argc)
printf("positive\n");
else
printf("zero\n");
return 0;
}
I put the dicussion about compiler books in a WIKI page:
http://gcc.gnu.org/wiki/ListOfCompilerBooks since I feel it is of common
interest.
Please feel free to correct any mistakes and ad more comments or books.
Michael Cieslinski
On 3/14/07, Tristan Gingold <[EMAIL PROTECTED]> wrote:
Hi,
in some cases, a breakpoint can't be set on a continue or break
statement. Here is a simple example:
I think this is also related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
Yes, yes I have the whole bugzilla memorized. :)
On Wed, 2007-03-14 at 15:06 +0100, Richard Guenther wrote:
> I think the BIT_FIELD_REF should be properly folded to a constant or
> the propagation not done.
Agreed. I'd lean towards folding the BIT_FIELD_REF to a constant, but
if that isn't easy I'd recommend avoiding the propagation.
Jeff
* David Daney <[EMAIL PROTECTED]> [2007-03-14 10:01]:
> I get:
> $ make compare
> Comparing stages 2 and 3
Probably the same as PR31169, reported for HPPA. Unfortunately the PR
doesn't contain much useful information yet.
--
Martin Michlmayr
[EMAIL PROTECTED]
Rohit Arul Raj wrote:
(define_insn "movsf_store"
[(set (match_operand:SF 0 "memory_operand" "=m")
(match_operand:SF 1 "float_reg""f"))]
You must have a single movsf define_insn that accepts all alternatives
so that reload will work. You can't have separate define_insns for
movsf an
On Mar 14, 2007, at 1:49 AM, Ian Lance Taylor wrote:
I see it now. My apologies. I just committed a patch to the 4.2
branch to fix it.
--enable-werror, however, that only works well if you have installed
a gcc of the same vintage as your building. If they differ too much,
you'll still mi
[ oops, almost forgot why I stared sending the email ]
On Mar 14, 2007, at 1:49 AM, Ian Lance Taylor wrote:
I see it now. My apologies. I just committed a patch to the 4.2
branch to fix it.
I can confirm that fixed it, thanks.
Dear GCC Developers/Users,
I am working on a port of a target backend. I have a problem when
compiling the following program:
---snip---
short b = 5;
short c = 5;
int main(void)
{
long int a[b][c];
a[1][1]=5;
return 0;
}
---snap---
During compilation I get the following e
On Mar 14, 2007, at 2:11 AM, Jakub Jelinek wrote:
On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrote:
Interestingly, while...
gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/
lib -lgomp -lstdc++ -lm -m32 -o ./pr30703.exe
Could we please use g++ to compile C++ c
Markus Franke wrote:
Does anybody have an idea what could be wrong in the machine description
or to where start finding the error?
Compile with -da, and starting looking at the RTL dumps, mainly the greg
and lreg ones. The greg one will have a section listing all of the
reloads generated, fi
It looks like modifying the testsuite scripts for libgomp
to properly compile c++ files with g++ will be pretty messy.
Can we just fix PR30703 for now with the simple change...
Index: libgomp/testsuite/libgomp.c++/pr30703.C
===
/u
I'm working on readying the Toshiba Media Processor (mep-elf) port for
contribution to GCC 4.x, but we added some core changes needed to
support it. The changes are listed below; I'd like some feedback
about these before I go too far with them. Are these concepts
acceptable for inclusion in gcc?
DJ Delorie <[EMAIL PROTECTED]> writes:
> Coprocessor types - the MeP chip has optional coprocessors, each with
> their own register sets. They need their own internal types (mostly
> to keep track of which unit to use), which we've created by prefixing
> the existing types with COP (i.e. COPSImod
This and the register changes come close to multi-arch gcc. Is that a
direction we want to go? Historically we have not tried to support
Personally I'd love to see us go this way if it doesn't inconvenience
us too much.
From what I remember of the MeP port it was pretty clean and wouldn't
> This and the register changes come close to multi-arch gcc.
Yup. The core has two modes, core and vliw, and the coprocessor(s)
each have their own units. The core manages the opcode processing,
but the coprocessor does the work.
> Historically we have not tried to support different architect
> Personally I'd love to see us go this way if it doesn't
> inconvenience us too much.
It would be useful to be able to optimize each function as to, for
example, arm or thumb mode based on -Os and/or some heuristics. As a
long-term goal, at least.
Hello all,
Looking at the internals i couldn't find an answer for my problem.
I have a define_expand with the pattern name mov and a
define_insn mov_store
The predicate in define_expand is general_operand, so that all
operands are matched.
While in define_insn i have a predicate which allows onl
On Mar 14, 2007, "Uros Bizjak" <[EMAIL PROTECTED]> wrote:
> Recent committed patch breaks i386ssefp-2.c testcase, where maxsd is
> not generated anymore.
FWIW, I saw it both before and after the patch for PR 31127. I've
just tried reverting PR 30643 as well, but the problem remains. So
it's unr
On 14 Mar 2007 18:42:13 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
DJ Delorie <[EMAIL PROTECTED]> writes:
> Coprocessor types - the MeP chip has optional coprocessors, each with
> their own register sets. They need their own internal types (mostly
> to keep track of which unit to use),
> This is what we do for the Cell also, we expect people to compile
> using two different compilers right now, but we are actually looking
> into doing an "one source" based compiling where some functions or
> loops are pushed off to the SPUs via annotations like the OpenMP
> ones.
It sounds like
Janis Johnson wrote:
>> It's not punishing the testcase; it's recognising that we have a bug
>> tracking system to track regressions and having "expected unexpected
>> FAILs" is helpful neither to users wishing to know if their compiler built
>> as expected nor to developers glancing over test
52 matches
Mail list logo
