David Eisner | 1 Aug 2008 16:37
Picon
Gravatar

gen-classlist.sh problem while building gcc 4.2.4

Still trying to build gcc-4.2.4 on a Solaris 9 box.  During stage 3, I
run into this problem:

cannes [lib]$ make
true
top_builddir=..
top_srcdir=../../../../../../gcc-4.2.4/libjava/classpath /bin/sh
./gen-classlist.sh standard
Adding java source files from srcdir
'../../../../../../gcc-4.2.4/libjava/classpath'.
Adding java source files from VM directory
/export/data/software/cradle/build/gcc/gcc-4.2.4/libjava
Adding java source files from VM directory
/export/data/software/cradle/build/gcc/objdir/sparc-sun-solaris2.9/sparcv9/libjava
./gen-classlist.sh: test: unknown operator -ef
make: *** [genclasses] Error 1

The problem appears to be that the built-in 'test'  operator in the
/bin/sh Bourne shell that ships with Solaris 9 doesn't understand the
-ef operator, though bash does:

cannes [lib]$ /bin/sh -c 'test foo -ef bar && echo same'
/bin/sh: test: unknown operator -ef
cannes [lib]$ /usr/bin/bash -c 'test foo -ef bar && echo same'
cannes [lib]$

I couldn't find this in the bug database.  Should I report it?

Workaround: in gen-classlist.sh, change
   if test ! "${top_builddir}" -ef
(Continue reading)

Dima Sorkin | 1 Aug 2008 16:45
Picon

Re: getting started

> We ended up modifying some of the libraries and got the "C" code to work
> under Visual Studio 6.  We had special libraries for the GNU C and for the
> "C" component of the graphics libraries. All I want is the old fortran to
> work under Visual Studio and call the old graphics library.  The Fortran
> is pure F77.  I got a FTN95 compiler but its a totally new system with a
> long learning curve.

1) -- F2C --
The F2C (from http://www.netlib.org/f2c, both libf2c.a and the executable)
passes compilation on GCC 4.1.2 (that I have) without even one warning,
simply by typing "GNUmake -f makefile.u".
You can add -fPIC option and produce shared library.

2)  -- Your special libs --
If you can compile and use your "special" C code on GCC, then you can work
on any platform GCC is installed on. Otherwise you will be bound to
Visual Studio,
of which I have little knowledge. MinGW project should ensure interoperability
with libraries compiled on Visual Studio. DJGPP (http://www.delorie.com/djgpp/)
should too... Last time I compiled anything on Windows was in 2004, I had to :)

Regards,
  Dima.

Donak, John | 1 Aug 2008 16:45

Using Mudflap on Powerpc

I am trying to instrument my program to use mudflap, cross-compiling for
powerpc.

I am using gcc-4-1.

When I try to compile my program, I get:

cc1: warnings being treated as errors

In file included from <command line>:1:

/home/jdonak/tipc/src/memCheck/mf-runtime.h:101: warning: #pragma
redefine_extname not supported on this target

/home/jdonak/tipc/src/memCheck/mf-runtime.h:102: warning: #pragma
redefine_extname not supported on this target

/home/jdonak/tipc/src/memCheck/mf-runtime.h:103: warning: #pragma
redefine_extname not supported on this target
...

Looking at the gcc docs, it appears that this pragma is not supported
for powerpc builds.

If so, how can mudflap be used? I would think this configuration would
be pretty standard??

JD

(Continue reading)

Picon

gcc-3.3.6 vs gcc-4.2.2 scimark performance degradation

Hi all,

We are observing a slowdown in the performance of scimark benchmark
w.r.t to the gcc versions 3.3.6 vs 4.2.2. And in our actual application, we
are observing a slowdown of almost 20%..

We are currently using -O2 for compilation for both the gcc versions.
On our product, even with -O3 on gcc-4.2.2, we are not able to reach the
performance of gcc-3.3.6

We are also observing that the size of binary has increased  from 38M to 50MB.
Compiling with -Os didn't yield much benefit (resultant binary was 47 MB).
We were guessing that the increase in size could probably because
of inlining and hence should yield a better performance. But the results
are  disappointing.

We have done the profiling of the application code using gpror and we
observe that
almost 80% of the functions of gcc-4.2.2 are running slower than the
ones on gcc-3.3.6

Did anyone face this sort of issue earlier (slowness 3.x vs 4.x) ?
Could someone suggest the potential list of flags of 4.2.2, which can
probably yield
a better result or at least at par with the 3.3.6, so that we can
experiment a bit
and arrive at the best combination. ( we cannot use the -march flag
and -ffast-math,
due to strict requirement IEEE floating-point conformance )

(Continue reading)

Mateusz Loskot | 1 Aug 2008 23:55
Gravatar

[GCC 4.3] Strange -O2 optimization issue

Hello,

I'm experiencing a strange problem while building a small program
using GCC 4.3.1 (Debian, Lenny) with -O2 optimization.
The program is a simple hash generator from 2D point,
using high and low word of a coordinate (object of double type).
I include a small test program [1]

Here are 3 test cases that differ in optimization flag only

$ g++ -W -Wall -o bar bar.cpp
$ ./bar
1073741824
1073741824
1073741824
1073741824
1073741824

$ g++ -O1 -W -Wall -o bar bar.cpp
$ ./bar
1073741824
1073741824
1073741824
1073741824
1073741824

$ g++ -O2 -W -Wall -o bar bar.cpp
$ ./bar
136623933
1073741824
(Continue reading)

Brian Dessent | 2 Aug 2008 02:11
Favicon

Re: [GCC 4.3] Strange -O2 optimization issue

Mateusz Loskot wrote:

> Why the first value printed is different (136623933) in the 3rd
> test case.

Your suspicion is correct, as this violates the ISO C aliasing rules:

> static unsigned long HashDouble(double* pdfVal)
> {
>      unsigned int* pnValue = (unsigned int*)pdfVal;

You're accessing a variable of type double through a pointer of type
unsigned int.  For the purposes of optimization the compiler is allowed
to assume that values of type double will only be accessed through
variables of type double, and thus it can assume that pdfVal and pnValue
can't refer to the same thing.  It may seem nonsensical in this instance
that it would assume that, but it's still legal for the compiler to do
so.  And being able to make this assumption allows for interesting
optimizations, for example consider something like:

typedef struct { int size; float *data; } foo;

void bar (foo *src, foo *dest)
{
  for (int i = 0; i < src->size; i++)
    dest->data[i] += src->data[i];
}

In this example all the stuff happening in the loop with the data arrays
involves floats so the compiler can prove to itself that src->size (an
(Continue reading)

Mateusz Loskot | 2 Aug 2008 04:14
Gravatar

Re: [GCC 4.3] Strange -O2 optimization issue

Brian Dessent wrote:
> Mateusz Loskot wrote:
> 
>> Why the first value printed is different (136623933) in the 3rd
>> test case.
> 
> Your suspicion is correct, as this violates the ISO C aliasing rules:

Brian,

Good to hear I was close ;-)

>> static unsigned long HashDouble(double* pdfVal)
>> {
>>      unsigned int* pnValue = (unsigned int*)pdfVal;
> 
> You're accessing a variable of type double through a pointer of type
> unsigned int.  For the purposes of optimization the compiler is allowed
> to assume that values of type double will only be accessed through
> variables of type double, and thus it can assume that pdfVal and pnValue
> can't refer to the same thing.  It may seem nonsensical in this instance
> that it would assume that, but it's still legal for the compiler to do
> so.  
 > [...]

Thank you very much for in-depth explanation of the problem.
It was greatly helpful.

> If you want to rewrite your code in a conformant way you can use a union
> or memcpy; or you can disable strict aliasing with
(Continue reading)

Ralf Wildenhues | 2 Aug 2008 14:29
Picon
Picon

Re: gen-classlist.sh problem while building gcc 4.2.4

David Eisner <deisner <at> gmail.com> writes:
> Still trying to build gcc-4.2.4 on a Solaris 9 box.  During stage 3, I
> run into this problem:

> ./gen-classlist.sh: test: unknown operator -ef
> make: *** [genclasses] Error 1

> I couldn't find this in the bug database.  Should I report it?

This is <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25557>.
If this isn't a regression (which I'm not sure of), then I guess this
bug won't be fixed in the branch.

The relevant diff between branch-4_2 and branch-4_3 is this (which looks
a bit different from the patch proposed in that PR):

--- gen-classlist.sh.in       2008-02-13 20:44:41.000000000 +0100
+++ gen-classlist.sh.in       2008-02-19 21:08:25.000000000 +0100
 <at>  <at>  -55,7 +62,9  <at>  <at> 
 done

 # Only include generated files once.
-if test ! "${top_builddir}" -ef " <at> top_srcdir <at> "; then
+abs_top_builddir=`cd "${top_builddir}"; pwd`
+abs_top_srcdir=`cd " <at> top_srcdir <at> "; pwd`
+if test "$abs_top_builddir" != "$abs_top_srcdir"; then
   echo "Adding generated files in builddir '${top_builddir}'."
   # Currently the only generated files are in gnu.*.
   (cd ${top_builddir};  <at> FIND <at>  gnu -follow -name '*.java' -print) |
 <at>  <at>  -95,7 +104,7  <at>  <at> 
(Continue reading)

Eus | 2 Aug 2008 15:49
Picon
Gravatar

Re: build 4.3.1 from source

Hi Ho!

On Wed, 07/30/08, "Leslie(Pete) Boyd" <lhb <at> hpcc.epa.gov> wrote:

> tornado:/usr/local/bin # ./gfortran -v
> Using built-in specs.
> Target: ia64-unknown-linux-gnu
> Configured with: ./configure
                   ^^^
Quoting Eljay:

> That is unsupported.
> 
> As per the instructions, build in a separate directory that is not in the
> source directory, or in any subdirectory thereof.
> 
> Your source code is tainted.  Delete it and start with a fresh untar.
> 
> Also, as per the instructions, make sure you have all the prerequisites.
> 
> HTH,
> --Eljay

Best regards,
Eus

Eus | 2 Aug 2008 15:52
Picon
Gravatar

Re: Description warnings

Hi Ho!

On Thu, 07/31/08, "Kastil" <lordgalloth <at> gmail.com> wrote:

> Hello,
> 
> Is there any description of all possible warning that gcc can produce? I  
> would like to found some document, when all warning would be described  
> instead of constantly searching through Internet.
> Thank for all suggestions

You may as well try to contact "Simon Toth" <happy.cerberus <at> gmail.com> because he said on
gcc-thread.147973 <at> gcc.gnu.org that he would like to build a database about all GCC warnings and errors.

> Jan
> 
> -- 

Best regards,
Eus


Gmane