David Malcolm | 29 Jul 20:35 2014

Prototype of a --report-bug option

At Cauldron on the Sunday morning there was a Release Management BoF
session, replacing the specRTL talk (does anyone know what happened to
the latter?)

One of the topics was bug triage, and how many bug reports lacked basic
metadata on e.g. host/build/target, reproducer etc.

I suggested we could automate gathering this, and rashly promised to
write a prototype in Python.  So here it is...

The attached script demonstrates a way to generate a URL that, when
followed, takes the user to the GCC Bugzilla "Enter Bug" page, with all
pertinent fields prepopulated with meaningful data.  (run the script,
and follow the URL; this uses the same server-side URLs as the "Remember
values as bookmarkable template" BZ button).

The idea is that the "gcc" driver program could gain a --report-bug
feature that injects -save-temps into the options, disables plugins, and
tries to reproduce a crash.  It then gives you the URL to click on,
capturing the backtrace and embedding it into the form for you.

Perhaps we could guess the "Component" based on the backtrace.

I note that there doesn't seem to be a "trunk" entry for "Version".

I am both proud of, and scared of, this idea: it could make it easy for
people to file higher-quality bugs.  On the other hand, that means more
bugs in the tracker... (they do at least need to be logged in).

Note that this points users at the GCC bug tracker.  Presumably
(Continue reading)

Tobias Burnus | 29 Jul 10:48 2014

Re: Gfortran issue

Good morning Jerome,

Jerome Huck wrote:
> I have warning with COMMON. The COMMONS are the same along the code...
> When compiled I have warnings with different sizes !!!

Well, neither /NO1/ nor /NO4/ are not the same size throughout the code.

> There were some bugs/issues in the past see :

Those issues were about not warning in this case - not about
falsely warning.

Back to your code.  In the main program and in GRID your code
contains for /NO4/ the variables: QF(6,14,3), QC(4,13,3), DXW

But in WING it only has in /NO4/ only: QF(6,14,3)

Similarly for /NO1/, which has:
      COMMON/NO1/ DS

The Fortran standard mandates that all named common blocks have
the same size. However, looking at your common blocks, I think
your declarations are fine in practice. Thus, you can ignore
the warning, unless you want to make the code conforming to
the Fortran standard.

Quoting Fortran 77's 8.3.3: "Within an executable program, all
(Continue reading)

Gengyulei (Gengyl | 29 Jul 10:07 2014

Is there any possibility to parallel compilation in a single file?


 Is there any possibility to parallel the compilation in a single file scope? For large application the
compilation time is long, although we

can parallel the process at the level of files, we still try to find a way to accelerate the compilation in a
single file. Can we change some serial process into 

Parallel?  Could you give me some advices? Thank you very much.

Best regards.


Carrot Wei | 29 Jul 02:49 2014

Reload generate invalid instruction on ppc64

Hi Vlad

When I use ppc64 gcc4.9 to compile an internal application I got an
ICE due to an invalid instruction generated by reload.

Before IRA, I have following insns:

(insn 139 136 581 10 (set (reg:DI 567)
        (const_int 0 [0])) ./strings/stringpiece.h:205 discrim 1 520
     (expr_list:REG_EQUIV (const_int 0 [0])


(insn 231 1062 237 24 (set (reg:V2DI 401 [ vect_cst_.7586 ])
        (vec_concat:V2DI (reg:DI 235 [ fprint$lo_ ])
            (reg:DI 567))) 1066 {vsx_concat_v2di}
     (expr_list:REG_DEAD (reg:DI 235 [ fprint$lo_ ])
        (expr_list:REG_EQUAL (vec_concat:V2DI (reg:DI 235 [ fprint$lo_ ])
                (const_int 0 [0]))

IRA decides register r567 should be spilled into memory

       a48(r567,l0)  -- assign memory
    48:r567 l0   mem

Later reload pass reload constant 0 into hard floating point r42 directly

(Continue reading)

Prathamesh Kulkarni | 28 Jul 22:02 2014

[GSoC] replacing op in c_expr

I am having few issues replacing op in c_expr.
I thought of following possibilities:

a) create a new vec<cpp_token> vector new_code.
for each token in code
    if token.type is not CPP_NAME
      new_code.safe_push (token);
        cpp_token new_token =
            ??? create new token of type CPP_NAME
                  with contents as name of operator ???

I tried to go this way, but am stuck with creating a new token type.
i started by:
cpp_token new_token = token;  // get same attrs as token.
CPP_HASHNODE (new_token.val.node.node)->ident.str = name of operator.
CPP_HASHNODE (new_token.val.node.node)->ident.len = len of operator name.
name of operator is obtained from opers[i] in parse_for.

however this does not work because I guess
 new_token = token, shallow copies
the token (default assignment operator, i didn't find an overloaded version).

b) create new struct c_expr_elem and use
vec<c_expr_elem> code, instead of vec<cpp_token> code;

(Continue reading)

gccadmin | 28 Jul 00:54 2014

gcc-4.10-20140727 is now available

Snapshot gcc-4.10-20140727 is now available on
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

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

You'll find:

 gcc-4.10-20140727.tar.bz2            Complete GCC


Diffs from 4.10-20140720 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.10
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.

Prathamesh Kulkarni | 27 Jul 22:05 2014

[GSoC] support for literals

    I was wondering if it would be a good idea to have the following syntax
for literals:
(type val) ?
type would be one of the tree-codes representing cst types like

(negate (integer_cst 3))

would be equivalent to the following:
(negate INTEGER_CST_P <at> 0)
if (TREE_INT_CST_LOW ( <at> 0) == 3)
{ .. }

Also possibly provide a short-hand for some literals
like integer and floating point, so just writing
3 would be short-hand for (integer_cst 3) ?

Many patterns from [1] have integral constants to match.
eg: (a >> 2) >=3 -> a >= (3 << 2)
so this could be written as:
(gte (rshift  <at> 0 2) 3)
(gte  <at> 0 (lshift 3 2))

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14753


(Continue reading)

Christian Svensson | 27 Jul 17:43 2014

New architecture port: legal matters and copyright assignment


I'm coordinating the effort to prepare the OpenRISC architecture GCC
port for mainline review.
The website https://gcc.gnu.org/contribute.html recommends reaching
out to this mailing list for all the latest and greatest help to make
this happen.

I'm aware of the process of assigning copyright via assign <at> gnu.org
(the form that requests a list of all changed files), that was the
process we followed for binutils. Is there anything else that needs to
be done?

Thanks in advance,

Prathamesh Kulkarni | 26 Jul 23:20 2014

[GSoC] outer-if expressions

   This patch adds support for outer-if expressions.

Couple of issues:
a) Doesn't interop with for-pattern, since we don't replace identifier
in c-expr yet,
and this gets more complicated with addition of outer-if.

b) I removed ifexpr-locations for now. I am not sure where to output
if-expr locations
when there are multiple if-exprs (one outer and one inner).

* genmatch.c (simplify::ifexpr): Remove.
      (simplify::ifexpr_location): Likewise.
      (simplify::simplify): Adjust to changes in simplify and
                                   add parameter ifexpr_vec_.
      (dt_simplify::gen_gimple): Adjust to changes in simplify.
      (dt_simplify::gen_generic): Likewise.
      (parse_if): New function.
      (parse_pattern): Add call to parse_if.

* match.pd: Use outer-if for plus-minus patterns.

Attachment (outer-if.patch): text/x-patch, 11 KiB
Andreas Schwab | 26 Jul 19:57 2014

Re: GCC version bikeshedding

NightStrike <nightstrike <at> gmail.com> writes:

> On Jul 26, 2014 9:26 AM, "Andreas Schwab" <schwab <at> linux-m68k.org> wrote:
>> pinskia <at> gmail.com writes:
>> >> On Jul 23, 2014, at 9:51 AM, Andreas Schwab <schwab <at> linux-m68k.org>
> wrote:
>> >>
>> >> Ian Lance Taylor <iant <at> google.com> writes:
>> >>
>> >>> At the same time, we face the fact that going from 4.9 to 4.10 will
>> >>> break some people's existing scripts, as is also true of any other
>> >>> decision we can make.
>> >>
>> >> Looking forward to gcc 10.0. :-)
>> >
>> > So are following what sun did?
>> What does this have to do with sun?
> It's what sun did for Java and I think Solaris

Did what?



Andreas Schwab, schwab <at> linux-m68k.org
(Continue reading)

Basile Starynkevitch | 26 Jul 09:05 2014

Ann: MELT plugin 1.1 release candidate 1 available

Dear All,

It is my please to announce the MELT plugin 1.1 release candidate 1 for
GCC 4.8 and 4.9 (hosted preferably on Linux).

MELT -see http://gcc-melt.org/ for more - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.

The MELT plugin 1.1 release candidate 1 (for GCC 4.8 or 4.9, with major
updates since previous MELT plugin 1.0.2) is available (since july 26th,
2014) from 

as a bzip2-ed tar source file of md5sum
3b7ea46dddac2e81927c211ca6a90201, and of 3891814 bytes (3.8 Megabytes),
extracted from MELT branch svn revision 213071.

NEWS for 1.1 MELT plugin for GCC 4.8 & 4.9
[[july 2014]]
This is a major release (with perhaps some small incompatibilities
with previous MELT plugin releases).

   End-user improvements


   The module list files *.modlis accept conditioned extra
   modules. Within them, a line like
(Continue reading)