Hello,
this fixes a bug I introduced when adding noexcept all over the place by
reverting the guilty bit.
Tested with no regression on x86_64-linux-gnu, and checked that the leak
has disappeared in the PR.
2014-02-22 Marc Glisse
PR libstdc++/60308
* include/bits/stl_dequ
Since GCC 4.9, gfortran generates a DECL_NAMELIST (for DWARF's
DW_TAG_namelist) - they are stored in the BIND_EXPR. Namelists are a bit
boring: They only group variable names and the namelist name is only
used in I/O statements (READ, WRITE) to permit a fancy data input [and
output] - and for t
On 22 February 2014 08:53, Marc Glisse wrote:
> Hello,
>
> this fixes a bug I introduced when adding noexcept all over the place by
> reverting the guilty bit.
>
> Tested with no regression on x86_64-linux-gnu, and checked that the leak has
> disappeared in the PR.
>
This is OK, thanks for the qui
Index: gcc/gcc.c
===
--- gcc/gcc.c (revision 208009)
+++ gcc/gcc.c (working copy)
@@ -3108,8 +3108,21 @@
fputs (_(" -specs=Override built-in specs with the contents of \n"), stdout);
fputs (_(" -std= Assum
Le 19/02/2014 16:51, Janus Weil a écrit :
> The patch was not applying cleanly any more, so here is a re-diffed
> version for current trunk. It works nicely on the included test case
> as well as the one provided by Walter Spector in comment 12 of the PR.
>
> Since, also in the current state, "cha
On Sat, Feb 22, 2014 at 04:38:52PM +0100, Mikael Morin wrote:
> > +
> > +bool
> > +gfc_deferred_strlen (gfc_component *c, tree *decl)
> > +{
> > + char name[GFC_MAX_SYMBOL_LEN+1];
Shouldn't this be +2?
> > + gfc_component *strlen;
> > + if (!(c->ts.type == BT_CHARACTER && c->ts.deferred))
> >
There was a new effective-target predicate (thanks, Richard S),
but the droplet that broke the camel's back or something, wasn't
added to its target-list. Committed after brief testing
(checking that tests fail before, checking that tests pass after
patch).
Other observations:
- LOGICAL_OP_NON_SH
Not sure if this a good idea, but it seemed to me that goto sizeof_expr; wasn't
really required in c_parser_sizeof_expression.
Bootstrapped and regression tested on x8_64-unknown-linux-gnu
Ok for trunk ?
* c-parser.c (c_parser_sizeof_expression): Remove goto sizeof_expr;
Thanks and Regards,
Prath
On Sat, Feb 22, 2014 at 10:34 PM, Prathamesh Kulkarni
wrote:
> Not sure if this a good idea, but it seemed to me that goto sizeof_expr;
> wasn't
> really required in c_parser_sizeof_expression.
> Bootstrapped and regression tested on x8_64-unknown-linux-gnu
> Ok for trunk ?
>
> * c-parser.c (c_pa
On Sat, Feb 22, 2014 at 10:34:13PM +0530, Prathamesh Kulkarni wrote:
> Not sure if this a good idea, but it seemed to me that goto sizeof_expr;
> wasn't
> really required in c_parser_sizeof_expression.
> Bootstrapped and regression tested on x8_64-unknown-linux-gnu
> Ok for trunk ?
>
> * c-parser
2014-02-19 19:15 GMT+04:00 Joern Rennecke :
> When compiling compile/pr17906.c, compute_frame_pointer_to_fb_displacement
> passes the argument pointer to eliminate_regs. This eliminates it to
> the frame pointer,
> which later causes and ICE because frame_pointer_needed is not set.
>
> The problem
On Sat, Feb 22, 2014 at 11:44 PM, Marek Polacek wrote:
> On Sat, Feb 22, 2014 at 10:34:13PM +0530, Prathamesh Kulkarni wrote:
>> Not sure if this a good idea, but it seemed to me that goto sizeof_expr;
>> wasn't
>> really required in c_parser_sizeof_expression.
>> Bootstrapped and regression test
On Sun, Feb 23, 2014 at 12:19:49AM +0530, Prathamesh Kulkarni wrote:
> Is this fine ?
No, there still are some formatting issues.
> Index: gcc/c/c-parser.c
> ===
> --- gcc/c/c-parser.c (revision 207916)
> +++ gcc/c/c-parser.c (work
On 01/27/14 18:20, Hans-Peter Nilsson wrote:
You'd need some additional conditions. There might be the
additional issue that any "lex" is expected to work too, not
just "flex".
It isn't committed 'cuz nobody said, "Okay."
I do wish either someone would say, "Okay." or come up with something
th
In retrospect, it occurs to me that a "am-i-ready-to-build.sh" script
in the contrib directory might be useful, too.
Hi all,
Just a ping, I haven't gotten anything back on this patch:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00621.html
Thanks!
Hi,
This patch adds -maltivec=be support for vec_lde and vec_ste, similarly
to what was done for vec_ld, vec_st, vec_ldl, and vec_stl. Much of the
same infrastructure is used. Because the insn pattern for vec_ste is
formed slightly differently than the ones for vec_st and vec_stl, we
can't reuse
17 matches
Mail list logo
