Basile Starynkevitch | 29 Aug 17:29 2014

GCC plugins & GGC & explicit gcc_free

Hello All,

[[I know that this is a sensitive issue, and I also know that I am in
the minority believing that a garbage collection is useful inside the
GCC compiler]]

How should plugins deal with data that is explicitly gcc_free-d outside
of ggc_collect?

In particular, plugins are apparently allowed to have their own GTY-ed
data (which is very good, I certainly don't want that feature to
disappear). I'm particularly thinking of "static analysis" (or
"observing") plugins, which would take advantage of the GCC compiler to
add some extra measures and analysis but which won't change anything
observable in the GCC internal representations (e.g. plugins that won't
add or remove any Gimple inside existing functions, for instance).

I believe that such "observing" plugins should certainly be allowed to
register a pass which would put some data (e.g. tree-s or basic_block-s)
inside some GTY-ed variable and examine it much later, perhaps even at
PLUGIN_FINISH time (and certainly at PLUGIN_FINISH_UNIT time). This
would make sense if such a plugin would like to make some detailed
statistics, serialize *some* of the Gimple or Tree-s in a database, etc.

However, such a plugin could crash, because at several occasions
ggc_free is *forcibly* called *outside* of the garbage collector - and
there is no mechanism (finalization, plugin hooks) to communicate that
deletion to the plugin. So such a plugin will keep a *stale* data
referenced by its GTY-ed roots.

(Continue reading)

lin zuojian | 29 Aug 11:50 2014

record_component_aliases will not record the bases with no field declaration

    record_component_aliases only handle fields of a record type, and
    would ignore the base of this record if the base has no field
    Is this a bug or on purpose?
Lin Zuojian

DJ Delorie | 29 Aug 06:27 2014

push_rounding vs memcpy vs stack_pointer_delta

The m32c-elf with -mcpu=m32c has a word-aligned stack and uses pushes
for arguments (i.e. not accumulate_outgoing_args).  In this test case,
one of the arguments is memcpy'd into place, and an assert fails:

typedef struct {
  int a, b, c, d, e, f, g, h;
} foo;
int x;
dj (int a, int b, foo c)
  dj2 (x, a, b, c);

      if (pass == 0)
	  . . .
	  normal_call_insns = insns;

	  /* Verify that we've deallocated all the stack we used.  */
	  gcc_assert ((flags & ECF_NORETURN)
		      || (old_stack_allocated
			  == stack_pointer_delta - pending_stack_adjust));

After much debugging, it turns out that the argument that's memcpy'd
(Continue reading)

gccadmin | 29 Aug 00:36 2014

gcc-4.8-20140828 is now available

Snapshot gcc-4.8-20140828 is now available on
and on various mirrors, see for details.

This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn:// revision 214699

You'll find:

 gcc-4.8-20140828.tar.bz2             Complete GCC


Diffs from 4.8-20140821 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.

gccadmin | 28 Aug 00:45 2014

gcc-4.9-20140827 is now available

Snapshot gcc-4.9-20140827 is now available on
and on various mirrors, see for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn:// revision 214609

You'll find:

 gcc-4.9-20140827.tar.bz2             Complete GCC


Diffs from 4.9-20140820 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.

Basile Starynkevitch | 27 Aug 20:29 2014

consistent naming of passes....

Hello all,

When I compile some file (precisely, the gcc/ from the latest melt branch) with -O1
-fdump-passes (using GCC 4.9) I'm getting

   ipa-cp                                              :  OFF
   ipa-cdtor                                           :  OFF
   ipa-inline                                          :  ON
   ipa-pure-const                                      :  ON
   ipa-static-var                                      :  ON
   ipa-pta                                             :  OFF
   ipa-simdclone                                       :  OFF
   *free_cfg_annotations                               :  ON

However, in file gcc/ipa-inline.c there is

const pass_data pass_data_ipa_inline =
  IPA_PASS, /* type */
  "inline", /* name */
  OPTGROUP_INLINE, /* optinfo_flags */
  false, /* has_gate */
  true, /* has_execute */
  TV_IPA_INLINING, /* tv_id */

I find strange that the two names (the one given by -fdump-passes and the one in the pass_data_ipa_inline
object) are different.

When I try to insert a plugin pass (actually in MELT, file gcc/melt/xtramelt-ana-simple.melt) named
(Continue reading)

Wilco Dijkstra | 27 Aug 18:24 2014

Register allocation: caller-save vs spilling


I'm investigating various register allocation inefficiencies. The first thing that stands out is
that GCC both supports caller-saves as well as spilling. Spilling seems to spill all definitions and
all uses of a liverange. This means you often end up with multiple reloads close together, while it
would be more efficient to do a single load and then reuse the loaded value several times.
Caller-save does better in that case, but it is inefficient in that it repeatedly stores registers
across every call even if unchanged. If both were fixed to minimise the number of loads/stores I
can't see how one could beat the other, so you'd no longer need both.

Anyway due to the current implementation there are clearly cases where caller-save is best and cases
where spilling is best. However I do not see it making the correct decision despite trying to
account for the costs - some code is significantly faster with -fno-caller-saves, other code wins
with -fcaller-saves. As an example, I see code like this on AArch64:

        ldr     s4, .LC20
        fmul    s0, s0, s4
        str     s4, [x29, 104]
        bl      f
        ldr     s4, [x29, 104]
        fmul    s0, s0, s4

With -fno-caller-saves it spills and rematerializes the constant as you'd expect:

        ldr     s1, .LC20
        fmul    s0, s0, s1
        bl      f
        ldr     s5, .LC20
        fmul    s0, s0, s5

(Continue reading)

Daniel Gutson | 27 Aug 16:27 2014

Possible LRA issue?


   I have a large codebase where at some point, there's a structure
that takes an unsigned integer template argument, and uses as the size
of an array, something like

template <class T, size_t S>
struct Struct
    typedef std::array<T, S> Chunk;
    typedef std::list<Chunk> Content;

   Content c;

Changing the values of S alters significantly the compile time and
memory that the compiler takes. We use some large numbers there.
At some point, the compiler runs out of memory (xmalloc fails). I
wondered why, and did some analysis by debugging the 4.8.2 (same with
4.8.3), and did the following experiment turning off all the
optimizations (-fno-* and -O0):
  I generated a report of xmalloc usage of two programs: one having
S=10u, and another with S=11u, just to see the difference of 1.
The report was generated as follows: I set a breakpoint at xmalloc,
appending a bt to a file. Then I found common stack traces and counted
how many xmallocs were called in one and another versions of the
program (S=10u and S=11u as mentioned above).
The difference were:

a) Stack trace:
(Continue reading)

Dominik Vogt | 27 Aug 11:59 2014

Turning a single warning into an error in dejagnu test

I'm writing a dejagnu test and encounter this warning at one place:

  warning: passing argument 1 of '...' makes integer from pointer
  without a cast [enabled by default]

Now, I have a "{ dg-error ... }" comment in that line.  The line
is generated from a script among hundreds of others that are all
expected to produce errors, not warnings.  It would be very
inconvenient (= lots of work) to change the script to make an
exception just for that single line (because there's no easy way
to identify lines that produce the warning instead of an error).

So the question is:  Is it possible to turn only this one warning
into an error inside a dejagnu test?  As I understand it, there
are no -W... switches for "enabled by default" options, and I
cannot use -Werror because that would break other tests in the


Dominik ^_^  ^_^



Dominik Vogt
IBM Germany

Mike Stump | 27 Aug 07:06 2014

The C++ link on the main web page seems old

Gosh, and seem to old and dated now.  First, the standard before
last has been published.  Second, at some point, it can’t be experimental anymore.  Would be nice if
someone could update the content.  The part about the concepts branch being dead is now wrong, it is alive again.
Sebastian Pop | 26 Aug 15:56 2014

[AArch64] Using QEMU to run Ubuntu ARM 64-bit


my colleague Brian has posted the instructions to set up
an AArch64 virtual machine running ubuntu on top of qemu:

We are using this setup to bootstrap gcc on aarch64.