<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help">
    <title>gmane.comp.gcc.help</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41634"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41633"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41632"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41631"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41630"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41629"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41628"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41627"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41626"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41625"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41624"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41623"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41622"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41621"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41620"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41618"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41617"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41616"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41615"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.help/41614"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41634">
    <title>COMPILER_PATH question</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41634</link>
    <description>&lt;pre&gt;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&lt;/pre&gt;</description>
    <dc:creator>Chih Wang</dc:creator>
    <dc:date>2012-05-25T23:08:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41633">
    <title>memory overhead of static const char?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41633</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Erik Rull</dc:creator>
    <dc:date>2012-05-25T20:45:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41632">
    <title>Re: Integral type with sizeof(T) == 1 and distinct aliasing class</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41632</link>
    <description>&lt;pre&gt;
is it possible to use one of those GCC type mode extensions to
typedef int with mode saying it has 8-bit and use that?

&lt;/pre&gt;</description>
    <dc:creator>Gabriel Dos Reis</dc:creator>
    <dc:date>2012-05-25T20:40:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41631">
    <title>Re: Integral type with sizeof(T) == 1 and distinct aliasing class</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41631</link>
    <description>&lt;pre&gt;* Ian Lance Taylor:


It turns out that I can't get GCC to eliminate redundant bounds
checks, no matter what the type is.  I guess I have to do this in a
library after all, using template metaprogramming.

&lt;/pre&gt;</description>
    <dc:creator>Florian Weimer</dc:creator>
    <dc:date>2012-05-25T20:01:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41630">
    <title>Re: compile gcc and library</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41630</link>
    <description>&lt;pre&gt;

Not usually. Very old versions of gcc were often written in semi-broken
nonstandard C.

Andrew.

&lt;/pre&gt;</description>
    <dc:creator>Andrew Haley</dc:creator>
    <dc:date>2012-05-25T15:28:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41629">
    <title>Re: compile gcc and library</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41629</link>
    <description>&lt;pre&gt;I thought the minimum compiler requirements for the bootstrap compiler
where very limited.
Isn't it even backwards compatible for one version? (ie. you can use
version X
to build X-1, then X-1 to build X-2...)

As for the actual problem of getting a 3.4 gcc, you may have better luck
making
the binary from some archive like
http://ge.archive.ubuntu.com/ubuntu/pool/universe/g/gcc-3.4/
to work.


&lt;/pre&gt;</description>
    <dc:creator>Ángel González</dc:creator>
    <dc:date>2012-05-25T15:22:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41628">
    <title>Re: Why is fixincludes not doing anything?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41628</link>
    <description>&lt;pre&gt;
Maybe that's the error:

./gcc/xgcc -print-sysroot-headers-suffix
xgcc: fatal error: not configured with sysroot headers suffix

xgcc is the compiler in question right?  . is the build directory.  I 
believe xgcc is the compiler that compiles all of the cross targets (lib*).

My configure call was:

../gcc-4.7.0/configure --prefix=/usr --target=powerpc-wrs-vxworks 
--with-gnu-as --with-gnu-ld 
--with-headers=../gccdist/WindRiver/vxworks-6.3/target/h 
--disable-shared --disable-libssp --disable-multilib --with-float=hard 
--enable-languages=c,c++ --enable-threads=vxworks --without-gconv 
--disable-libgomp --disable-nls --disable-libmudflap --with-cpu-PPC603

I don't use --with-sysroot; I use --with-headers.  So do I need to use a 
different configuration?  And how can I achieve the same effect using 
--with-sysroot as I did with --with-headers if that *is* the issue.

Thanks!

Robert Mason

&lt;/pre&gt;</description>
    <dc:creator>rbmj</dc:creator>
    <dc:date>2012-05-25T14:23:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41627">
    <title>Re: How to define special requirements for an address operand?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41627</link>
    <description>&lt;pre&gt;
What will happen if a frame pointer is needed? Is GCC supposed to work with
such a limited hardware at all?


&lt;/pre&gt;</description>
    <dc:creator>Georg-Johann Lay</dc:creator>
    <dc:date>2012-05-25T14:17:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41626">
    <title>Re: How to define special requirements for an address operand?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41626</link>
    <description>&lt;pre&gt;


That target sounds insane.

I think it is going to be quite difficult to get GCC to generate
efficient code with this restriction.  GCC has a basic concept of a
memory address.  It does not separate memory addresses into readable
addresses and writable addresses.  If you write code like a[i]++ GCC is
going to use a single pseudo-register to hold the address to read and
write.  I would not know how to begin fixing that.

Setting aside efficiency considerations, the easy way is going to be to
ignore the write register, and change all your insns that write to
memory to first move the value from the read register to the write
register before doing the actual write.

Ian

&lt;/pre&gt;</description>
    <dc:creator>Ian Lance Taylor</dc:creator>
    <dc:date>2012-05-25T14:02:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41625">
    <title>Re: Why is fixincludes not doing anything? (was: Re: Fixincludes permanence &amp; questions on cross compilers)</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41625</link>
    <description>&lt;pre&gt;

In your specific case, I don't know.  But it is possible for a target to
disable fixincludes by setting STMP_FIXINC in a config/CPU/t-XXX file.
Or, since this is a cross-compiler, GCC may simply be confused about
where to find the header files that it is supposed to fix.  Normally
those header files will be found in the directory printed by gcc
-print-sysroot-headers-suffix.  What does that print for you?  Did you
configure GCC with the right --with-sysroot option?

Ian


&lt;/pre&gt;</description>
    <dc:creator>Ian Lance Taylor</dc:creator>
    <dc:date>2012-05-25T13:59:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41624">
    <title>Re: Effect of 'register' keyword on debug info</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41624</link>
    <description>&lt;pre&gt;

I don't know.


That is a good question.  Right now -fvar-tracking is turned on by
default at -O1.  I guess the assumption was that at -O0 variables
wouldn't wind up in the same register.


Yes.

Ian

&lt;/pre&gt;</description>
    <dc:creator>Ian Lance Taylor</dc:creator>
    <dc:date>2012-05-25T13:11:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41623">
    <title>How to define special requirements for an address operand?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41623</link>
    <description>&lt;pre&gt;Hi,
I'am trying to write a backend for my own target system.
The target has two pointer registers but only one of them can be used to read data from memory and the other one to write data into memory.

How could i tell the compiler to use the correct register for the respective operation?

I have tried to copy the address into the correct register in the define_expand "mov&amp;lt;mode&amp;gt;", but this seems to confuse the compiler and not working always.
I also tried to describe it in the target hook TARGET_LEGITIMATE_ADDRESS_P, but there i have no idea how to find out which operation is performed (write/read).

Thanks in advance.

best regards,
Andreas


&lt;/pre&gt;</description>
    <dc:creator>Setjem Setjem</dc:creator>
    <dc:date>2012-05-25T12:11:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41622">
    <title>Why is fixincludes not doing anything? (was: Re: Fixincludes permanence &amp; questions on cross compilers)</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41622</link>
    <description>&lt;pre&gt;
Refine my question: anyone know why fixincludes does not appear to be 
doing *anything*?  I can't seem to find any fixed headers anywhere in 
GCC's build tree.  And the compile keeps failing...

Thanks,

Robert Mason

&lt;/pre&gt;</description>
    <dc:creator>rbmj</dc:creator>
    <dc:date>2012-05-25T12:08:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41621">
    <title>Re: compile gcc and library</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41621</link>
    <description>&lt;pre&gt;
This is going to be tricky.  Older versions of gc generally don't
compile with newer versions, and you'll have to do some fixing
up.

Andrew.


&lt;/pre&gt;</description>
    <dc:creator>Andrew Haley</dc:creator>
    <dc:date>2012-05-25T08:30:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41620">
    <title>Re: Effect of 'register' keyword on debug info</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41620</link>
    <description>&lt;pre&gt;
Further, by default the debug info for variables 'd1' and 'f1' are
generated as location expressions. Where as with '-fvar-tracking', the
debug info is generated as location lists.

1) Is it possible to generate location expressions to identify that
the variable has been optimized out?
2) If (1) is not possible and if '-fvar-tracking' gives accurate info
on live variables, why isn't it turned ON by default at '-O0'?

Since the code is compiled at '-O0' should correct debug info be generated?

Thanks for the help,
Rohit

&lt;/pre&gt;</description>
    <dc:creator>Rohit Arul Raj</dc:creator>
    <dc:date>2012-05-25T08:07:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41618">
    <title>Re: Unexpected compiler error ( error: template argument 1 is invalid ) when using &lt;limits&gt; and using -m32 option on 64-bit system.</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41618</link>
    <description>&lt;pre&gt;Thank you for the very useful and detailed reply :)

On 24 May 2012 20:43, Ángel González &amp;lt;keisial&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

Thanks for pointing that out.


Thanks for the tip. I've installed the gcc-multilib package and
everything works fine now.


&lt;/pre&gt;</description>
    <dc:creator>Delcypher</dc:creator>
    <dc:date>2012-05-24T19:59:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41617">
    <title>Re: Unexpected compiler error ( error: template argument 1 is invalid ) when using &lt;limits&gt; and using -m32 option on 64-bit system.</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41617</link>
    <description>&lt;pre&gt;
You seem to be using a 64bit-only compiler:

I'd have expected it to reject the -m32 switch in such case, but it's
probably the issue.
For Arch Linux I think you should install the gcc-multilib package.

Probably as consequence of not being, a multilib compiler, it is reading
the bits files from
/usr/include/c++/4.7.0/x86_64-unknown-linux-gnu/bits (which would be 64
bits)
instead of /usr/include/c++/4.7.0/x86_64-unknown-linux-gnu/32/bits
There's only a few differences in my system between both folders, some
#define in c++config.h,
but they seem to make the difference.

The error limits:1405:35: error: template argument 1 is invalid comes
from this excerpt:

One of the different defines is precisely _GLIBCXX_USE_INT128 not being
defined in 32bit folder.

So, you don't have multilib compiler properly setup, in -m32 it doesn't
have __int128 type, but
as it's using the wrong config, it is trying nonetheless to use it,
which produces your error.

You should be able to bypass it with -D__STRICT_ANSI__, but then i&lt;/pre&gt;</description>
    <dc:creator>Ángel González</dc:creator>
    <dc:date>2012-05-24T19:43:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41616">
    <title>Re: compile gcc and library</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41616</link>
    <description>&lt;pre&gt;

A C library inherently has lots of system dependencies, like how to do
I/O on the system.  It's easier to maintain that separately from the
compiler.

A C++ library does not have those dependencies, because it can simply
use the facilities of the C library.  Also, a C++ library has some close
ties to the compiler, e.g., in how exceptions are implemented and
details of things like __is_pod.

Also and probably more importantly, historically GCC was developed on
systems that have C libraries but don't have C++ libraries.  So GCC
always needed to provide a C++ library, but rarely needed to provide a C
one.


That is one, yes.  In general the C++ ABI is much more complex and
subtle than the C ABI, and there is a correspondingly higher chance of
some sort of breakage.  That said, it usually does work fine.

Ian

&lt;/pre&gt;</description>
    <dc:creator>Ian Lance Taylor</dc:creator>
    <dc:date>2012-05-24T19:17:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41615">
    <title>Re: Unexpected compiler error ( error: template argument 1 is invalid ) when using &lt;limits&gt; and using -m32 option on 64-bit system.</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41615</link>
    <description>&lt;pre&gt;error: template argument 1 is invalid
error: template argument 1 is invalid
Perhaps it is an issue with my distribution then. Are you using Arch
Linux on a 64-bit system?

I have the output of running
$ g++ -v -m32 limits.cpp

here: http://pastebin.com/JRJcVDX2

It is showing some header mismatch issues but I do not know if it is
related to my issue.

Any ideas what might be wrong?

&lt;/pre&gt;</description>
    <dc:creator>Dan Liew</dc:creator>
    <dc:date>2012-05-24T18:47:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41614">
    <title>Re: compile gcc and library</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41614</link>
    <description>&lt;pre&gt;
This is the reason why gcc contains a c++ library, but no need for C
library ? what kind of caveats , like different mangling styles ?


&lt;/pre&gt;</description>
    <dc:creator>Xin Tong</dc:creator>
    <dc:date>2012-05-24T18:10:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.help/41613">
    <title>Re: compile gcc and library</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.help/41613</link>
    <description>&lt;pre&gt;

Yes.


GCC includes the C++ library, libstdc++, but it does not include a C
library.


In general, yes.  For pure C code, yes.  For C++ code, some caveats may
apply.

Ian

&lt;/pre&gt;</description>
    <dc:creator>Ian Lance Taylor</dc:creator>
    <dc:date>2012-05-24T17:58:10</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gcc.help">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gcc.help</link>
  </textinput>
</rdf:RDF>

