gmane.comp.gcc.help

COMPILER_PATH question

Chih Wang — 2012-05-25T23:08:45

Hi all,

I'm experiencing a weird behavior and would appreciate some guidance.

We are using gcc v 4.4.6 (plus necessary packages to support c++
compilation) installed in a non-standard location due to company
policy. When I first logged into the test box, I can compile and link
a test c++ program without any problem. However, as soon as I source
our project specific resource file, the same code fails to compile
with the following error:

gcc: error trying to exec 'cc1plus': execvp: No such file or directory

After some digging around, it appears that the issue is caused by a
different value in COMPILER_PATH as returned by running echo "" | gcc
- -xc -v -E.

Before sourcing our environment file, I got:
COMPILER_PATH=/swdepot/2012-Q2/37178099/SDK/usr/bin/../libexec/gcc/x86_64-redhat-linux/4.4.6/:/swdepot/2012-Q2/37178099/SDK/usr/bin/../libexec/gcc/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/

After sourcing:
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/l

memory overhead of static const char?

Erik Rull — 2012-05-25T20:45:36

Hi all,

when having a .cpp file that contains lines like:

static const char * data = "test";

compile it with -fPIC and link it as a .so file - how big is the actual 
overhead beside the 5 byte text (incl. terminating \0)?

I saw that there are symbols created in the .so file when looking at it 
with objdump -x

I don't need these symbols because I use the defined variables only locally 
in the .cpp file and nobody outside accesses them - maybe another variable 
declaration prevents creating these symbols and reduces the needed memory?

Best regards,

Erik

compile gcc and library

Xin Tong — 2012-05-24T17:40:49

I am looking for an older version of gcc ( gcc version 3.4.X). I can
not find it in my os software repository. therefore i decide to
download the source and compile it myself.  I am looking at this
download link and have a few questions.

1. does gcc-3.4.2.tar.bz2 include all the other tars (i.e.
gcc-g++-3.4.2.tar.bz2 ).
2. if i compile the gcc in  gcc-3.4.2.tar.bz2, is libc going to be
compiled as well ? there are also other libraries such as libstdc++,
is it going to be compiled.
3. is it possible to link again a library compiled by other versions
of gcc (i.e. a program compiled with gcc 3.4.4 and links it with
library that comes with gcc-4.4.6 ) ?

http://gcc.skazkaforyou.com/releases/gcc-3.4.2/

Thanks

Gcov - Cmake - Shared Lib - Problem

Alex Büchel — 2012-05-24T14:16:44


Hi guys,

I am working on a CmakeProjekt. This Projekt creates a shared Library, 
lets call it lib_shared. This shared library will be created in the 
following directory: /home/username/project/build/sharedlibdirectory/ . 


THEN this Cmake project builds a testrun-executable in the following path: 
/home/username/project/build/testrundirectory/ . The shared library 
lib_shared is linked against this test-executable.

Everything works fine. 


My problem appears when i try to use Gcov for this projekt. Of course i 
want to have the code coverage of the sourcefiles of the sharedlibrary. 

I have used the flag "--coverage" and created the gcno files:

The gcno-Files for the test-exectutable will be created in /home/username/project/build/testrundirectory/CMakeFiles/testrundirectory.dir/
The gcno-Files for the shared library will be created in 
/home/username/project/build/sharedlibdirectory/CMakeFiles/sharedlibdirectory.dir/

Then i have started the testrun. 


The gcda Files of this testrun will be created

Unexpected compiler error ( error: template argument 1 is invalid ) when using and using -m32 option on 64-bit system.

Delcypher — 2012-05-24T13:27:23

Hi,

I was playing with a very simple program ( limits.cpp ) as shown below.

#include <limits>
#include <iostream>
using namespace std;
int main()
{
        cout << numeric_limits<int>::has_infinity << endl;
        return 0;
}

on my system (Arch Linux: g++ (GCC) 4.7.0 20120505 (prerelease) ) on a
x86_64 system.

If I compile with

$ g++ -m64 limits.cpp

compilation succeeds. However if I compile as follows I get a rather
unhelpful error.

$ g++ -m32 limits.cpp
In file included from limits.cpp:1:0:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:1405:35:
error: template argument 1 is invalid
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:1479:44:
error: template argument 1 is invalid

Seems a very strange error message to give as I took a look at the
numeric_limits templates in the <limits> header file and it looks
perfectly valid.

Is this a bug or a "feature"?

Regards,
Dan.

Warning message with usage of visibility hidden with wrapper class

Christopher Sigman — 2012-05-24T02:02:41

Hi all,

My team at work and I have started to utilize the visibility
attributes in gcc so that we are building 'nix libraries whose public
symbols are in-line with our Windows builds. With some of our code
though, we're noticing warnings about parts being declared with
greater visibility.  As far as we've been able to determine, there's
nothing being executed incorrectly, but we'd like to understand the
warning before ignoring it.

The code in question is basically set up like this:

class __attribute__ ((visibility ("hidden"))) SomeClass
{
  ...
}

template <T>
class WrappingSomeClass
{
...
  void someFunc()
  {
    SomeClass var;
    ...
  }
...
}

Where the warning occurs on usage of SomeClass in WrappingSomeClass.
Any code using this example links to the library with SomeClass in it.
Any help you can give would be appreciated, and if my super
simplification is overly so, let me know and I can give it in more
detail.

--
CSS

Files with no valid license information

Evan Hunter — 2012-05-23T23:34:58

Hello,

We are using a custom GCC toolchain to build commercial ARM code, and have noticed some issues with licensing of some of the install files that GCC creates.

There are at least 5 small header files that are missing any kind of license information.
There are also many object and static library files created with no clear indication of which (if any) are covered by the LibGCC exception.
In the lib/gcc/arm-none-eabi/4.6.3/plugin/ directory, there are also many GPL header files without the LibGCC exception.

I would like to request:
. A license block in every output header file,  and an output text file specifying which object/library files are covered by the LibGCC exception.
AND/OR
. A build switch to prevent output of any files incompatible with commercial licensed target code.

Attached is a text file detailing the headers/objects/libraries, and the build string I'm using. Also attached is a minor patch to the configure system that we needed.


Regards,

Evan Hunter
(Broadcom, Sydney)










Hea

Fixincludes permanence & questions on cross compilers

rbmj — 2012-05-23T16:52:59

Hi all,

Two questions:

1.  Are fixincludes hacks only active during build-time (e.g. they do 
not replace the actual file) or are they permanent?  If they are only 
temporary/local to gcc, but they need to be permanent, is there a way to 
specify this?

2.  On cross compilers, fixincludes does not appear (to my uneducated 
eye) to be applied to my headers (then again, I may have written the 
hacks wrong) located in sys-include.  Does fixincludes not affect 
headers in sys-include or am I not looking hard enough?

If somebody can explain in a bit more detail how fixincludes works (I 
read the README but it only defines the formatting), please do.

The hacks I'm trying to apply are at the end of this email, if it helps.

Thanks,

Robert Mason

/*
  *  Wrap VxWorks ioctl to keep everything pretty
  */
fix = {
     hackname    = vxworks_ioctl_macro;
     files       = ioLib.h;
     test        = " -r vxWorks.h ";

     c_fix       = format;
     c_fix_arg   = "%0\n"
         "#define ioctl(fd, func, arg) ((ioc

Problem compiling gcc 4.7.0 libgcc on Netgear ReadyNAS DUO Sparc

.uservorname .usernachname — 2012-05-23T13:29:11

Hello,

I'm trying to upgrade my gcc from 4.0 to 4.7.

I got the following compiling enviroment:
2.6.17.14ReadyNAS #1 Thu Sep 1 17:44:33 PDT 2011 padre GNU/Linux
GNU ld (GNU Binutils) 2.22
ldconfig (GNU libc) 2.3.2
GNU Make 3.82
debian sarge

ls /usr/local/lib/libmpfr.*
/usr/local/lib/libmpfr.a   /usr/local/lib/libmpfr.so    /usr/local/lib/libmpfr.so.1.2.2  /usr/local/lib/libmpfr.so.4.1.0
/usr/local/lib/libmpfr.la  /usr/local/lib/libmpfr.so.1  /usr/local/lib/libmpfr.so.4

ls /usr/local/lib/libmpc.*
/usr/local/lib/libmpc.a   /usr/local/lib/libmpc.so    /usr/local/lib/libmpc.so.0.0.0  /usr/local/lib/libmpc.so.2.0.0
/usr/local/lib/libmpc.la  /usr/local/lib/libmpc.so.0  /usr/local/lib/libmpc.so.2

whereis libgmp
libgmp: /usr/lib/libgmp.a /usr/lib/libgmp.lai /usr/local/lib/libgmp.so /usr/local/lib/libgmp.la /usr/local/lib/libgmp.a

I configured gcc with the following parameters: gcc-4.7.0-compiled# ../gcc-4.7.0/configure --build='sparc-linux' --enable-languages=c,c++ --prefix=/usr --mandir=/usr/s

Query regarding pointer analysis

Mukta Joglekar — 2012-05-23T10:16:28

Hello,

We are trying to find how pointer analysis information is being used
by other optimizations in gcc. We disovered that pointer information
is stored as a bitmap which is accessed via a macro named
"SSA_NAME_PTR_INFO". However, when we tried to find where this macro
is being used, we came up with following observations:

For the example given below:

int main()
{
         int *a,*b;

         int p,q,r;

         a = &r;

         *a = p + q;

         b = &p;

         *b = p + q;

         printf("%d,%d",*a,*b);

}

There is scope for copy propagation, and the program does get
optimized stating that *a should be equal to *b. Pass
"COPY_PROPAGATION" has a call to SSA_NAME_PTR_INFO wherein it
duplicates the points-to information in case of copy propagation.
However, for the example given above, this macro is not being called.
Here, we realized that the pointer dereferences are already converted
to scalar variables in the first execution of the pass "CONDITIONAL
CONSTANT PROPAGATION". However, this pass

cross gcc libgfortran mis-configuration

rbmj — 2012-05-22T03:51:14

Hi everyone,

I am working on getting libgfortran to cross compile targeting vxworks.  
However, I've noticed that it has been mis-configured.  Checking 
config.log, it appears that checks for function existence is succeeding 
because gcc thinks they are builtins.

My config.log is attached - line 2175 (for example) shows the issue.

This appears to be a problem with other functions as well.  For some 
reason, configure thinks that my cross gcc has functions like fp_trap, 
fp_enable, fp_setmask, umask, exec*

For another thing, I don't see how fork() can be a builtin, considering 
that there is no fork() in the libc and the vxworks process model 
doesn't exactly mesh with posix and forking...

Or maybe there's another issue.  Either way, these functions should 
*not* be working.

Any help is appreciated.  Thanks,

Robert Mason

Help compiling native gcc-4.7.0 on Solaris/x86

Shahbaz Javeed — 2012-05-21T21:45:23

Folks,

I've dug through the archives to see if my question is answered here
but haven't found anything.  I've been scouring Google for the past
few days and am coming to you for help after having exhausted the
resources at my disposal.  Without further ado, here's what I have:

My system:
SunOS archive 5.11 oi_151a i86pc i386 i86pc
isainfo -kv reports a 64bit OS: 64-bit amd64 kernel modules

System compiler:
gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802)

Libraries I'm using to compile gcc-4.7.0:
gmp-5.0.5
mpfr-3.0.1 (mpfr-3.1.0 crashed earlier than where I am)
mpc-0.9
binutils-2.22

I'm attempting to do a full bootstrap compilation so I can get rid of
the system compiler.  I've followed the instructions here:
http://stackoverflow.com/a/6228588 to setup and build gcc using the
libraries mentioned above.

I'm building as per gcc recommendations in a build directory parallel
to the gcc-4.7.0 sources.  My environment has the following variables:

ABI=long

and the configure command I used to kickstart this bu

-mx32 'unrecognized option'

Vincent Diepeveen — 2012-05-21T20:04:40

hi, i tried mx32 option, it doesn't know it. What did i do wrong?

diep< at >linux-ljxv:/home/213> gcc -o try64 tryp.c
diep< at >linux-ljxv:/home/213> gcc --version
gcc (GCC) 4.7.0
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There  
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
PURPOSE.

diep< at >linux-ljxv:/home/213> ./t64
bash: ./t64: No such file or directory
diep< at >linux-ljxv:/home/213> ./try64
p=8 bytes adress=0x7fffadd09104 size of long=8 int=4 bytes
diep< at >linux-ljxv:/home/213> gcc -mx32 -o try64 tryp.c
as: unrecognized option '--x32'
diep< at >linux-ljxv:/home/213> gcc -m32 -o try64 tryp.c
diep< at >linux-ljxv:/home/213> ./try64
p=4 bytes adress=0xffeef1a4 size of long=4 int=4 bytes
diep< at >linux-ljxv:/home/213> cat tryp.c
#include <stdio.h>

int main(void) {
   int *p,i[3] = {0,1,2};

   p = &i[1];
   printf("p=%d bytes adress=%p size of long=%d int=%i bytes\n",
          sizeof(p),p,sizeof(long),sizeof(int));
   return 0;
}
diep< at >lin

cine castiga

2012-05-21T19:04:27

http://www.youtube.com/watch?feature=youtu.be&hl=ro&v=_Sl3Ox7RMnE
 To unsubscribe please send email to unsubscribe< at >cc.psd-prahova.ro

Address rejected by TARGET_LEGITIMATE_ADDRESS_P recreated in post reload CSE pass at -O2

Ayonam Ray — 2012-05-21T19:13:53

Hi,

I have an address (symbolicRef + indexReg * scaleFactor) that is
rejected by my TARGET_LEGITIMATE_ADDRESS_P.  However, at -O2, the same
address gets recreated in the post reload CSE pass.  The symbolic
reference just after the reload is in a register and the address
"register + indexReg * scaleFactor" is a valid address for my
architecture.  The CSE figures out that the symbolic reference is in a
register (the notes say so) and replaces the "register + indexReg *
scaleFactor" address with "symbolicRef + indexReg * scaleFactor".

Is there a way to prevent this from happening?  Am I missing some
target definitions which is causing this?  Or is it an incorrect
predicate definition?

I get the failure in "movsi" when, after the post reload CSE, it tries
to match the constraints for that memory operand.  The 'm' constraint
ends up calling the TARGET_LEGITIMATE_ADDRESS_P which returns a zero
and the constraint check fails.

Thanks in advance.
Regards
Ayonam

Creating X32 ABI code with GCC?

Vincent Diepeveen — 2012-05-21T17:55:03

hi,

Kernel 3.4 supports X32 ABI.

see http://kernelnewbies.org/ 
Linux_3.4#head-039c9d273884c9639937c10d68b4a3214869eb4b

This could give fantastic speedups at x64 hardware as it combines the  
advantages of 64 bits
  programming, bunch of registers, with the advantage of still  
reusing the old codes 'signed integer' lookup
which right now slows down so much in x64 as it creates an extra sign  
extension for the lookup 32 bits signed
  value to 64 bits signed value.

Does GCC already support this and if so which options can i trigger  
this with GCC?

If so does this work at all x64 processors as well?

If i google i see a few postings about X32 'backported to GCC'  
attempt in 2011 somewhere, but no confirmation whatsoever.

Thanks,
Vincent

Partial registers in asm constraints/clobber lists

Jeremy Hall — 2012-05-21T09:00:35

Hi,

My question is this.
Is it safe to mention part of a register only in a constraint or clobber list?

Two examples:

    asm( "xor %%eax,%%eax" ::: "eax" );

This is fine for 32 bits, but in 64 bit mode, the upper half of rax is
zeroed.  So do I have to
give rax in the clobber list? (which means separate code for 32 and 64
versions which I'd prefer to avoid).

Secondly:

bool have_tsc( void )
{
  bool present;
  asm( "mov $1,%%eax;  cpuid;  test $16,%%edx;  setnz %0" : "=a"
(present) :: "ebx", "ecx", "edx" );
  return present;
}

Here only "al" is mentioned but of course "eax" is altered.  (of
course I could use "=q"
but it creates an extra mov, as the function will return the bool in "al").

Does gcc treat registers as a whole so that a mention of any part of a
register refers to all of it (e.g. register "a").

Thanks
Jeremy

problem with order of -lmylibrary flags.

Brendan Miller — 2012-05-20T23:16:03

I've found kind of a weird issue where if I indicate I want to link a
library with the -l flag too early on the command line, I get linker
errors.

Here's an example:
g++ -lml -lcvaux -lhighgui -lcv -lcxcore   -std=c++0x -Werror -Wall -g
-MMD -MP -Iinclude  -o objrec main.cpp

Here I'm linking a bunch of libraries, into a binary called objerec.
The source file is at the end. This command line produces linker
errors as if the libraries had not been linked properly.

However in this example everything is fine:
g++  -std=c++0x -Werror -Wall -g -MMD -MP -Iinclude  -o objrec
main.cpp -lml -lcvaux -lhighgui -lcv -lcxcore

The only difference is that I place the -l flags after the source file
(main.cpp) that I'm building.

Why does the second example compile while the first gets linker errors?

A more general question: in a make file is it better to list libraries
you want to link in the LDFLAGS variable, or in the LDLIBS variable?

Thanks,
Brendan Miller

Creating makefiles in gcc4.7.0

blessman11 — 2012-05-20T10:05:58


How do I create makefiles for gcc4.7.0 c++ projects? 
Has anybody got a link to an example of a "gcc4.7.0" c++11 project? And also
a tutorial to writing makefiles for the compiler? (I've looked at the
general documentation and it wasn't really clear enough and mostly feels a
bit like information overload when first looking at it)

Integral type with sizeof(T) == 1 and distinct aliasing class

Florian Weimer — 2012-05-20T09:45:29

Is there a type which is basically an (unsigned) char, but with the
additional feature that a pointer derived from it wouldn't alias with
basically anything?

This type would be handy for optimizing marshaling code.

lang.opt

Philip Herron — 2012-05-20T02:20:56

Hey

Trying to add option to my front-end thought lang.opt:

fpy-dump-dot
Python Var(gpy_set_dump_dot) Init(1)
dumps the pretty-printed DOT IL

But i keep Getting:

warning: command line option ‘-fpy-dump-dot’ is valid for Python but
not for  [enabled by default]

--Phil