<?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://blog.gmane.org/gmane.comp.gcc.help">
    <title>gmane.comp.gcc.help</title>
    <link>http://blog.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://comments.gmane.org/gmane.comp.gcc.help/44773"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44763"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44762"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44759"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44755"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44754"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44751"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44749"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44733"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44732"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44724"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44723"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44716"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44715"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44705"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44704"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44701"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44699"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44689"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.help/44685"/>
      </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://comments.gmane.org/gmane.comp.gcc.help/44773">
    <title>Trouble building AR</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44773</link>
    <description>&lt;pre&gt;Hi,
I'm having trouble building GCC. I've decompressed GCC 4.7.2 source
into a directory and binutils 2.21.1 into a directory in parallel with
symbolic links to all subdirectories. I ran the contrib script to get
all other dependencies and then ran GCC's configure in a parallel
directory, following all installation instructions. It builds just
fine but when I install it AR seems to be missing. Any idea what
happened to it and how to get it?

Looks like it's supposed to be built with binutils and I'm getting
other tools from it like LD just not that one. There is a program
called gcc-ar that seems to exist but not sure if it's the same tool?
It may appear if I build binutils by itself but I'm trying to build
them together so that I can get -flto optimization to work, as
apparently GCC balks at using the linker plugin if they weren't built
together.

Thanks!

&lt;/pre&gt;</description>
    <dc:creator>Uri Moszkowicz</dc:creator>
    <dc:date>2013-06-18T20:07:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44763">
    <title>-Wold-style-casts and system headers</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44763</link>
    <description>&lt;pre&gt;
Greetings.

I'm using -Wold-style-casts on my project, and I've found that I get
warnings in my code when certain macros are expanded.

These macros are defined in headers under /usr/include; my reading of
the manual is that these ought to get some immunity from some
warnings:

  "Macros defined in a system header are immune to a few warnings
  wherever they are expanded. This immunity is granted on an ad-hoc
  basis, when we find that a warning generates lots of false positives
  because of code in macros defined in system headers."
  -- http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html

But it seems there is some degree of judgment ("ad-hoc basis")
involved -- it's not clear whether that's regarding the header files,
individual macros, or individual warnings.

The case I hit today was from zlib.h, which has the following macro
definition:

  #define deflateInit(strm, level) \
          deflateInit_((strm), (level), ZLIB_VERSION, (int)sizeof(z_stream))

When expanded into my sample code:

  // https://gist.github.com/tkil/5806218

  #include &amp;lt;string.h&amp;gt;
  #include &amp;lt;zlib.h&amp;gt;

  int main()
  {
      z_stream_s strm;
      memset( &amp;amp;strm, 0, sizeof( strm ) );
      const int rc = deflateInit( &amp;amp;strm, Z_DEFAULT_COMPRESSION );
      return rc;
  }

I got:

  $ g++ -Wold-style-cast -o g++-warnings-check g++-warnings-check.cpp -lz
  g++-warnings-check.cpp: In function ‘int main()’:
  g++-warnings-check.cpp:49:20: warning: use of old-style cast [-Wold-style-cast]

A few months ago, I ran into this &amp;lt;sys/select.h&amp;gt; as well; in that
case, I could easily enough rewrite the needed operations for private
use, so I did so.

I'm aware that I can disable that warning for the single file, or even
for a single region in the file using pragmas, but I would like to
understand why g++ isn't applying the "system header" rule to that
macro.

Best regards,
Anthony Foiani

&lt;/pre&gt;</description>
    <dc:creator>Anthony Foiani</dc:creator>
    <dc:date>2013-06-18T16:14:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44762">
    <title>if-conversion passes</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44762</link>
    <description>&lt;pre&gt;Hello all

Can someone please specify the pass related to if-conversion optimization?

Best regards

Abdul

&lt;/pre&gt;</description>
    <dc:creator>Abdul Wahid Memon</dc:creator>
    <dc:date>2013-06-18T15:30:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44759">
    <title>Function Parameters vs. Prologue (fastcall + O1 + -fschedule-insns2)</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44759</link>
    <description>&lt;pre&gt;Hi,

I'm curious about what is causing this reordering (prologue with the
function parameters):

# gcc structs.c -o structs -m32 -O1 -fschedule-insns2

(gdb) disas main
Dump of assembler code for function main:
   0x0804868c &amp;lt;+0&amp;gt;: push   %ebp
   0x0804868d &amp;lt;+1&amp;gt;: mov    $0x3,%edx
   0x08048692 &amp;lt;+6&amp;gt;: mov    %esp,%ebp
   0x08048694 &amp;lt;+8&amp;gt;: mov    $0x2,%ecx
   0x08048699 &amp;lt;+13&amp;gt;: and    $0xfffffff0,%esp
   0x0804869c &amp;lt;+16&amp;gt;: call   0x804845c &amp;lt;funcao&amp;gt;


The code:

__attribute__((fastcall)) void funcao(int i, int a) {
...
int main() {

        int i, a;
        i = 2;
        i = 3;

        funcao(i, a);
...


When I remove one of them (fastcall or schedule-insns2), the binary is
generated in logic order:

(gdb) disas main
Dump of assembler code for function main:
   0x08048340 &amp;lt;+0&amp;gt;: push   %ebp
   0x08048341 &amp;lt;+1&amp;gt;: mov    %esp,%ebp
   0x08048343 &amp;lt;+3&amp;gt;: and    $0xfffffff0,%esp
   0x08048346 &amp;lt;+6&amp;gt;: sub    $0x10,%esp
   0x08048349 &amp;lt;+9&amp;gt;: movl   $0x3,0x4(%esp)
   0x08048351 &amp;lt;+17&amp;gt;: movl   $0x2,(%esp)
   0x08048358 &amp;lt;+24&amp;gt;: call   0x8048450 &amp;lt;funcao&amp;gt;

... or

(gdb) disas main
Dump of assembler code for function main:
   0x0804868c &amp;lt;+0&amp;gt;: push   %ebp
   0x0804868d &amp;lt;+1&amp;gt;: mov    %esp,%ebp
   0x0804868f &amp;lt;+3&amp;gt;: and    $0xfffffff0,%esp
   0x08048692 &amp;lt;+6&amp;gt;: mov    $0x3,%edx
   0x08048697 &amp;lt;+11&amp;gt;: mov    $0x2,%ecx
   0x0804869c &amp;lt;+16&amp;gt;: call   0x804845c &amp;lt;funcao&amp;gt;

Someone knows something about the combined use of the fastcall
attribute and schedule-insns2 option? Is there an issue?

Regards.

Geyslan Gregório Bem

http://hackingbits.com
&amp;lt; at &amp;gt;geyslangb
br.linkedin.com/in/geyslan

&lt;/pre&gt;</description>
    <dc:creator>Geyslan Gregório Bem</dc:creator>
    <dc:date>2013-06-18T14:24:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44755">
    <title>-femit-struct-debug-reduced/baseonly debug info</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44755</link>
    <description>&lt;pre&gt;Hi!

I'm trying to reduce the amount of debug info in my binaries.

What kind of debug info will I loose in case of using -femit-struct-debug-reduced or -femit-struct-debug-baseonly?
And what is still available?

/*
With optimism,
Evgeny Gavrin

email : evgeny.gavrin&amp;lt; at &amp;gt;hotmail.com
*/       
&lt;/pre&gt;</description>
    <dc:creator>Evgeny Gavrin</dc:creator>
    <dc:date>2013-06-18T11:40:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44754">
    <title>static library unresolved symbols</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44754</link>
    <description>&lt;pre&gt;I'm inspecting a static library with nm, and I see that the tool 
provides me with the unresolved symbols of a file foo.o even though 
those symbols are defined in file zoo.o and both are included in the 
static library (ar rcs libmy.a zoo.o foo.o).

How can I ask nm to resolve these symbols if they can be found within 
the files of the archive and just report me about the other not resolved?
Thanks
R

&lt;/pre&gt;</description>
    <dc:creator>Riccardo Manfrin</dc:creator>
    <dc:date>2013-06-18T10:40:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44751">
    <title>Authoritative answer wanted: "-g -O1" vs. "-O1"</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44751</link>
    <description>&lt;pre&gt;If I compile my embedded program with options "-g -O1" I obtain an elf 
file with debug information. I can objcopy the elf file to a binary or 
hex file that can be loaded to flash, effectively striping out the debug 
information leaving only the optimized code in ROM.

But if I re-build with options the same except omit the -g option, 
obviously I will have no symbols in the elf file making debugging 
impossible or at least more difficult. However, when I object copy this 
elf to a binary or hex file they are different somewhat than the binary 
or hex produced with options -g present. At least with 4.7.3 the main 
difference, as seen with objdump, is in the prologue to certain function 
calls with only a few bytes different in total code length on a fairly 
large embedded application (arm). So -g has some effect on the actual 
code produced it appears.

Is this difference expected? Should -g cause changes in the actual code 
generated and not just add debug symbols to the elf? Possibly it is 
related to the optimization level? I have not checked to see if the 
results differ with higher or lower levels than -O1.

I have seen several opinions regarding this but no authoritative answer. 
The gcc manual also does not really answer this.


Thanks,
-gene










&lt;/pre&gt;</description>
    <dc:creator>Gene Smith</dc:creator>
    <dc:date>2013-06-18T05:21:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44749">
    <title>designated initializers extension and sparc</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44749</link>
    <description>&lt;pre&gt;I tried to ask in gcc and was redirected here.

So, I've read the spec about extension

The `[index]' or `.fieldname' is known as a designator. You can also
use a designator (or the obsolete colon syntax) when initializing a
union, to specify which element of the union should be used. For
example,
      union foo { int i; double d; };
      union foo f = { .d = 4 };
will convert 4 to a double to store it in the union using the second
element. By contrast, casting 4 to type union foo would store it
into the union as the integer i, since it is an integer. (See Cast
to Union.)

and wrote the following test:

union foo { int i; double d; };

int main(int argc, char **argv)
{
     union foo f = { .d = 4 };

     ASSERT_EQ(0, f.i);
     ASSERT_FEQ(4.0, f.d);

     return 0;
}

ASSERT_EQ and ASSERT_FEQ are some macros which checks the value and
gives some error messages.

But it fails on sparc. I guess int should be equal 0x40100000 since bytes are in reverse order.
As I know now, this extension is not bi-endian.
So the question is: what shall I do? Does it mean that I just shall forget about that extension usage on sparc?

Sergey


&lt;/pre&gt;</description>
    <dc:creator>Sergey Kljopov</dc:creator>
    <dc:date>2013-06-17T11:21:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44733">
    <title>GCC 4.8.1 building fails</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44733</link>
    <description>&lt;pre&gt;Hello,
I've tried to build GCC 4.8.1 numerous times without any luck.
Build, host, and target system: i686-pc-mingw32.
I'm using MinGW Shell, gcc -v 4.6.2 ; g++ -v 4.7.2
Configure goes fine, then building starts: it builds all required
libraries and other built-in libraries, and ./gcc folder. Then it
starts to build ./i686-pc-mingw32/libgcc folder, and that's when it
crashes.


Configure: ../gcc-*/configure --enable-languages=c,c++
Make: make

Every time I got to this point, shell showed following error:
checking how to run the C preprocessor... /lib/cpp
configure: error: in `/y/Downloads/gcc481d/i686-pc-mingw32/libgcc`
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log` for more details.
make[2]: *** [configure-stage1-target-libgcc] Error1
make[2]: Leaving directory /y/Downloads/gcc481d
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory /y/Downloads/gcc481d
make: *** [all] Error 2

I've attached config.log.

Any ideas how to fix this?
Thanks.
&lt;/pre&gt;</description>
    <dc:creator>Ignas</dc:creator>
    <dc:date>2013-06-14T09:31:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44732">
    <title>G++ refuses to compile simple, looking good code</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44732</link>
    <description>&lt;pre&gt;Hi,
i'm not a c++/template guru and i can't decide if this is really a
valid code or i have encountered a gcc bug:

------------------------------
template &amp;lt;class T&amp;gt; struct A {
  void *p;
};
template &amp;lt;class T&amp;gt; struct B : A&amp;lt;T&amp;gt; {
  void *foo() { return p; }
};
------------------------------

g++ says "error: 'p' was not declared in this scope".
microsoft's compiler is happy with the same code.

Can anyone help?

&lt;/pre&gt;</description>
    <dc:creator>Luchezar Belev</dc:creator>
    <dc:date>2013-06-14T09:30:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44724">
    <title>Does gcc hoist memory-reference based loop invariant?</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44724</link>
    <description>&lt;pre&gt;Hi there,

For the below simple case, I think poly1[i] should be hoisted to
outermost loop to avoid loading from innermost loop at each iteration.
But for arm-none-eabi target like cortex-m4, gcc fails to do so. Is
this a normal case or a missing optimization? Please advise.

void
PolyMul (float *poly1, unsigned int n1,
         float *poly2, unsigned int n2,
         float *polymul, unsigned int *nmul)
{
      unsigned int i, j;

         for (i = 0; i &amp;lt;= n1; i++)
   for (j = 0; j &amp;lt;= n2; j++)
      polymul[i+j] += poly1[i] * poly2[j];
}

Thanks.

BR,
Terry

&lt;/pre&gt;</description>
    <dc:creator>Terry Guo</dc:creator>
    <dc:date>2013-06-13T10:13:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44723">
    <title>gcc Cortex M4 bug ?</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44723</link>
    <description>&lt;pre&gt;Hi,
Im trying to implement a dynamic linker for M4 mcu's.
But the generated code from gcc seems incorrect to me: im compiling using
arm-none-eabi-gcc: -mcpu=cortex-m4 -mthumb -O2 -ggdb  -Wstrict-prototypes 
-Wunused-parameter -lmylib main.c -o test

Ive created the following program dynamically linked:
----main.c---------
int main()
{
        test();
        return 1;
}

On target I have the function
-------mylib.c-----------
int test()
{
        return 1;
}
arm-none-eabi-gcc -fPIC -mcpu=cortex-m4 -mthumb -O2 -ggdb 
-Wstrict-prototypes -Wunused-parameter -lmylib mylib.c -o mylib.so

------linker script-----
OUTPUT_FORMAT("elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)

PHDRS
{
        headers PT_PHDR PHDRS ;
        interp PT_INTERP ;
        text PT_LOAD FILEHDR PHDRS ;
        data PT_LOAD ;
        got PT_LOAD;
        dynamic PT_DYNAMIC ;
}

SECTIONS
{
        . = SIZEOF_HEADERS;
        .interp : { *(.interp) } :text :interp
        .hash           : { *(.hash) }
        .text : { *(.text) } :text
        .rodata : { *(.rodata) } /* defaults to :text */
        .dynsym         : { *(.dynsym) }
        .dynstr         : { *(.dynstr) }
        .rel.dyn        :
    {
      *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
      *(.rel.got)
    }
        .rela.dyn       :
    {
      *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
      *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
      *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
      *(.rela.got)
    }
        .rel.plt        :
    {
      *(.rel.plt)
    }
        .rela.plt       :
    {
      *(.rela.plt)
    }
  .init_array     :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array))
    PROVIDE_HIDDEN (__init_array_end = .);
  }
  .fini_array     :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array))
    PROVIDE_HIDDEN (__fini_array_end = .);
  }
  .jcr            : { KEEP (*(.jcr)) }

        .init           :
        {
                KEEP (*(.init))
        } =0
 .plt            :  { *(.plt) }
        .dynamic : { *(.dynamic) } :data :dynamic
        .got            : { *(.got.plt) *(.igot.plt) *(.got) *(.igot) } 
:got
        .data : { *(.data) } :data
}

the machine generated code for main looks as follows (objdump -D):

0000015c &amp;lt;main&amp;gt;:
 15c:   b508            push    {r3, lr}
 15e:   f000 e888       blx     270 &amp;lt;__libc_fini_array+0xfc&amp;gt;
 162:   2001            movs    r0, #1
 164:   bd08            pop     {r3, pc}
 166:   bf00            nop


instruction at  15e:   seems incorrect to me, since M4 only branches using 
a register   blx{cond} Rm, (M3 seems to be ok with label aswell.)

Anyone who can tell me what is wrong and if there is a workaround for this 
?

Ive tried to use -mlong-calls, and it produces:

00000164 &amp;lt;main&amp;gt;:
 164:   b508            push    {r3, lr}
 166:   f240 237c       movw    r3, #636        ; 0x27c
 16a:   f2c0 0300       movt    r3, #0
 16e:   4798            blx     r3
 170:   2001            movs    r0, #1
 172:   bd08            pop     {r3, pc}


This looks OK except for the address in R3 not being rellative, since it's 
absolute it's not correct either (or am I missing something)



BR
Matias

&lt;/pre&gt;</description>
    <dc:creator>matti h</dc:creator>
    <dc:date>2013-06-13T09:25:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44716">
    <title>Basic Block info in DWARF line number table</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44716</link>
    <description>&lt;pre&gt;Hello,

From DWARF standard I read that basic block info can also be stored in
DWARF line number tables so that a DWARF consumer can match basic
blocks with the machine code addresses. And I found in gcc 3.x there
is an option "-a" to support output basic block information. However,
in gcc 4.x this option is no longer available and I cannot find any
basic lock info in line number tables through dwarfdump. Do gcc still
record this information? What command line option is needed to enable
this?

Thanks,
Yue Liu

&lt;/pre&gt;</description>
    <dc:creator>Yuë Liu</dc:creator>
    <dc:date>2013-06-13T00:07:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44715">
    <title>trouble building 4.7.2 w/binutils 2.23.1</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44715</link>
    <description>&lt;pre&gt;Hi,
I'm trying to build GCC 4.7.2 with binutils 2.23.1 and am getting a
compile error:

dwarf.o: In function `get_TAG_name':
/w/umoszkow/gcc/x86_64/binutils/../../gcc-4.7.2/binutils/dwarf.c:662:
undefined reference to `get_DW_TAG_name'
dwarf.o: In function `get_FORM_name':
/w/umoszkow/gcc/x86_64/binutils/../../gcc-4.7.2/binutils/dwarf.c:678:
undefined reference to `get_DW_FORM_name'
dwarf.o: In function `get_AT_name':
/w/umoszkow/gcc/x86_64/binutils/../../gcc-4.7.2/binutils/dwarf.c:1867:
undefined reference to `get_DW_AT_name'
collect2: error: ld returned 1 exit status

Any idea how to get around this build problem? My arch is x86_64 and
my OS is RHEL4u8WS.

Thanks!

&lt;/pre&gt;</description>
    <dc:creator>Uri Moszkowicz</dc:creator>
    <dc:date>2013-06-12T20:52:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44705">
    <title>-flto making program slower?</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44705</link>
    <description>&lt;pre&gt;Hi,
I'm having trouble with link time optimization in my application. It
is a large application that uses only basic C++ (no exceptions, no
templates, no STL, no floating point, etc). Like many applications,
the source files are compiled separately into object files. Some of
those are combined into shared libraries. The shared libraries are
then statically linked with the remaining object files to produce the
final application, which is about 100MB big. We are using GCC 4.7.2
with a non-GOLD 2.23.1 binutils.

I simply added "-flto" to the GCC command to create object files:
    g++ -Wall -pipe -O3 -flto -fno-strict-aliasing -mtune=generic
--no-exceptions -fPIC -c some.cc

I then added "-flto" to the final link command but not the shared libraries:
  g++ -o exec -Xlinker some1.o some2.o -static some1.a some2.a
-Wl,--wrap,open -flto

I ran a benchmark of tests and the resulting execution time is now
about 7% higher than it was without "-flto" added. Any suggestions for
how to improve this result or why it may have gotten slower?

If it helps, when I add "-fuse-linker-plugin" I get this error:
  g++: error: -fuse-linker-plugin is not supported in this configuration

Thanks!

&lt;/pre&gt;</description>
    <dc:creator>Uri Moszkowicz</dc:creator>
    <dc:date>2013-06-11T21:48:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44704">
    <title>link issue for libc stubs</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44704</link>
    <description>&lt;pre&gt;Hi list,
I use gcc 4.8.1 + newlib on a cortex-m3. I'm trying to link my app with 
libc and a library "libtlc.a" that I created out of a bunch of object 
files (init.o, tlc.o, cpu.o) as follows:

arm-none-eabi-ar rcs build/libtlc.a build/core_cm3.o build/cpu.o 
build/startup.o build/init.o build/tlc.o

Within tlc.o I have  the stubs implementation for _exit _sbrk ...
I can see the assembly with objdump ether in the .o and in the libtlc.a 
library.

I try linking with this command

arm-none-eabi-g++  -W -Wall -mcpu=cortex-m3 -mthumb -march=armv7-m 
-nostartfiles  -Wl,-Map=maketest.map  -Wl,-Tlinkerscript.ld main.o -lc 
-lstdc++ -lgcc -ltlc -o maketest.elf

but fail with these errors

... abort.c:63: undefined reference to `_exit' (same error for _sbrk, 
_getpid and _kill).

On the contrary, if I use the object file "tlc.o" in the linking phase, 
I'm able to produce the elf app:

arm-none-eabi-g++  -W -Wall -mcpu=cortex-m3 -mthumb -march=armv7-m 
-nostartfiles  -Wl,-Map=maketest.map  -Wl,-Tlinkerscript.ld main.o 
tlc.o  -lc -lstdc++ -lgcc -ltlc -o maketest.elf

What is the difference? The functions defs are in either tlc.o as well 
as in libtlc.o, but I'm able to produce the binary app only with the 
object file, not with the library.

Thanks,
RM

&lt;/pre&gt;</description>
    <dc:creator>Riccardo Manfrin</dc:creator>
    <dc:date>2013-06-11T21:36:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44701">
    <title>dynamic_cast from a const class</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44701</link>
    <description>&lt;pre&gt;Hello,

Does the below code look like valid C++, or is it a G++ bug?  5.2.7 has

&amp;lt;...&amp;gt;
The dynamic_cast operator shall not cast away constness (5.2.11).

The other compilers I could check quickly (clang, icc, msvc) all reject the 
code, GCCs 3.3, 4.6, 4.7 and 4.8 accept the code.

Andrey


class A {
};

class B : public A {
};

int main() {
   A* a;
   B* b = new B();
   a = dynamic_cast&amp;lt;const A*&amp;gt;(b);
   return 0;
}

&lt;/pre&gt;</description>
    <dc:creator>Andrey Belevantsev</dc:creator>
    <dc:date>2013-06-11T11:30:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44699">
    <title>aprovechas las mejores ofertas</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44699</link>
    <description>&lt;pre&gt;si te gusta la fortuna de san carlos.

dale me gusta a nuestro sitio en fb

https://www.facebook.com/fortunacostarica?ref=tn_tnmn

 &amp;lt;https://www.facebook.com/fortunacostarica?ref=nf&amp;gt;

La Fortuna Costa Rica &amp;lt;https://www.facebook.com/fortunacostarica&amp;gt;

aqui estaremos publicando las mejores ofertas, tal como la que
publicamos en nuestro muro, 
oferta del Hotel Linda Vista
 
a precio super rebajado
 
gracias



Esta correspondencia no contiene fines de venta directa. Nuestro deseo es
mantenerle informado sobre los movimientos,
servicios y oportunidades que se brindan para su crecimiento profesional y
personal. Si usted est&lt;/pre&gt;</description>
    <dc:creator>info&lt; at &gt;ticosviajando.com</dc:creator>
    <dc:date>2013-06-11T01:00:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44689">
    <title>Thumb inline assembly</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44689</link>
    <description>&lt;pre&gt;Hi,
 I'm trying to do a simple register read through ARM inline assembly.
If I embed the asm in the function directly, it works ...


eg:

#define BAD 0xBAADBAAD
#define GOOD 0x600D600D
#define RESET 0x00000000

#define NVIC_ISER0 0xE000E100

volatile int nvic_iser_status = 0xFFFFFFFF;

function () {


...

asm volatile(
"ldr r2, =8   /* number of register */ \n\t"
"ldr r1, =%0 /* load the nvic_iser* register */ \n\t"
"read_nvic_iser:\n\t"
"sub r2, r2, #1\n\t"
"ldr r0, [r1]\n\t"
"add r1, r1, #4 /* go to the next register */ \n\t"
"cmp r0, %1\n\t"
"beq read_nvic_iser_ok\n\t"
"ldr r3, =%2\n\t"
"str r3, [%4] /* update status flag */\n\t"
"read_nvic_iser_ok:\n\t"
"cmp r2, #0\n\t"
"bne read_nvic_iser\n\t"
"ldr r3, =%3\n\t"
"str r3, [%4] /* update status flag */\n\t"
:
: "i" (NVIC_ISER0), "i" (RESET), "i" (BAD), "i" (GOOD), "r" (&amp;amp;nvic_iser_status)
: "r0", "r1", "r2", "r3"
);

..

}

But, if I want to call the asm through another function, I get errors ..

eg: function (){

 ...
reg_read(NVIC_ISER0, RESET, nvic_iser_status)

..
}

reg_read(int addr, int reset, int status){

asm volatile(
"ldr r2, =8   /* number of register */ \n\t"
"ldr r1, =%0 /* load the nvic_iser* register */ \n\t"
"read_reg:\n\t"
"sub r2, r2, #1\n\t"
"ldr r0, [r1]\n\t"
"add r1, r1, #4 /* go to the next register */ \n\t"
"cmp r0, %1\n\t"
"beq read_reg_ok\n\t"
"ldr r3, =%2\n\t"
"str r3, [%4] /* update status flag */\n\t"
"read_reg_ok:\n\t"
"cmp r2, #0\n\t"
"bne read_reg\n\t"
"ldr r3, =%3\n\t"
"str r3, [%4] /* update status flag */\n\t"
:
: "r" (addr), "r" (reset), "r" (BAD), "r" (GOOD), "r" (status)
: "r0", "r1", "r2", "r3"
//:
);
}

I see the following errors:
/tmp/ccYu7aUS.ltrans0.ltrans.o: In function `read_reg_ok':
ccYu7aUS.ltrans0.o:(.text.check_reset_value.4010+0x60): undefined
reference to `r6'
ccYu7aUS.ltrans0.o:(.text.check_reset_value.4010+0x64): undefined
reference to `r4'
ccYu7aUS.ltrans0.o:(.text.check_reset_value.4010+0x68): undefined
reference to `r5'
collect2: error: ld returned 1 exit status

What am I doing wrong?

thanks,
Kalai

&lt;/pre&gt;</description>
    <dc:creator>Kalai Rajah N</dc:creator>
    <dc:date>2013-06-10T21:41:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44685">
    <title>trouble using glob and wordexp</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44685</link>
    <description>&lt;pre&gt;I'm getting an error at compile time.
All the variables are declared and my glob sruct is declared like this:

struct glob_t globualation

I though I might use wordexp instead since it would be more suited to what
I'm doing but that fails with the same error exept it's wordexp's structure
that is the problem.

I also tried this to no avail.

Gcc complains that the struct size is unknown.



--
View this message in context: http://gcc.1065356.n5.nabble.com/trouble-using-glob-and-wordexp-tp945091.html
Sent from the gcc - Help mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>ballsystemlord</dc:creator>
    <dc:date>2013-06-10T15:59:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.help/44682">
    <title>embedding compile options in program</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.help/44682</link>
    <description>&lt;pre&gt;Is there a conditional define that expands to  a string of the full
gcc command-line used to compile the given .c/.cc file?  I'd like to
embed in the executable the exact compilation options used to build
it.
Thanks for help,
ilya

&lt;/pre&gt;</description>
    <dc:creator>Ilya Shlyakhter</dc:creator>
    <dc:date>2013-06-09T22:29:08</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>
