Re: legitimate parallel make check?

[Rainer Orth]

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 easier: just set the DEJAGNU environment variable to the absolute
path to the size.exp file.  runtest knows about that.

> hmm.  I see that the make check would work using that neat method above...
> ... however,
>
> 1/ I want a different language list than the default...
> 2/ also some other different configure options...

I've got some local patches for btest-gcc.sh which allow just that
(e.g. support for Ada testing), which I'll submit once I'm reasonably
confident they are general enough.

> but mainly
> 3/
> ...  As I read it -  btest.sh strips everything but the testname from the
> PASSES and FAILS files. (the awk lines that print $2 for a match  of /FAIL:
> / etc.)
> This means (e.g.) that if a test passes at m32 and fails at m64 I think it
> will appear in both PASSES and FAILS..
> ...  this seems destined to result in confusion...

You can still use make mail-report.log in the build subdir to get the
complete summary; besides, there's still contrib/dg-cmp-results.sh
(which I haven't checked out yet).

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: legitimate parallel make check?

[IainS]

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  
the

order that the files are processed.


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

hmm.  I see that the make check would work using that neat method  
above...

... however,

1/ I want a different language list than the default...
2/ also some other different configure options...


I've got some local patches for btest-gcc.sh which allow just that
(e.g. support for Ada testing), which I'll submit once I'm reasonably
confident they are general enough.

OK - (but I'm happy that my local mods for this are also working).


but mainly
3/
...  As I read it -  btest.sh strips everything but the testname  
from the
PASSES and FAILS files. (the awk lines that print $2 for a match   
of /FAIL:

/ etc.)
This means (e.g.) that if a test passes at m32 and fails at m64 I  
think it

will appear in both PASSES and FAILS..
...  this seems destined to result in confusion...


You can still use make mail-report.log in the build subdir to get the
complete summary; besides, there's still contrib/dg-cmp-results.sh
(which I haven't checked out yet).


contrib/compare_tests is good (I was thinking to merge the capability  
of that with the capability of btest.sh)

meetings today... so until later

I can't find a hardware fault -- but I'm exploring a hunch about a  
FBKAC 


Iain

Re: legitimate parallel make check?

[Office Admin]

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 ago ..

.. it isn't set in the current version..
Iain

Re: legitimate parallel make check?

[Rainer Orth]

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 testing

>> I've got some local patches for btest-gcc.sh which allow just that
>> (e.g. support for Ada testing), which I'll submit once I'm reasonably
>> confident they are general enough.
> OK - (but I'm happy that my local mods for this are also working).

Without doubt, but why should everyone trying to use this have to
reinvent the wheel?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Use the wctype builtins functions

[Shujing Zhao]

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 use iswalpha strictly on command line
options, but using it anywhere else gets you into a set of issues
around -finput-charset and -fexec-charset.


The present issue is help text, as produced by gettext (which produces 
output in the locale's LC_CTYPE, calling iconv internally as needed).  See 
my discussion at  
of the issues with line breaking given a string of multibyte characters, 
whose display width may also vary.


I don't know if there's an existing free software implementation of UAX#14 
(Unicode Line Breaking Algorithm) suitable for use in GCC; that would be 
the very heavyweight approach.  I also don't know if that algorithm would 
actually work well for the peculiarities of option help strings, not 
having studied the details of it.  Hence the suggestion that the existing 
algorithm in opts.c could be reworked to check for L'-', L'/', L' ' and 
use iswalpha.


Thank you all to that replied. I finally include  on intl.c and use 
isw* strictly to handle the wide-character help string.
The updated patch for the issue that Joseph mentioned is at 
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00364.html. Any advices will be 
appreciated.


Thanks
Pearly

Re: Incorrect casting?

[Richard Guenther]

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));
>        printf("%08x\n", (unsigned char)(foo.bar * 0xff));
>
>        return 0;
> }
>
> monst...@yggdrasil /data/tmp $ gcc -v
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc-svn/configure --enable-stage1-languages-c
> --enable-languages=c,c++
> Thread model: posix
> gcc version 4.4.4 20100309 (prerelease) (GCC)
> monst...@yggdrasil /data/tmp $ ./a.out
> 00fe
> 0001
>
> monst...@yggdrasil /data/tmp $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc-svn/configure --enable-stage1-languages-c
> --enable-languages=c,c++
> Thread model: posix
> gcc version 4.5.0 20100309 (experimental) (GCC)
> monst...@yggdrasil /data/tmp $ ./a.out
> 00fe
> 00ff
>
> Is there something illegal in this code or is it a bug somewhere?

Probably something that was fixed for 4.5 but not backported to 4.4.
The 4.4 C frontend produces for the 2nd printf:

  printf ((const char * restrict) "%08x\n", (int) -foo.bar);

while 4.5 does

  printf ((const char * restrict) "%08x\n", (int) -(unsigned char) foo.bar);

I'm not sure where this difference comes from (and I can't convince
myself that this is a real fix).  Please file a bugreport.

Btw, 4.3 produced

  printf ((const char * restrict) (char *) "%08x\n", (int) (unsigned
char) ((int) foo.bar * 255));

and the same runtime result as 4.5.

Thanks,
Richard.

> Thanks,
> Marcin
>

Compiling OpenCV 2.0 on Solaris 10 with GCC 4.4.3

[Nick Fielding]

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 look at to try and resolve it.

Basically I'm getting the following error:

[ 54%] Building CXX object src/cxcore/CMakeFiles/cxcore.dir/cxmatmul.o
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:673: error: expected ',' or '...' 
before numeric constant
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp: In function 'void cv::gemm(const 
cv::Mat&, const cv::Mat&)':
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:682: error: conversion from 'int' to 
'cv::Mat' is ambiguous
/tmp/OpenCV-2.0.0/include/opencv/cxcore.hpp:732: note: candidates are: 
cv::Mat::Mat(const IplImage*, bool) 
/tmp/OpenCV-2.0.0/include/opencv/cxmat.hpp:194: note: 
cv::Mat::Mat(const CvMat*, bool) 
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:683: error: request for member 'data' 
in '32', which is of non-class type 'int'
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:683: error: 'beta' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:683: error: lvalue required as unary 
'&' operand
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:689: error: 'flags' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:715: error: 'flags' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:718: error: 'flags' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:718: error: 'D' was not declared in 
this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:725: error: 'D' was not declared in 
this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:727: error: 'flags' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:752: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:769: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:784: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:804: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:821: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:845: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:879: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:896: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:911: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:931: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:948: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:972: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1028: error: 'flags' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1102: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1102: error: 'flags' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1106: error: 'flags' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1233: error: 'alpha' was not declared 
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1240: error: 'alpha' was not declared 
in this scope
make[2]: *** [src/cxcore/CMakeFiles/cxcore.dir/cxmatmul.o] Error 1
make[1]: *** [src/cxcore/CMakeFiles/cxcore.dir/all] Error 2
make: *** [all] Error 2

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 it's complaining about I can see 
absolutely nothing wrong with it:

   ...
   664  static void GEMMStore_64fc( const Complexd* c_data, size_t c_step,
   665const Complexd* d_buf, size_t d_buf_step,
   666Complexd* d_data, size_t d_step, Size d_size,
   667double alpha, double beta, int flags )
   668  {
   669  GEMMStore(c_data, c_step, d_buf, d_buf_step, d_data, d_step, 
d_size, alpha, beta, flags);
   670  }
   671
   672
   673  void gemm( const Mat& _A, const Mat& _B double alpha,
   674   const Mat& _C, double beta,  Mat& D, int flags )
   675  {
   676  const int block_lin_size = 128;
   677  const int block_size = block_lin_size * block_lin_size;
   678
   679  static double zero[] = {0,0,0,0};
   680  static float zerof[] = {0,0,0,0};
   ...

What could possibly be causing this error??

Environment configuration
=

SunOS ignatius 5.10 Generic_142900-03 sun4u sparc SUNW,Sun-Fire-V440

GCC 4.4.3
GNU Make 3.80

LD_OPTIONS=-R/usr/local/lib/ -R/usr/

Re: Compiling OpenCV 2.0 on Solaris 10 with GCC 4.4.3

[Nathan Froyd]

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 it's complaining about I can see 
> absolutely nothing wrong with it:
> 
>...
>673  void gemm( const Mat& _A, const Mat& _B double alpha,
   ^

Looks like a missing comma.

-Nathan

Advancing SP on a call

[Frank Isamov]

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 code looks like:
load (sp-4), r1   // load the argument from the stack.

The problem is that the 'call' instruction pushes the return address
to the stack and
increments the sp by 4 so when the callee tries to access the memory
it does not get
to the correct location.

How can I tell GCC that that the callee should load from the original
offset + 4?

Thanks.

ICE with nontype template parameter

[Roger Ferrer Ibáñez]

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: In function ‘void m()’:
test.cc:22: internal compiler error: in unify, at cp/pt.c:14081

g++ 4.1 yields this error, instead

[g++ 4.1]
test.cc: In function ‘void m()’:
test.cc:22: error: incomplete type ‘A::B<1, 4>’ used in nested name specifier

This code seems fine to me (and so seems to intel, xlc++ and comeau online) so 
I assume it is some issue in g++.

Is this a known bug or I should fill a PR? 


(It seems that GCC's bugzilla has some issues at the moment of writing this 
message)

Kind regards,

--
Roger Ferrer Ibáñez - roger.fer...@bsc.es

Re: Advancing SP on a call

[Richard Henderson]

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~

Re: legitimate parallel make check?

[IainS]

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 cleared the problem.

On 10 Mar 2010, at 09:47, Rainer Orth wrote:


IainS  writes:

I've got some local patches for btest-gcc.sh which allow just that
(e.g. support for Ada testing), which I'll submit once I'm  
reasonably

confident they are general enough.

OK - (but I'm happy that my local mods for this are also working).


Without doubt, but why should everyone trying to use this have to
reinvent the wheel?


indeed, I have every intention of sharing my changes too (at least  
those that are of any merit).


thanks for the help, and apologies that it was noise in the end...
Iain

test listarch

[Frank Ch. Eigler]

Hi -

This is a test for gcc.gnu.org's listarch for this mailing list,
which has interrupted.

- FChE

Does gengtyped gt-*.h depends upon the configuration of the compiler?

[Basile Starynkevitch]

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:

http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins

"Plugins needing to use gengtype require a GCC build directory for the 
 same version of GCC that they will be linked against."


The MELT plugin uses PLUGIN_REGISTER_GGC_ROOTS et PLUGIN_GGC_MARKING

So it needs to run gengtype to generate the GGC roots table specific to 
MELT. MELT also have its own GTY-ed struct in melt-runtime.h & some 
GTY-ed roots in melt-runtime.c


MELT only need gengtype to generate its gt-melt-runtime.h but I have no 
idea if that file depends upon the configuration (and notably the target 
for which GCC is built). The GTY-ed data of MELT does not depend (IMHO) 
upon the configuration directly (in the sense that there is no #ifdef 
around GTY-ed struct), but of course it points to data like Gimple or 
Tree which I imagine depend upon the configuration of GCC (notably 
--enable-check but perhaps also the target ...)


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 source & the build trees of the GCC for which the plugin is built is 
quite unnatural (but of course I understand why it is needed) and could 
be perhaps incompatible with the way many Linux distributions (including 
Debian) are naturally packaging GCC.


Comments are welcome.

Regards.

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: ICE with nontype template parameter

[Dodji Seketeli]

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

constant hoisting out of loops

[fanqifei]

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 to be changed, but I don't know how.
Thanks.

C code:
void memzero_aligned(uint* ptr, uint size)
{
uint ptr_end = (uint)ptr + size;
while ((uint)ptr < ptr_end)
{
 *ptr++ = 0;
}
}

Disassembly code:
 <_memzero_aligned>:
   0:   bc ab 90   add.w a9 a10 a11;
   3:   f4 0e 0bbra 0xe;  #branch unconditionally, no delay slot
   6:   bd f4clr.w a15; #clear to zero
   8:   80 af 00std.w a10 0x0 a15;
   b:   90 aa 04   add.w a10 a10 0x4;
   e:   b8 a9 06   cmp.w a10 a9;
  11:   f4 08 f5brc 0x6;
  14:   f8 00ret;

-- 
-Qifei Fan
http://freshtime.org

Re: Does gengtyped gt-*.h depends upon the configuration of the compiler?

[Basile Starynkevitch]

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 source & the build trees of the GCC for which the plugin is built is 
quite unnatural (but of course I understand why it is needed) and could 
be perhaps incompatible with the way many Linux distributions (including 
Debian) are naturally packaging GCC.



I also have sent to the Debian GCC team an email 
http://lists.debian.org/debian-gcc/2010/03/msg00047.html describing my 
views and issues.


Perhaps should I send the same emails to both gcc@ & debian-gcc@ ? Is it 
appropriate?


Regards.


--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***