Adding a few more tweaks:
commit bf054f32b165fda6e90c52a57a31538e5ae24678
Author: Jason Merrill
Date: Mon Aug 25 00:48:17 2014 -0400
* c.opt: Change -std=c++1y and -std=gnu++1y to be aliases for
-std=c++14 and -std=gnu++14, rather than the reverse.
* c-opts.c (c_common_handle_o
To avoid the unused new discriminator value, I added a map
"found_call_this_line" to track whether a call is the first call in a
source line seen when assigning discriminators. For the first call in
a source line, its discriminator is 0. For the following calls in the
same source line, a new discri
On 08/23/2014 06:29 PM, Ville Voutilainen wrote:
Based on my quick tests with it, it seems to me that we need more
tests for static member variable templates. My first attempt at something
like that gave an ICE...
Yeah, I figured there would be more to do. More tests are welcome. :)
Jason
OK.
Jason
Jason, can you take a look? Thanks.
Ian
On Tue, Aug 19, 2014 at 3:46 AM, Gary Benson wrote:
> Hi all,
>
> I just retested this patch. The crash it fixes is still there,
> and the patch still fixes it. Is this ok to commit?
>
> Cheers,
> Gary
>
> Andrew Burgess wrote:
>> In two places when a s
I've applied the attached patch to fix PR target/62111 which
is a sh64 specific 4.9/5 regression.
It seems that *zero_extendhisi2_media makes reload unhappy
with permitting (truncate (pseudo_reg)) when pseudo_reg can
be substituted by mem. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
f
On Sun, Aug 24, 2014 at 05:47:23PM -0400, Trevor Saunders wrote:
> On Sun, Aug 24, 2014 at 01:58:52PM -0700, Andrew Pinski wrote:
> > On Sun, Aug 24, 2014 at 1:42 PM, Josh Triplett
> > wrote:
> > > handle_section_attribute contains many levels of nested conditionals and
> > > branching code flow
On Sun, Aug 24, 2014 at 01:58:52PM -0700, Andrew Pinski wrote:
> On Sun, Aug 24, 2014 at 1:42 PM, Josh Triplett wrote:
> > handle_section_attribute contains many levels of nested conditionals and
> > branching code flow paths, with the error cases sometimes in the else
> > case and sometimes in th
On Sun, Aug 24, 2014 at 01:58:52PM -0700, Andrew Pinski wrote:
> On Sun, Aug 24, 2014 at 1:42 PM, Josh Triplett wrote:
> > handle_section_attribute contains many levels of nested conditionals and
> > branching code flow paths, with the error cases sometimes in the else
> > case and sometimes in th
On Sun, Aug 24, 2014 at 1:42 PM, Josh Triplett wrote:
> handle_section_attribute contains many levels of nested conditionals and
> branching code flow paths, with the error cases sometimes in the else
> case and sometimes in the if case. Simplify the code flow into a series
> of potential failure
handle_section_attribute contains many levels of nested conditionals and
branching code flow paths, with the error cases sometimes in the else
case and sometimes in the if case. Simplify the code flow into a series
of potential failure cases ending with the successful path, with no
nesting and no
On Fri, 11 Jul 2014, Martin Liška wrote:
2014-07-11 Martin Liska
* doc/invoke.texi: Added missing options to options
that control optimization. Missing -foptimize-strlen option
introduced.
I applied the following patch on top of yours, adding @code in
one, and @option in another
>> but helpful for gfortran users ?
>The problem is that a similar sentence would then need to be
>added to other intrinsic subroutines/functions where an actual
>argument might produce a result that is out-of-range of the
>representable entity.
So, I could remove the sentence if there is conse
On Sun, Aug 24, 2014 at 03:58:42PM +, VandeVondele Joost wrote:
> >> +of @var{A} and whose sign is the same as the sign of @var{A}. The result
> >> +is undefined if it can not be represented as an @code{INTEGER} of the
> >> +given @code{KIND}.
> >
> >The last sentence above is not needed.
>
>> +of @var{A} and whose sign is the same as the sign of @var{A}. The result
>> +is undefined if it can not be represented as an @code{INTEGER} of the
>> +given @code{KIND}.
>
>The last sentence above is not needed.
but helpful for gfortran users ?
> There is a general
> prohibition in 13.7.1 a
On Sun, Aug 24, 2014 at 12:47:18PM +, VandeVondele Joost wrote:
> > One small ask: these lines are too long (already before your patch);
> > can you please reformat those lines your patch touches to <80 columns?
>
> sure:
>
> +of @var{A} and whose sign is the same as the sign of @var{A}. Th
Hi,
Trevor Saunders wrote:
>> -static gfc_expr ***expr_array;
>> -static int expr_size, expr_count;
>> +static vec expr_array = vec();
>
> that's usually written as just static vec foo; vec doesn't actually
> have ctors, and 0 initialization works fine.
Fixed (also below).
>> + // doloop_li
> One small ask: these lines are too long (already before your patch);
> can you please reformat those lines your patch touches to <80 columns?
sure:
Index: intrinsic.texi
===
--- intrinsic.texi (revision 214408)
+++ intrinsic.
On Sun, 24 Aug 2014, VandeVondele Joost wrote:
> A doc change to refine wording for result value of int, avoiding the
> word range and using magnitude as does the standard. Mentions undefined
> behavior.
>
> 2014-08-24 Joost VandeVondele
>
> PR fortran/62245
> * intrinsic.texi (
A doc change to refine wording for result value of int, avoiding the word range
and using magnitude as does the standard. Mentions undefined behavior.
2014-08-24 Joost VandeVondele
PR fortran/62245
* intrinsic.texi (INT): clarify result and undefined behavior.
Index: intrins
Hi,
The attached patch fixes PR 61996 and does some minor documentation
fixes. Committed to trunk (r214406), 4.9 (r214407) and 4.8 (r214408).
Tested with 'make all', verifying that the new test case passes for m1*
and m2* targets and with 'make info dvi pdf'.
Cheers,
Oleg
gcc/ChangeLog:
On 24/08/14 10:45, Gerald Pfeifer wrote:
I am wondering, should we consider merging i686-pc-linux-gnu and
i686-unknown-linux-gnu? It's practically the same, isn't it?
I did consider it, but I don't think it's really a problem to have them
both listed and since I don't really know what the diff
PING: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01709.html
On 18 August 2014 00:03, Manuel López-Ibáñez wrote:
> Following a suggestion in PR16564, this patch makes excessive template
> instantiation depth a fatal error. In fact, this allows simplifying
> the code a lot, just by printing firs
On Sun, 17 Aug 2014, Tom G. Christensen wrote:
> Latest results for 4.9.x
>
> -tgc
>
> Testresults for 4.9.1:
> arm-unknown-linux-gnueabihf
> hppa2.0w-hp-hpux11.11
> hppa64-hp-hpux11.11
> i386-pc-solaris2.9
> i686-pc-linux-gnu
> powerpc-apple-darwin8.11.0
> sparc-sun-solaris2.9
>
On Sun, Aug 24, 2014 at 12:47:17AM +0200, Thomas Koenig wrote:
> Hello world,
>
> the attached patch uses the vec<> templates instead of the
> home-grown memory management.
>
> Did I get the style right? I was a bit confused because, with
> the declarations used in the patch, using the vec_safe_
Thank you for the report!
> (1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect
> "vectorized 2 loops" 1
>
> before I saw
>
> [Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect
> /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: ===
> vect_mark_stmt
26 matches
Mail list logo
