On Wed, 28 Sep 2016, Bernd Edlinger wrote:
> Hi,
>
> this test does fail because a non-existent dump file is referenced in
> the dg-final.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> OK for trunk?
Ok.
Richard.
On Tue, Sep 27, 2016 at 4:01 PM, Pierre-Marie de Rodat
wrote:
> On 09/07/2016 11:30 AM, Richard Biener wrote:
>>
>> That said, with the idea of early debug in place and thus giving
>> more responsibility to the frontends I wonder in what order the Ada
>> FE calls debug_hooks.early_global_decl ()?
On Tue, 27 Sep 2016, Rainer Orth wrote:
> Hi Richard,
>
> >> this patch introduced many pch assembly comparison failures on Solaris
> >> (both sparc and x86, 32 and 64-bit, /bin/as only), like
> >>
> >> FAIL: gcc.dg/pch/common-1.c -O3 -g assembly comparison
> >> FAIL: gcc.dg/pch/common-1.c -
On Wed, 28 Sep 2016, Richard Biener wrote:
> On Tue, 27 Sep 2016, Rainer Orth wrote:
>
> > Hi Richard,
> >
> > >> this patch introduced many pch assembly comparison failures on Solaris
> > >> (both sparc and x86, 32 and 64-bit, /bin/as only), like
> > >>
> > >> FAIL: gcc.dg/pch/common-1.c -O3
On Tue, 27 Sep 2016, Jason Merrill wrote:
> OK.
May I ping https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01835.html then
on which this depends?
Thanks,
Richard.
> On Tue, Sep 27, 2016 at 9:47 AM, Richard Biener wrote:
> >
> > This is moving break_out_includes (aka -feliminate-dwarf2-dups handl
Hi Alan,
On Wed, Sep 28, 2016 at 10:41:45AM +0930, Alan Modra wrote:
> Extend this attribute to cover long double ABIs, for 64-bit too. The
> idea is that the linker should warn if you are linking object files
> with incompatible ABIs, for example IEEE128 long double with IBM long
> double. It's
On Wed, Sep 28, 2016 at 10:43:38AM +0930, Alan Modra wrote:
> compatibility-ldbl.o is compiled with -mlong-double-64. When
> long double .gnu_attribute tags are checked by the linker, it
> complains about the mismatch between this file and others in
> libstdc++.
>
> Bootstrapped and regression te
Hi all,
This patch tries to avoid materialising an immediate
when comparison has shown that it is already loaded.
This is performed during ifcvt and only when the target has the conditional
negate
or inverse optabs, which for now is only aarch64.
Thus for the code:
int
foo (int a, int b)
{
re
On Tue, Sep 27, 2016 at 03:14:51PM -0600, Jeff Law wrote:
> On 09/23/2016 02:21 AM, Segher Boessenkool wrote:
> >--- a/gcc/function.c
> >+++ b/gcc/function.c
> >@@ -5920,9 +5920,7 @@ thread_prologue_and_epilogue_insns (void)
> > edge entry_edge = single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun));
> Could you rebase this onto the current head please. I couldn't get
> this to merge cleanly.
>
Sure, I will come back to you asap.
//Claudiu
Hi!
On Tue, 27 Sep 2016 12:34:46 +0200 (CEST), Richard Biener
wrote:
> --- gcc/dwarf2out.c (revision 240521)
> +++ gcc/dwarf2out.c (working copy)
> @@ -25657,14 +25687,6 @@ dwarf2out_init (const char *filename ATT
> vec_alloc (macinfo_table, 64);
> #endif
>
> - /* Make sure the
On Wed, 28 Sep 2016, Thomas Schwinge wrote:
> Hi!
>
> On Tue, 27 Sep 2016 12:34:46 +0200 (CEST), Richard Biener
> wrote:
> > --- gcc/dwarf2out.c (revision 240521)
> > +++ gcc/dwarf2out.c (working copy)
> > @@ -25657,14 +25687,6 @@ dwarf2out_init (const char *filename ATT
> > vec_al
On 27/09/16 23:28 +, Joseph Myers wrote:
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y), z), and should be a bit more accurate at very l
On 27/09/16 23:50 +0200, Marc Glisse wrote:
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y), z), and should be a bit more accurate at very la
Hi,
in this test case, c-reduce had created various forms of undefined
behaviour, which did only show up on m68k and arm-none-eabi.
Most notably the original problem did only happen when
512/sizeof(basic_string) = 7, but with a non-zero remainder.
In the way that c-reduce used to reduce that stru
On Wed, 28 Sep 2016, Bernd Edlinger wrote:
> Hi,
>
> in this test case, c-reduce had created various forms of undefined
> behaviour, which did only show up on m68k and arm-none-eabi.
>
> Most notably the original problem did only happen when
> 512/sizeof(basic_string) = 7, but with a non-zero re
std::function::swap does swap(_M_functor, x._M_functor) which
exchanges the underlying bytes of the two _Any_data PODs using that
type's implicit assignment operator. However, unlike using placement
new to construct an object in the storage, simply memcpying the bytes
doesn't change the effective
On Wed, Sep 28, 2016 at 12:57 PM, Jonathan Wakely wrote:
> std::function::swap does swap(_M_functor, x._M_functor) which
> exchanges the underlying bytes of the two _Any_data PODs using that
> type's implicit assignment operator. However, unlike using placement
> new to construct an object in the
On 28/09/16 13:14 +0200, Richard Biener wrote:
On Wed, Sep 28, 2016 at 12:57 PM, Jonathan Wakely wrote:
std::function::swap does swap(_M_functor, x._M_functor) which
exchanges the underlying bytes of the two _Any_data PODs using that
type's implicit assignment operator. However, unlike using pl
From: claziss
2016-09-28 Claudiu Zissulescu
* MAINTAINERS (Reviewers): Add myself.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240569
138bc75d-0d04-0410-961f-82ee72b054a4
---
ChangeLog | 4
MAINTAINERS | 1 +
2 files changed, 5 insertions(+)
diff --git a/ChangeLog b/Cha
On 09/27/16 09:30, Bernd Schmidt wrote:
On 09/27/2016 12:58 PM, Nathan Sidwell wrote:
In working on some new code I got sufficiently frustrated to implement
pretty printing on internal function discriminators, as I think one of
you suggested a while back. With this patch we get:
.data_dep.2 =
On Wed, 28 Sep 2016, Jonathan Wakely wrote:
On 27/09/16 23:28 +, Joseph Myers wrote:
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y), z
I am testing the following patch to avoid useless VRP range allocations
when we just ask for varying on stmts we don't know how to handle.
I think it should fix the PR where we end up assigning to the
static const vr_const_varying returned by get_value_range in the early VRP
context.
Eventually t
The following patch makes VN not choke on code that stores to readonly
memory it knows the constant value of. I took the liberty to clean up
the surrounding code a bit as well.
Bootstrap / regtest in progress on x86_64-unknown-linux-gnu.
Richard.
2016-09-28 Richard Biener
PR tree-o
On 28/09/16 13:31 +0200, Marc Glisse wrote:
On Wed, 28 Sep 2016, Jonathan Wakely wrote:
On 27/09/16 23:28 +, Joseph Myers wrote:
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y +
Currently strided SLP vectorization creates vector constructors composed
of vector elements. This is a constructor form that is not handled
specially by the expander but it gets expanded via piecewise stores
to scratch memory and a load of that scratch memory. This is obviously
bad on any modern
On Tue, Sep 27, 2016 at 12:08:46AM +0200, Jan-Benedict Glaw wrote:
> Hi Martin,
>
> On Thu, 2016-09-08 13:03:12 -0600, Martin Sebor wrote:
> > Attached is another update to the patch to address the last round
> > of comments and suggestions, most notably to:
> [...]
>
> with the currently commit
Hi,
On Tue, 27 Sep 2016, Tom Tromey wrote:
> The point of the warning is to make code more robust. But accepting any
> comment like "Don't fall through" is not more robust, but rather an
> error waiting to happen; as IIUC the user has no way to detect this
> case.
>
> I think it's better for
On Wed, 28 Sep 2016, Jonathan Wakely wrote:
> On 27/09/16 23:28 +, Joseph Myers wrote:
> > On Tue, 27 Sep 2016, Jonathan Wakely wrote:
> >
> > > This adds the new 3D std::hypot() functions. This implementation seems
> > > to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
>
On 28/09/16 12:40 +, Joseph Myers wrote:
On Wed, 28 Sep 2016, Jonathan Wakely wrote:
On 27/09/16 23:28 +, Joseph Myers wrote:
> On Tue, 27 Sep 2016, Jonathan Wakely wrote:
>
> > This adds the new 3D std::hypot() functions. This implementation seems
> > to be faster than the naïve sqrt(x
This change drops forced alignment to 8 if requested alignment is higher
than 8: before the patch, -falign-functions=9 was generating
.p2align 4,,8
.p2align 3
which means: "align to 16 if the skip is 8 bytes or less; else align to 8".
After this change, ".p2align 3" is not emitted
These patches are for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"
This is version 4 of the patch set. Changes since version 3:
* Improved documentation in invoke.texi
* Fixed x86-specific calculation of default N2 value:
previous version was d
falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte
alignment
of functions runs fastest (he tried many other possibilites):
this way, after a call CPU can fetch a lot of insns in the first cacheline fill.
However, developers are less tha
* PING *
2016-09-21 19:03 GMT+01:00 Alessandro Fanfarillo :
> Thanks Andre.
>
> 2016-09-19 9:55 GMT-06:00 Andre Vehreschild :
>> Hi Alessandro,
>
>> The if in resolve.c at 8837: resolve_failed_image (... is intentional? It is
>> doing nothing. So do you plan to add more code, or will there never b
>
> This looks good to me.
>
> Thanks,
> Andrew
>
Committed r240576.
Thank you for your review,
Claudiu
The following patch implements patterns to catch x / abs (x)
and x / -x, taking advantage of undefinedness at x == 0 as
opposed to the PR having testcases with explicit != 0 checks.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2016-09-28 Richard Biener
PR middle
This fixes the original request in PR77399, better handling of
typedef int v4si __attribute__((vector_size(16)));
typedef float v4sf __attribute__((vector_size(16)));
v4sf vec_cast(v4si f)
{
return (v4sf){f[0], f[1], f[2], f[3]};
}
which nicely fits into the existing simplify_vector_construc
The following adds a pattern to optimize MAX (a, -a) to abs (a).
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2016-09-28 Richard Biener
PR middle-end/55152
* match.pd: Add max(a,-a) -> abs(a) pattern.
* gcc.dg/pr55152.c: New testcase.
Index: gc
OK.
> This looks like a good improvement to me.
>
> Thanks,
> Andrew
>
Committed r240577
Thank you for your review,
Claudiu
OK, thanks.
Jason
> From: DJ Delorie
> Cc: f...@deneb.enyo.de, gcc-patches@gcc.gnu.org, seze...@gmail.com
> Date: Tue, 27 Sep 2016 15:23:46 -0400
>
> > Why would it need to
> > change? It's perfectly okay to link GPL code with LGPL code, we do
> > this all the time with libgcc, no? Or am I missing something?
>
On Tue, Sep 27, 2016 at 11:10 AM, Bernd Edlinger
wrote:
> On 09/27/16 16:42, Jason Merrill wrote:
>> On Tue, Sep 27, 2016 at 10:28 AM, Bernd Edlinger
>> wrote:
>>> On 09/27/16 16:10, Florian Weimer wrote:
* Bernd Edlinger:
>> “0 << 0” is used in a similar context, to create a zero c
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, e...@gnu.org, f...@deneb.enyo.de
> Date: Tue, 27 Sep 2016 15:45:28 -0400
>
>
> I wonder if us relicensing our modified copy would apply to your old
> copy. I mean, are we sure RMS knows you're also relicensing an old
> copy, and that the current
* Eli Zaretskii:
> If my arithmetics is correct, about 70% of its files is LGPL, the
> rest GPL. Which doesn't keep many GNU projects under GPL from using
> Gnulib.
Sorry, I don't understand. Surely anything released under the LGPL by
the FSF can be upgraded to the current GPLv3? First upgrade
I think this broke g++.dg/ext/builtin10.C.
Jason
In my recent patch for tile clauses, I noticed some tile tests didn't appear to
fail, even though the loops they tiled were ill formed. I figured I'd find out
why in the fullness of time.
Didn't take long for time to be full. The omp_for parsing routines had no
knowledge of tile, so did not
ENOPATCH
2016-09-28 Nathan Sidwell
c/
* c-parser.c (c_parser_omp_for_tiling): Accept tiling constructs.
cp/
* parser.c (cp_parser_omp_for_loop): Deal with tile clause. Don't
emit a parse error about missing for after already emitting
one. Use more conventional for idiom for unbounded
> "Michael" == Michael Matz writes:
Michael> Not accepting
Michael> /* And here we intentionally fall through because ... */
Michael> and forcing users to replace this by:
Michael> /* fallthrough */
Michael> is not robust either. It's actually actively lowering robustness of
code,
Mich
> Sorry, I don't understand. Surely anything released under the LGPL by
> the FSF can be upgraded to the current GPLv3? First upgrade to the
> latest LGPL, then switch over to the GPLv3?
That seems correct to me.
> From: Florian Weimer
> Cc: DJ Delorie , gcc-patches@gcc.gnu.org, seze...@gmail.com
> Date: Wed, 28 Sep 2016 16:43:53 +0200
>
> * Eli Zaretskii:
>
> > If my arithmetics is correct, about 70% of its files is LGPL, the
> > rest GPL. Which doesn't keep many GNU projects under GPL from using
> >
Jason Merrill wrote:
> I think this broke g++.dg/ext/builtin10.C.
That's odd. It appears if you add a fold in gimple-fold.c, it no longer calls
the
folding code in builtins.c. No idea what the idea behind that is (especially
since
there are other builtins that appear in both files), but this sim
On Thu, Aug 18, 2016 at 5:33 AM, Pierre-Marie de Rodat
wrote:
> A check in dwarf2out_imported_module_or_decl prevents valid strict
> DWARF2 constructs such as DW_TAG_imported_declaration from being emitted
> in dwarf2out_imported_module_or_decl_1.
>
> The latter already protects the emission of ne
OK.
On Wed, Sep 28, 2016 at 11:43 AM, Wilco Dijkstra wrote:
> Jason Merrill wrote:
>> I think this broke g++.dg/ext/builtin10.C.
>
> That's odd. It appears if you add a fold in gimple-fold.c, it no longer calls
> the
> folding code in builtins.c. No idea what the idea behind that is (especially
> Le 28 sept. 2016 à 17:44, Jason Merrill a écrit :
>
> On Thu, Aug 18, 2016 at 5:33 AM, Pierre-Marie de Rodat
> wrote:
>> A check in dwarf2out_imported_module_or_decl prevents valid strict
>> DWARF2 constructs such as DW_TAG_imported_declaration from being emitted
>> in dwarf2out_imported_modu
On 09/28/2016 05:41 AM, Richard Biener wrote:
Currently strided SLP vectorization creates vector constructors composed
of vector elements. This is a constructor form that is not handled
specially by the expander but it gets expanded via piecewise stores
to scratch memory and a load of that scra
This patch that Bernd put in PR77718 seems to be fine. Bootstrap and
regtest done on powerpc64le, no new failures. Ok for trunk?
2016-09-28 Bernd Schmidt
* builtins.c (expand_builtin_memcmp): don't swap args unless
result is only being compared with zero.
Index: builtins.c
===
Hi all,
This is v4 of the pass. It addresses feedback by Bernhard, including typo fixes
and
skipping of debug statements.
Also, I've extended it to handle the case from PR 23684 and included that
testcase
in the patch. Merging now triggers more often.
I've also added purging of dead EH edges t
Florian Weimer writes:
> Sorry, I don't understand. Surely anything released under the LGPL by
> the FSF can be upgraded to the current GPLv3? First upgrade to the
> latest LGPL, then switch over to the GPLv3?
>
> (I assume that the FSF releases their works under the “any later
> version” regime
On Sep 28, 2016, at 10:54 AM, Kyrill Tkachov
wrote:
>
> Hi all,
>
> This is v4 of the pass. It addresses feedback by Bernhard, including typo
> fixes and
> skipping of debug statements.
> Also, I've extended it to handle the case from PR 23684 and included that
> testcase
> in the patch. Mer
On 28/09/16 16:59, Bill Schmidt wrote:
On Sep 28, 2016, at 10:54 AM, Kyrill Tkachov
wrote:
Hi all,
This is v4 of the pass. It addresses feedback by Bernhard, including typo fixes
and
skipping of debug statements.
Also, I've extended it to handle the case from PR 23684 and included that
tes
On 09/28/2016 02:48 AM, Kyrill Tkachov wrote:
Hi all,
This patch tries to avoid materialising an immediate
when comparison has shown that it is already loaded.
This is performed during ifcvt and only when the target has the
conditional negate
or inverse optabs, which for now is only aarch64.
Th
On 09/28/16 16:41, Jason Merrill wrote:
> On Tue, Sep 27, 2016 at 11:10 AM, Bernd Edlinger
> wrote:
>> On 09/27/16 16:42, Jason Merrill wrote:
>>> On Tue, Sep 27, 2016 at 10:28 AM, Bernd Edlinger
>>> wrote:
On 09/27/16 16:10, Florian Weimer wrote:
> * Bernd Edlinger:
>
>>> “0 <<
On 09/22/2016 02:07 PM, Jakub Jelinek wrote:
Hi!
I've noticed lots of vec_safe_length (CONSTRUCTOR_ELTS (...)) uses
in the sources, which IMHO are less readable than the much more often
used CONSTRUCTOR_NELTS (...) macro that does the same thing.
Bootstrapped/regtested on x86_64-linux and i686-
On Wed, Sep 21, 2016 at 10:42:03AM +0100, James Greenhalgh wrote:
> On Tue, Sep 13, 2016 at 10:31:28AM +0100, James Greenhalgh wrote:
> > On Tue, Sep 06, 2016 at 10:19:50AM +0100, James Greenhalgh wrote:
> > > This patch adds patterns for conversion from 64-bit integer to 16-bit
> > > floating-poin
On 09/21/2016 02:52 AM, Bin.Cheng wrote:
On Wed, Sep 14, 2016 at 5:43 PM, Jeff Law wrote:
On 09/14/2016 07:21 AM, Richard Biener wrote:
On Tue, Sep 6, 2016 at 8:52 PM, Bin Cheng wrote:
Hi,
This is the main patch improving control flow graph for vectorized loop.
It generally rewrites loop p
On Thu, Sep 22, 2016 at 05:55:21PM +, Joseph Myers wrote:
> On Thu, 22 Sep 2016, James Greenhalgh wrote:
>
> > The relaxation isn't portable, and keeping it in place is tricky, so this
> > patch removes it, and poisons TARGET_FLT_EVAL_METHOD_NON_DEFAULT in
> > system.h to prevent future use.
>
On 09/21/2016 06:59 PM, David Malcolm wrote:
On Mon, 2016-09-19 at 11:31 -0600, Jeff Law wrote:
On 09/16/2016 03:19 PM, David Malcolm wrote:
When possible I don't think we want the tests to be target
specific.
Hmm, I'm probably about to argue for Bernd's work... The 71779
testcase
is a great
On 09/21/2016 01:01 PM, David Malcolm wrote:
Presumably we could use "v" rather than "p" as the prefix for the
first
5 pseudos (up to LAST_VIRTUAL_REGISTER), doing any adjustment at load
time, rather than at dump time. So the above example would look
like:
(reg/f:DI v82 virtual-stack-vars)
On 09/28/2016 06:23 PM, Jeff Law wrote:
(reg/i:SI h0 ax)
(reg/i:SF h21 xmm0)
(Replying to myself, in the hope of better demonstrating the idea)
The following patch implements this idea for RTL dumps, so that all REGNO
values in dumps get a one character prefix: 'h' for hard registers, 'v'
On 09/28/2016 03:04 AM, Segher Boessenkool wrote:
+static void
+place_prologue_for_one_component (unsigned int which, basic_block head)
+{
+ /* The block we are currently dealing with. */
+ basic_block bb = head;
+ /* Is this the first time we visit this block, i.e. have we just gone
+
Hi Jeff,
On 28/09/16 17:07, Jeff Law wrote:
On 09/28/2016 02:48 AM, Kyrill Tkachov wrote:
Hi all,
This patch tries to avoid materialising an immediate
when comparison has shown that it is already loaded.
This is performed during ifcvt and only when the target has the
conditional negate
or inve
On 09/28/2016 10:30 AM, Bernd Schmidt wrote:
On 09/28/2016 06:23 PM, Jeff Law wrote:
(reg/i:SI h0 ax)
(reg/i:SF h21 xmm0)
(Replying to myself, in the hope of better demonstrating the idea)
The following patch implements this idea for RTL dumps, so that all
REGNO
values in dumps get a one
On 09/28/2016 06:36 PM, Jeff Law wrote:
A "p" prefix for pseudos might still be a good idea, but there's still
the issue of a real "p0" register name causing confusion.
So how do you think we should deal with distinguishing between the
different registers that may appear in a dump file?
I thin
On 09/28/2016 10:54 AM, Kyrill Tkachov wrote:
> +fstore-merging
> +Common Var(flag_store_merging) Optimization
> +Use the tree store merging pass.
> +
Did you purposely leave off "Report" for this option? I noticed the option
didn't show up in the "options enabled:" section of the .s file when
-
On Wed, 28 Sep 2016, Alan Modra wrote:
> > I'd expect libraries such as libstdc++ and libgcc (generally, all compiler
> > and libc libraries) to be set up in such a way that they will work with
> > all long double choices in user code (via mangling and headers mapping
> > access to long double
On Wed, 28 Sep 2016, Richard Biener wrote:
> Index: gcc/testsuite/gcc.dg/pr55152.c
> ===
> --- gcc/testsuite/gcc.dg/pr55152.c(revision 0)
> +++ gcc/testsuite/gcc.dg/pr55152.c(working copy)
> @@ -0,0 +1,13 @@
> +/* { dg-do comp
On Wed, 28 Sep 2016, James Greenhalgh wrote:
> On Thu, Sep 22, 2016 at 05:55:21PM +, Joseph Myers wrote:
> > On Thu, 22 Sep 2016, James Greenhalgh wrote:
> >
> > > The relaxation isn't portable, and keeping it in place is tricky, so this
> > > patch removes it, and poisons TARGET_FLT_EVAL_MET
On 28 September 2016 at 16:45, Jason Merrill wrote:
> I think this broke g++.dg/ext/builtin10.C.
>
> Jason
It also broke:
gc gcc.c-torture/execute/builtins/strchr.c execution, -O1
c.c-torture/execute/builtins/strchr.c (execution) on arm* and aarch64*
Christophe
A system_clock::time_point can't be used to represent all valid values
of a 64-bit time_t because nearly half the bits are used up for the
nanoseconds part. This makes filesystem::last_write_time() check the
time_t values and report an error if it can't be converted to the
time_point type. This me
My earlier patch to inline runtime.getcallerpc and runtime.getcallersp
when compiling the runtime package was incomplete, because it only
took effect when passing the -fcompiling-runtime option, and that
option is not passed when testing the runtime package. This patch by
Than McIntosh fixes that
Committed to trunk.
commit 6246cb3120548a1dfc62bf7aa538f3e5538123c9
Author: Jonathan Wakely
Date: Wed Sep 28 19:03:43 2016 +0100
* include/std/chrono (system_clock): Fix typo in comment.
diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index f29d8e1..11e
On Tue, Sep 27, 2016 at 10:15:40PM -0700, Jerry DeLisle wrote:
> I plan to commit the attached patch in the next few days. Fairly simple.
>
> Regression tested on x86-64.
>
Looks ok to me.
--
Steve
Hello!
Attached patch removes obsolete register allocator workaround from
gcc-4.6 era. The problem was fixed in gcc-4.7+.
2015-09-28 Uros Bizjak
* config/i386/cpuinfo.c (__get_cpuid_output): Remove.
(__cpu_indicator_init): Call __get_cpuid, not __get_cpuid_output.
Bootstrapped and r
Hi, Jason
This patch added testcases g++.dg/ext/vector32.C and vector32a.C, but
there is no gcc/testsuite/ChangeLog entry.
The testcases are failing on AIX with a strange ICE:
src/gcc/testsuite/g++.dg/ext/vector32.C: In function 'int main()':
src/gcc/testsuite/g++.dg/ext/vector32.C:18:1: interna
On 09/24/2016 10:39 AM, Andreas Schwab wrote:
I'm still seeing these failures on m68k:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 358)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1222)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (tes
On Mon, Sep 26, 2016 at 10:01:27AM -0400, Fritz Reese wrote:
>
> Attached is a patch extending the GNU Fortran front-end to support
> some additional math intrinsics, enabled with a new compile flag
> -fdec-math. The flag adds the COTAN intrinsic (cotangent), as well as
> degree versions of all tr
On Sep 27, 2016, Ozkan Sezer wrote:
> FYI: What I originally wanted was an authorization _for me_ to use
> filenames.h in LGPL projects with LGPL license notice; the version
> I use is modified (not refer to any external code other than libc,
> i.e. only macros and inlines) and doesn't include ha
On Aug 10, 2016, at 2:11 AM, Martin Liška wrote:
>
> Following patch clarifies usage of ctor and dtor attributes for Objective C.
> Patch survives (on x86_64-linux-gnu):
>
> make -k check-objc RUNTESTFLAGS="execute.exp"
>
> Ready for trunk?
Ok.
On Wed, Sep 28, 2016 at 09:29:01AM -0600, Tom Tromey wrote:
> > "Michael" == Michael Matz writes:
>
> Michael> Not accepting
> Michael> /* And here we intentionally fall through because ... */
> Michael> and forcing users to replace this by:
> Michael> /* fallthrough */
> Michael> is not
The attached patch and ChangeLog entries are for the
backporting of 25 patches from trunk to the 6-branch.
The bugzilla PR's contained in the patch are
fortran/41922 fortran/60774 fortran/61318 fortran/68566 fortran/69514
fortran/69867 fortran/69962 fortran/70006 fortran/71067 fortran/71730
On 09/28/2016 02:15 PM, Michael Matz wrote:
P.S.: Initially I even wanted to argue that the mere existence of _any_
comment before a case label would disable the warning. I don't have the
numbers but I bet even that version would have found the very same bugs
that the picky version has.
Sounds
Hi!
I'd like to ping the
http://gcc.gnu.org/ml/gcc-patches/2016-09/msg01436.html
patch, containing various fixes for gimple-ssa-sprintf.c.
If the 0 < var to var > 0 changes are deemed too controversial, I can
separate them from the other changes.
Jakub
On 09/28/2016 09:24 PM, Jakub Jelinek wrote:
I'd like to ping the
http://gcc.gnu.org/ml/gcc-patches/2016-09/msg01436.html
patch, containing various fixes for gimple-ssa-sprintf.c.
If the 0 < var to var > 0 changes are deemed too controversial, I can
separate them from the other changes.
I'd l
On 27/09/2016 12:32, Jonathan Wakely wrote:
Index: include/debug/safe_base.h
===
--- include/debug/safe_base.h(revision 240509)
+++ include/debug/safe_base.h(working copy)
@@ -121,11 +121,11 @@
void
_M_detach();
+
On 09/27/2016 10:43 PM, Jeff Law wrote:
On 09/27/2016 04:50 PM, Martin Sebor wrote:
The attached patch corrects a couple of typos in argument numbers
in the handling of __builtin__vsnprintf_chk calls in the gimple-
ssa-sprintf pass, and another couple of typos in the test for
this that were mask
Hi
Here is the patch to share a mutex pool between debug mode and
shared_ptr implementation. It saves 392 bytes on generated .so and will
make sure that fixing false sharing will impact both usages.
I preferred to leave implementation in shared_ptr.cc to avoid
introducing another tra
On 9/28/16, Alexandre Oliva wrote:
> On Sep 27, 2016, Ozkan Sezer wrote:
>
>> FYI: What I originally wanted was an authorization _for me_ to use
>> filenames.h in LGPL projects with LGPL license notice; the version
>> I use is modified (not refer to any external code other than libc,
>> i.e. only
On 28/09/16 21:30 +0200, François Dumont wrote:
On 27/09/2016 12:32, Jonathan Wakely wrote:
Index: include/debug/safe_base.h
===
--- include/debug/safe_base.h(revision 240509)
+++ include/debug/safe_base.h(working copy)
@@
On 09/28/2016 12:12 PM, Steve Kargl wrote:
The attached patch and ChangeLog entries are for the
backporting of 25 patches from trunk to the 6-branch.
The bugzilla PR's contained in the patch are
fortran/41922 fortran/60774 fortran/61318 fortran/68566 fortran/69514
fortran/69867 fortran/69962
1 - 100 of 117 matches
Mail list logo
