headers
Ken Raeburn | 1 Sep 2007 02:53

Re: loading multiple C++ runtimes but not mixing ABIs?

On Aug 31, 2007, at 16:36, Lawrence Crowl wrote:
> The most likely problem will be mangled names.  Do the two ABIs
> use the same mangling scheme?  If so, you could have a problem
> with a function from one ABI stepping on another.  You can reduce
> this problem by forcing bindings to a particular library, which is
> pretty much automatic on Windows, but requires extra work on
> Unix systems.  You can also, on some systems, restrict the set of
> symbols.  Visible to other libraries.

If symbol versioning is in use, it shouldn't matter.  But when it's  
not...  I would assume (from the ignorant point of view of someone  
doing very little C++ work) that most compiler vendors would be  
converging on a common name mangling scheme to promote  
interoperability, which would mean more name conflicts.

>     Don't use the global operators new and delete.
>     Don't use exceptions.  Set the compiler option that turns them  
> off.
>     Don't use RTTI functions.
>     If you use the standard library, make sure you link it  
> statically into
>     your library and restrict the resulting symbol scope.  (E.g. using
>     map files.)
>
> In summary, it can be done but you'll need to manage more symbols
> than you'd expect.

It's sounding like the remaining benefits wouldn't be worth the  
hassle...  And yet, some people do manage to program in C++. :)  Is  
the usual procedure, then, to just require that the application
(Continue reading)

Permalink | Reply | 3 comments |
headers
Darryl L. Miles | 1 Sep 2007 09:13

RFC: GCC should warn when evaluating a pointer return type from a function used in a conditional that performs arithmetic with it


Subject: RFC: GCC should warn when evaluating a pointer return type from 
a function used in a conditional that performs arithmetic with it

Shouldn't GCC generate some form of warning with the following code, for 
the "if(foobar(i) < 0)" statement ?

It does generate a warning if you use "int j = foobar(i);"

I would think this sort of error should be a default warning (i.e. not 
need to specifying any additional -W option) and it should certainly be 
caught when specifying "-Wall".

Tried with:

gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
gcc version 4.2.1

I don't think MSVC warns but SunPro C compiler (with Solaris 10 / Sun 
Studio 12) does.

Request for comments,

Darryl

#include <stdio.h>

extern char *foobar(int a);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sunil Amitkumar Janki | 1 Sep 2007 13:23
Picon

SPARC64 64-bit tool chain

I have Slackware 12.0 32-bit running on my SPARC server
and would like to build a 64-bit tool chain. I have tried many
times to build it but have failed to get far into the build
process.

I have also tried crosstool but it bails out with an error so
I would rather do it manually so I have more control over
the process and get a better understanding of the whole of
it.

Does anyone have any suggestions as to how to do this?
I can't find a SPARC64 64-bit tool chain anywhere but I
need at least a 64-bit compiler to build a 64-bit kernel
for my server since it won't boot 32-bit Linux kernels.

But I also want to have a pure 64-bit tool chain ready
to experiment with for performance and general testing
purposes.

Regards,
Sunil
Permalink | Reply | 1 comment |
headers
Andrea Marongiu | 1 Sep 2007 18:12
Picon
Favicon

Re: How to remove the option -Qy to as

Pedro Alves ha scritto:
> Andrea Marongiu wrote:
>
>>  gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall
> (...)
>>  /home/marongiu/Desktop/GCC-4.2.1/ARM/LOCAL/arm-elf/bin/as:
>>
>>  unrecognized option `-Qy'
>
>
> Coult it be you have '.' on the $PATH?  Don't do it, or at
> least put it last, and then try again.
>
>
>>  make[1]: *** [g++spec.o] Error 1
>>
>>  make[1]: Leaving directory
>>
>>  `/home/marongiu/Desktop/GCC-4.2.1/ARM/BUILD/GCC/gcc'
>>
>>  make: *** [all-gcc] Error 2
>>
>>  
>
>
> Cheers,
> Pedro Alves
>
I removed '.' from my $PATH and everything worked fine.
Thanks everybody for your time and advices.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ted Byers | 1 Sep 2007 18:41
Favicon

Fine tuning gcc build to machine specific properties

I have successfully built gcc v 4.2.1 on Cygwin on
Windows XP.  make -k check produces decent results for
all the languages I know, as well as for ada (which I
don't know but want to learn: fewer than 0.01% of the
tests fail unexpectedly.   The machine uses a dual
core Athlon 64 processor.

I tried passing something like -msse2 and
-march=athlon64 to configure, but configure rejected
these, claiming that there are no floags like these
for the configure script.  I found these flags in the
gcc documentation, so I am confused.  How do I tell
configure to build executables optimized for my
processor?  Or does that not work well for cygwin on
WXP on an AMD Athlon 64 X 2?

Thanks

Ted
Permalink | Reply | 3 comments |
headers
Brian Dessent | 1 Sep 2007 19:16
Favicon

Re: Fine tuning gcc build to machine specific properties

Ted Byers wrote:

> I tried passing something like -msse2 and
> -march=athlon64 to configure, but configure rejected
> these, claiming that there are no floags like these
> for the configure script.  I found these flags in the
> gcc documentation, so I am confused.  How do I tell
> configure to build executables optimized for my
> processor?  Or does that not work well for cygwin on
> WXP on an AMD Athlon 64 X 2?

Those are gcc options, they aren't configure options.  Specify them to
gcc when building software and it will do what you want.  Normally you
do this by setting the variables CFLAGS for C and CXXFLAGS for C++. 
Autoconf based packages automatically set these to "-g -O2" if they are
not set by the user (and it detects you're using gcc), which means if
you want to set them yourself you probably want to include "-g -O2" in
your own settings, otherwise the default means no optimization and no
debug information.

The only time you'd specify anything to configure is if you want to
change the default value of -march and -mtune that is "baked in" to gcc,
which you do with --with-arch and --with-tune.  But that is not the
usual way of doing things, and it's certainly not necessary to rebuild
gcc every time you want to change this.  It's a lot easier just to leave
gcc generic by default and set your desired *FLAGS.

Brian
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian Dessent | 1 Sep 2007 20:06
Favicon

Re: SPARC64 64-bit tool chain

Sunil Amitkumar Janki wrote:

> I have Slackware 12.0 32-bit running on my SPARC server
> and would like to build a 64-bit tool chain. I have tried many
> times to build it but have failed to get far into the build
> process.

I realize that it can be frustrating when you have tried many things and
they all failed, but in terms of posting for help to a mailing list it
doesn't help to omit the details.  Without knowing the exact steps you
have taken and the exact error messages, we can only speculate as to
what's going wrong.

> I have also tried crosstool but it bails out with an error so
> I would rather do it manually so I have more control over
> the process and get a better understanding of the whole of
> it.
> 
> Does anyone have any suggestions as to how to do this?
> I can't find a SPARC64 64-bit tool chain anywhere but I
> need at least a 64-bit compiler to build a 64-bit kernel
> for my server since it won't boot 32-bit Linux kernels.
> 
> But I also want to have a pure 64-bit tool chain ready
> to experiment with for performance and general testing
> purposes.

The problem with building a cross compiler is that it does not exist in
a vacuum.  You can't just download the source and build it.  A compiler
exists in the context of a C library and a kernel, both of which are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Dessent | 1 Sep 2007 20:21
Favicon

Re: SPARC64 64-bit tool chain

Brian Dessent wrote:

> I put together a small example, see attachment.  Run this in an empty

Oops, I just realized that I made a last minute goof, you need to change
"wget -nvN" to "wget -nv -N".

Brian
Permalink | Reply | 0 comments |
headers
ranjith kumar | 1 Sep 2007 20:59
Picon
Favicon

removing a statement from SSA representation

Hi,
     I tried to remove some statements using functions
bsi_remove(&bsi) and remove_phi_node(phi,temp) at SSA
level.

Are those functions will take care of everything??
ie)Will they update all information like number of
statements in a basic-bolck....etc.

Or any other thing should be done while calling those
functions??

Thanks in advance.

      ___________________________________________________________ 
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  http://uk.promotions.yahoo.com/forgood/environment.html
Permalink | Reply | 0 comments |
headers
Andrew Haley | 2 Sep 2007 12:31
Favicon

Re: Solution sought to GCC 4.1.1 backtrace problem

Blair Barnett writes:
 > Hi Andrew,
 > 
 > So our experiment with the 4.1.1 EABI compiler along with your patch provided no new results.
 > 
 > I applied your patch and recompiled arm-linux-gcc and recompiled our little test program. I copied the
program to our arm device and ran it, obtaining the following output:
 > 
 > arm-linux-gcc -o fault-unwind fault.c
 > 
 >  ./fault-unwind
 > in routine1 at 0x00008874
 > in routine2 at 0x0000882c
 > in routine3 at 0x000087e4
 > in routine4 at 0x00008794
 > in catch_segfault
 > Obtained 1 stack frames.
 > /lib/ld-linux.so.2 [0x40012f84]
 > Segmentation fault

That's what I predicted, right?

 > 
 > 
 > If we run the 4.1.2 compiler included with ubuntu on our little test program, we get the following results:
 > 
 > bbarnett <at> kitt:~$ gcc -v
 > Using built-in specs.
 > Target: i486-linux-gnu
 > Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang
(Continue reading)

Permalink | Reply | 501 comments |

Gmane