<?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.devel">
    <title>gmane.comp.gcc.devel</title>
    <link>http://blog.gmane.org/gmane.comp.gcc.devel</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.devel/131449"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131445"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131444"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131438"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131437"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131435"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131434"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131433"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131430"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131429"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131428"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131425"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131423"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131419"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131415"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131411"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131410"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131401"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131397"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/131393"/>
      </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.devel/131449">
    <title>Loop induction variable optimization question</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131449</link>
    <description>&lt;pre&gt;
I have a loop induction variable question involving post increment.
If I have this loop:

void *memcpy_word_ptr(int * __restrict d, int * __restrict s, unsigned int n )
{
  int i;
  for(i=0; i&amp;lt;n; i++) {*d++ = *s++; }
  return d;
}

and compile it with: -O3 -fno-tree-loop-distribute-patterns,
the loop induction variable pass (ivopts) converts this loop:

  &amp;lt;bb 4&amp;gt;:
  # d_22 = PHI &amp;lt;d_10(6), d_5(D)(3)&amp;gt;
  # s_23 = PHI &amp;lt;s_11(6), s_6(D)(3)&amp;gt;
  # i_24 = PHI &amp;lt;i_14(6), 0(3)&amp;gt;
  d_10 = d_22 + 4;
  s_11 = s_23 + 4;
  _12 = *s_23;
  *d_22 = _12;
  i_14 = i_24 + 1;
  i.2_8 = (unsigned int) i_14;
  if (i.2_8 &amp;lt; n_9(D))
    goto &amp;lt;bb 6&amp;gt;;  # bb 6 just loops back to bb 4
  else
    goto &amp;lt;bb 5&amp;gt;;

into this loop (using -4 offsets to compensate for incrementing the 's' and 'd'
variables before their use:

  &amp;lt;bb 4&amp;gt;:
  # d_22 = PHI &amp;lt;d_10(6), d_5(D)(3)&amp;gt;
  # s_23 = PHI &amp;lt;s_11(6), s_6(D)(3)&amp;gt;
  # i_24 = PHI &amp;lt;i_14(6), 0(3)&amp;gt;
  d_10 = d_22 + 4;
  s_11 = s_23 + 4;
  _12 = MEM[base: s_11, offset: 4294967292B];
  MEM[base: d_10, offset: 4294967&lt;/pre&gt;</description>
    <dc:creator>Steve Ellcey </dc:creator>
    <dc:date>2013-06-17T17:07:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131445">
    <title>unusable libatomic.so built in certain environments</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131445</link>
    <description>&lt;pre&gt;In an environment with relatively old core components (dynamic
loader and glibc) but with up-to-date binutils (perhaps built along
with gcc) libatomic.so gets built in a way such that it is unusable
on the build system. A similar issue was reported in a mail leading
to http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00315.html,
but I don't view switching back to old binutils as an acceptable
option.

Looking at the libatomic configury, I also do not see a way to
suppress the use of GNU IFUNC symbols. Am I overlooking
something, or is this an outright bug in a configuration no-one
really ever thought about? At least in a non-cross build I'd
expect runtime properties to be taken into account here. And
for cross builds I'd expect a way to control whether the final
binary would be using GNU IFUNC symbols rather than just
making this dependent upon tool chain capabilities.

Thanks, Jan


&lt;/pre&gt;</description>
    <dc:creator>Jan Beulich</dc:creator>
    <dc:date>2013-06-17T13:25:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131444">
    <title>Generate coverage informations in different sections.</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131444</link>
    <description>&lt;pre&gt;Hi,
  I'm a Xen developer. We have coverage support (lcov replacement) in
order to extract coverage information. However would be very helpful to
have a way to put counters, structures and strings (file names) related
to coverage in different section. Actually there are no such options (it
would be better for us to separate counters and structures/strings).

I tried to change generated .s files in order to separate these
informations but without success (I'm not so expert with gas, last gcc
require common section).

Is it difficult to implement such a feature in next gcc?

Do somebody have a better idea?

Frediano

&lt;/pre&gt;</description>
    <dc:creator>Frediano Ziglio</dc:creator>
    <dc:date>2013-06-17T12:33:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131438">
    <title>gcc-4.9-20130616 is now available</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131438</link>
    <description>&lt;pre&gt;Snapshot gcc-4.9-20130616 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20130616/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 200141

You'll find:

 gcc-4.9-20130616.tar.bz2             Complete GCC

  MD5=64b451e5dfcc930e80f9d2107a04b65c
  SHA1=ab07de380f467e644930417a5ed5efb88b737cdd

Diffs from 4.9-20130609 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

&lt;/pre&gt;</description>
    <dc:creator>gccadmin&lt; at &gt;gcc.gnu.org</dc:creator>
    <dc:date>2013-06-16T22:42:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131437">
    <title>designated initializers extension and sparc</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131437</link>
    <description>&lt;pre&gt;Hi,

Reading the text
-------------
In a structure initializer, specify the name of a field to initialize 
with `.fieldname =' before the element value. For example, given the 
following structure,
      struct point { int x, y; };
the following initialization
      struct point p = { .y = yvalue, .x = xvalue };
is equivalent to
      struct point p = { xvalue, yvalue };
Another syntax which has the same meaning, obsolete since GCC 2.5, is 
`fieldname:', as shown here:
      struct point p = { y: yvalue, x: xvalue };
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.)
---&lt;/pre&gt;</description>
    <dc:creator>Sergey Kljopov</dc:creator>
    <dc:date>2013-06-16T22:28:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131435">
    <title>source code to object code tracetability</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131435</link>
    <description>&lt;pre&gt;Hi,

I am trying to analyze source code to object code traceability while
using C source code and GCC 3.3.2 with optimization levels O0, O1, O2.
I create test cases that each test case (separate routine) contains
one C source code construct (if - else, do-while, for loop, switch and
etc.) and analyse the traceability to the object code. I would like to
ensure that all cases of constructs in the source code are covered by
this analysis.  I wonder if I need to extend the list of constructs
with additional cases as “if….else do….while”  in case the object code
created from separate  “if….else" and "do….while” statements is
different from the object code created  from two consecutive “if…else
do ... while” statements.  Is there a way to identify the full list of
these constructs to ensure that each object code is traceable back to
the source code using optimization level -O2? How different is this
list from optimization level -O1 or -O0?

Thanks,

Barry.

&lt;/pre&gt;</description>
    <dc:creator>Barry Holm</dc:creator>
    <dc:date>2013-06-16T17:06:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131434">
    <title>[PR43721] Failure to optimise (a/b) and (a%b) into single  call</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131434</link>
    <description>&lt;pre&gt;Hi,

I am attempting to fix Bug 43721 - Failure to optimise (a/b) and (a%b) 
into single __aeabi_idivmod call 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721)

execute_cse_sincos tree level pass does similar cse so I attempted to 
use similar approach here. Div/mod cse is not really using built-in 
functions though at this level.

For the case of div and mod operations, after CSE is performed, there 
isnt a way to represent the resulting stament in gimple. We will endup 
with divmod  taking two arguments and returning double the size of one 
arguments in the three address format (divmod will return reminder and 
quotient so the return type is double the size of argument type).

Since GIMPLE_ASSIGN will result in type checking failure in this case, I 
atempted use built-in functions (GIMPLE_CALL to represent the runtime 
library call). Name for the function here  is target specific and can be 
obtained from sdivmod_optab so the builtin function name defined in tree 
level is not used. I am not entirelt su&lt;/pre&gt;</description>
    <dc:creator>Kugan</dc:creator>
    <dc:date>2013-06-16T15:33:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131433">
    <title>out of source builds and precompiled headers</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131433</link>
    <description>&lt;pre&gt;I'm just pinging bug #19541 which, despite having patches with several 
solutions, isn't assigned to anybody. It's a 8 years old bug...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541

Here's the note I added there, FYI:

How difficult is it to add a parameter to add paths to precompiled 
header search list *only*?

We have a big code base with #include "pch.h" in some source files.
If source file directory is always searched first for headers, this 
breaks out-of-source builds, unless the precompiled header is generated 
in the source tree. For read-only source trees, this "solution" is 
unacceptable.

The ideal solution would be a parameter like -ipch &amp;lt;path&amp;gt; that adds 
&amp;lt;path&amp;gt; to be searched for precompiled headers *before* the current 
source directory.

I could spend some time creating a patch, but seeing that others have 
come with patches that weren't applied, this kind of demotivate me.


Best regards,
Rodolfo Lima


&lt;/pre&gt;</description>
    <dc:creator>Rodolfo Lima</dc:creator>
    <dc:date>2013-06-16T15:18:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131430">
    <title>There is a -Wenum-compare warning in gcc/c-family/array-notation-common.c</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131430</link>
    <description>&lt;pre&gt;Hi Balaji,

I was building a native gcc with trunk r200117,
but I noticed the following code fragment cause -Wenum-compare warning:


[gcc/c-family/array-notation-common.c]

483   /* This function is used by C and C++ front-ends.  In C++, additional
484      tree codes such as TARGET_EXPR must be eliminated.  These codes are
485      passed into additional_tcodes and are walked through and checked.  */
486   for (ii = 0; ii &amp;lt; vec_safe_length (i_list-&amp;gt;additional_tcodes); ii++)
487     if (TREE_CODE (*tp) == (enum rid)(*(i_list-&amp;gt;additional_tcodes))[ii])
488       *walk_subtrees = 0;


/gcc-4.9.0/gcc/c-family/array-notation-common.c: In function
'tree_node* find_inv_trees(tree_node**, int*, void*)':
/gcc-4.9.0/gcc/c-family/array-notation-common.c:487:68: warning:
comparison between 'enum tree_code' and 'enum rid' [-Wenum-compare]
  if (TREE_CODE (*tp) == (enum rid)(*(i_list-&amp;gt;additional_tcodes))[ii])
                                                                    ^

Seem that you are comparing different enum&lt;/pre&gt;</description>
    <dc:creator>Chung-Ju Wu</dc:creator>
    <dc:date>2013-06-16T01:23:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131429">
    <title>gcc-4.7-20130615 is now available</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131429</link>
    <description>&lt;pre&gt;Snapshot gcc-4.7-20130615 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20130615/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 200128

You'll find:

 gcc-4.7-20130615.tar.bz2             Complete GCC

  MD5=e38072c62ffdc0a49a567f9f92f417ae
  SHA1=8be84d3c6638cd27aa41dcb889d5d92b40c1ae26

Diffs from 4.7-20130608 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

&lt;/pre&gt;</description>
    <dc:creator>gccadmin&lt; at &gt;gcc.gnu.org</dc:creator>
    <dc:date>2013-06-15T22:40:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131428">
    <title>Libitm issues porting to POWER8 HTM</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131428</link>
    <description>&lt;pre&gt;I'm currently implementing support for hardware transactional memory in
the rs6000 backend for POWER8.  Things seem to be mostly working, but I
have run into a few issues I'm wondering whether other people are seeing.

For me, all of the libitm execution test cases in libitm/testsuite/libitm.c/
compile and execute without error, except for reentrant.c, which hangs for me.
My gdb hasn't been ported to support HTM on Power yet, so debugging has been
slow, but what I've learned is, that my tbegin. instruction succeeds, but I
fail the test (meaning someone has the write lock) at beginend.cc:200:

    if (unlikely(serial_lock.is_write_locked()))
      htm_abort();

...so we abort the transaction.  The failure is not persistent, so we do
not break out of the loop due to:

    if (!htm_abort_should_retry(ret))
      break;

We then fall into the following code, where we hang trying to get the
read lock:

    serial_lock.read_lock(tx);

I have yet to track down who has the write lock and why, but I am working
toward&lt;/pre&gt;</description>
    <dc:creator>Peter Bergner</dc:creator>
    <dc:date>2013-06-15T00:44:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131425">
    <title>Instruction scheduling question</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131425</link>
    <description>&lt;pre&gt;I have an instruction scheduling question I was hoping someone could help me
with.  Specifically, I am trying to figure out where and how GCC is deciding
to move the add of a constant to a register above the use of that register and
then changing the register usage by change the offsets associated with it.

For example, I am compiling the following memcpy code for MIPS:

void *memcpy_word_ptr(int * __restrict d, int * __restrict s, unsigned int n )
{
  int i;
  for(i=0; i&amp;lt;n; i++) *d++ = *s++;
  return d;
}

Using -fno-tree-loop-distribute-patterns -funroll-loops -O3,
the main loop I get is:

.L4:
lw$13,0($7)
addiu$7,$7,32
addiu$3,$3,32
addiu$8,$8,8
lw$12,-28($7)
lw$14,-24($7)
lw$15,-20($7)
lw$24,-16($7)
lw$5,-12($7)
lw$25,-8($7)
lw$9,-4($7)
sw$13,-32($3)
sw$12,-28($3)
sw$14,-24($3)
sw$15,-20($3)
sw$24,-16($3)
sw$5,-12($3)
sw$25,-8($3)
bne$8,$6,.L4
sw$9,-4($3)

Now, if I turn off instruction scheduling (-fno-schedule-insns
-fno-schedule-insns2), I get:

.L4:
lw$11,0($&lt;/pre&gt;</description>
    <dc:creator>Steve Ellcey </dc:creator>
    <dc:date>2013-06-14T20:43:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131423">
    <title>GNU Tools Cauldron 2013 - Schedule</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131423</link>
    <description>&lt;pre&gt;
An update on this year's Cauldron.

The schedule is now available at http://gcc.gnu.org/wiki/cauldron2013

We will start on Fri 12/Jul at 19:00.  Presentations will run Sat
all day and Sun until about 17:00.

We have a very packed schedule, so it is unlikely that we will be
able to add more presentations. However, we will have additional
rooms for impromptu meetings, if needed.


Diego.

&lt;/pre&gt;</description>
    <dc:creator>Diego Novillo</dc:creator>
    <dc:date>2013-06-14T14:57:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131419">
    <title>gcc-4.8-20130613 is now available</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131419</link>
    <description>&lt;pre&gt;Snapshot gcc-4.8-20130613 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130613/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 200079

You'll find:

 gcc-4.8-20130613.tar.bz2             Complete GCC

  MD5=df10611506ea0afaaf893512834f9504
  SHA1=0dc2ab0701dacab230ed23af612ab3391a437145

Diffs from 4.8-20130606 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

&lt;/pre&gt;</description>
    <dc:creator>gccadmin&lt; at &gt;gcc.gnu.org</dc:creator>
    <dc:date>2013-06-13T22:37:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131415">
    <title>Доброго времени суток</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131415</link>
    <description>&lt;pre&gt;Вы будете зреть мир во любых его расцветках http://goo.gl/1R0Y0?/MhffOh Превосходно

Мама что-то говорила, плакала, щупала меня, Принц обнюхивал мою руку, за которую брался оборотень, и рычал. Но все эти действия были от меня далеки, развивались как бы на втором плане. Мои мысли, хлынувшие сокрушительным потоком, как будто прорвало плотину, были заняты одним: оборотнем. Его странным появлением и уходом.

&lt;/pre&gt;</description>
    <dc:creator>admin&lt; at &gt;synergy-botanicals.com</dc:creator>
    <dc:date>2013-06-13T12:05:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131411">
    <title>What's up with g++.dg/ext/mv*.C?</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131411</link>
    <description>&lt;pre&gt;Hi,

these FAILs are much more recent but frankly I'm also puzzled: is a fix 
actively in the making? Do we have any sort of time for that?

Thanks,
Paolo.

&lt;/pre&gt;</description>
    <dc:creator>Paolo Carlini</dc:creator>
    <dc:date>2013-06-13T10:28:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131410">
    <title>Can we somehow XFAIL libmudflap.c++/pass41-frag.cxx ?</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131410</link>
    <description>&lt;pre&gt;Hi,

I don't remember seeing this testcase pass and the FAILs clutter the 
testsresults. Can we XFAIL it?

Thanks,
Paolo.

&lt;/pre&gt;</description>
    <dc:creator>Paolo Carlini</dc:creator>
    <dc:date>2013-06-13T10:25:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131401">
    <title>Can our C++ vectors hold derived classes?</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131401</link>
    <description>&lt;pre&gt;Hi everyone, but especially Diego :-)

it seems to me that our new C++ vectors have some problems holding
derived classes.  For example, when try to compile the following

  struct zzzA
  {
    int kind;
  };
  
  struct zzzB : public zzzA
  {
    int some, data, here;
  };
  
  struct container
  {
    vec &amp;lt;zzzB&amp;gt; my_vec;
  };
  static struct container my_cnt;
  
  /* and then somewhere later do */
  my_cnt.my_vec.create (8);

I get the following warnings:

In file included from /home/mjambor/gcc/small/src/gcc/tree.h:27:0,
                 from /home/mjambor/gcc/small/src/gcc/ipa-cp.c:106:
/home/mjambor/gcc/small/src/gcc/vec.h: In instantiation of ‘static size_t vec&amp;lt;T, A, vl_embed&amp;gt;::embedded_size(unsigned int) [with T = zzzB; A = va_heap; size_t = long unsigned int]’:
/home/mjambor/gcc/small/src/gcc/vec.h:298:64:   required from ‘static void va_heap::reserve(vec&amp;lt;T, va_heap, vl_embed&amp;gt;*&amp;amp;, unsigned int, bool) [with T = zzzB]’
/home/mjambor/gcc/small/src/gcc/vec.h:1468:5:   required from ‘bool vec&amp;lt;T, A&lt;/pre&gt;</description>
    <dc:creator>Martin Jambor</dc:creator>
    <dc:date>2013-06-12T17:23:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131397">
    <title>Custom hash tables in extensions</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131397</link>
    <description>&lt;pre&gt;Dear GCC devs,

I hope you don't mind me posting on this list. I'm trying to finish up an  
AST to XML converter, which I started porting from GCC-XML (a patched  
version of GCC-4.2) to a GCC plugin, quite a while ago now.

I'd really appreciate any help with finishing this up, as there's a lot to  
learn about GCC's internal garbage collection mechanisms, and I can't  
afford to burn much time on this at the moment, but I would like it to  
actually work...


(Please excuse the use of `VEC(tree, gc)` instead of `vec&amp;lt;tree, va_gc&amp;gt;` in  
this email; I'm accommodating for both in my code. Also, sorry about the  
length of this; I'm not very good at concise...)


Current plugin deficiency, cf. original GCCXML implementation
-----

One of the (last?) limitations of the plugin as it stands, is that each  
`cp_binding_level` is missing an extra `VEC(tree, gc)*` member, which was  
originally patched in to name-lookup.h. This VEC - i.e.  
`cp_binding_level-&amp;gt;all_decls` - stored all (grand-)child declarations  
passe&lt;/pre&gt;</description>
    <dc:creator>Alex Leach</dc:creator>
    <dc:date>2013-06-11T13:08:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131393">
    <title>Memory dependence</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131393</link>
    <description>&lt;pre&gt;In the architecture that I am using, there is a big pipeline penalty for 
read after write to the same memory location. Is it possible to tell the 
difference between a possible memory conflict and a definite memory 
conflict?


&lt;/pre&gt;</description>
    <dc:creator>shmeel gutl</dc:creator>
    <dc:date>2013-06-11T05:07:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/131389">
    <title>aprovechas las mejores ofertas</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/131389</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:15</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gcc.devel">
    <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.devel</link>
  </textinput>
</rdf:RDF>
