IainS writes:
> that's really neat indeed - I should have spotted the potential looking at
> the code in contrib
> ... although the site.exp is hardwired in btest.sh at present ;
> I guess one might be able to use .dejagnurc - just need to check on the
> order that the files are processed.
Far
On 10 Mar 2010, at 09:12, Rainer Orth wrote:
IainS writes:
that's really neat indeed - I should have spotted the potential
looking at
the code in contrib
... although the site.exp is hardwired in btest.sh at present ;
I guess one might be able to use .dejagnurc - just need to check on
t
On 10 Mar 2010, at 09:22, IainS wrote:
Far easier: just set the DEJAGNU environment variable to the absolute
path to the size.exp file. runtest knows about that.
the DEJAGNU env. var is set in btest.sh
my mistake.
duh - that's what comes of working with code that was forked a long
time a
IainS writes:
>> Far easier: just set the DEJAGNU environment variable to the absolute
>> path to the size.exp file. runtest knows about that.
> the DEJAGNU env. var is set in btest.sh
It's not:
$ grep DEJAGNU contrib/regression/btest-gcc.sh
# DEJAGNU: should point to a site.exp suitable for t
On 03/06/2010 12:03 AM, Joseph S. Myers wrote:
On Fri, 5 Mar 2010, Ian Lance Taylor wrote:
Dave Korn writes:
I think you'll probably have to use plain old iswalpha. Looking at opts.c,
I'm guessing you're trying to extend the help string format to allow unicode?
Note that it may be OK to
2010/3/9 Marcin Baczyński :
> Hi,
> the following piece of code produces different output on svn trunk and
> gcc-4_4-branch:
>
> #include
> int main()
> {
> struct { unsigned bar:1; } foo;
>
> foo.bar = 0x1;
>
> printf("%08x\n", (unsigned char)(foo.bar * 0xfe));
> print
Hello,
I'm having some problem with compiling OpenCV code on Solaris SPARC with GCC
4.4.3, I don't know whether it is an OpenCV bug (I have posted on their mailing
list too) or a gcc bug. I was hoping someone may be able to shed some light on
the error and provide some ideas on what I could loo
On Wed, Mar 10, 2010 at 01:30:36PM +, Nick Fielding wrote:
> The first syntax error the compiler complains about I think is the main
> problem:
> /tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:673: error: expected ',' or '...'
> before numeric constant
>
> However, when I look at the line of code
We have a problem with arguments passing in memory.
The caller puts the arguments in memory relative to the sp:
add sp, 4 // allocate space for the argument. stack grows up
store r1, (sp-4) // store the argument on the stack
call xxx// call the function.
In xxx the result co
Hi,
this code
---
template
struct A
{
template
struct B;
template
struct B<_N, _T::m>
{
static void f();
};
};
struct C
{
static const int m = 4;
};
void m()
{
A::B<1, 4>::f();
}
--
causes the following ICE as of 4.2
[g++ 4.4]
test.cc:
On 03/10/2010 09:02 AM, Frank Isamov wrote:
> How can I tell GCC that that the callee should load from the
> original offset + 4?
You'll want to set FIRST_PARM_OFFSET and INCOMING_FRAME_SP_OFFSET.
r~
FWIW;
the bus errors were consistently coming from expect in a strcpy [about
100 tcl levels down]
the actual fault was a corrupted dejagnu installation - it's not clear
how that happened - nothing present in syslogs to indicate disk
problems.
a clean install of dejagnu appears to have c
Hi -
This is a test for gcc.gnu.org's listarch for this mailing list,
which has interrupted.
- FChE
Hello All,
Sylvestre Ledru is very nicely trying to package MELT as a packaged
debian plugin for GCC 4.5 - MELT can be compiled either as an entire GCC
branch, or as a GCC 4.5 -i.e. trunk- plugin.
However, we seems to have found some difficult issue. As Diego added
into the documentation:
h
On Wed, Mar 10, 2010 at 07:04:20PM +0100, Roger Ferrer Ibáñez wrote:
> Is this a known bug or I should fill a PR?
I see that you have just filed a PR for this at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327
Thanks.
Dodji
I am porting gcc 4.3.2 to my own micro-controller.
For below piece of code, the instruction "clr.w a15" obviously doesn't
belong to the inner loop. Compiler should be smart enough to move it
to the beginning of the function.
How I can hoist the constant out of loops?
Maybe the costs functions have
Basile Starynkevitch wrote:
In other words, would a gt-melt-runtime.h generated on
Debian/Linux/AMD64 would be ok for a Debian/Linux/x86 or
Debian/Linux/ARM? I blindly guess that probably not, but I am not sure.
Apparently, the constraint that gengtype requires availability of both
the sour
17 matches
Mail list logo
