Are exception classes required to support emplace new construction
like that? With this change, Intel's TBB library no longer compiles
because its exception class declares it's own new operator (see
https://github.com/wjakob/tbb/blob/master/include/tbb/tbb_exception.h):
class tbb_exception : publ
Hi,
On 20/10/16 23:15, Jan Hubicka wrote:
Hi Richard,
On 20/10/16 18:41, Richard Biener wrote:
On Thu, 20 Oct 2016, kugan wrote:
On 20/10/16 01:26, Jan Hubicka wrote:
Would excluding weak symbols (I believe I can check DECL_WEAK for this)
good
enough. Or looking for acceptable subset wou
While investigating PR70855 I found a few minor issues.
Attached patch regression tested on x86-64-linux,
M libgfortran/ChangeLog
M libgfortran/io/transfer.c
Committed r241392
2016-10-20 Jerry DeLisle
* io/transfer.c (finalize_transfer): Free format data
On Thu, 2016-10-20 at 17:43 +0200, Bernd Schmidt wrote:
> On 10/20/2016 04:51 PM, David Malcolm wrote:
> >(0|scratch:DI)
> >
> > with the insn as a whole looking like:
> >
> >(cinsn (set (mem/v:BLK (0|scratch:DI) [0 A8])
> > (unspec:BLK [
> >
Committed as "obvious".
Index: ChangeLog
===
--- ChangeLog (revision 241387)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2016-10-20 Steven G. Kargl
+
+ * array.c (gfc_match_array_constructor): Remove set, but unused
+
On Fri, 21 Oct 2016, Uros Bizjak wrote:
> 2016-10-21 Uros Bizjak
>
> * config/i386/i386.c (ix86_fold_builtin): Handle IX86_BUILTIN_INFQ
> and IX86_BUILTIN_HUGE_VALQ here ...
> (ix86_expand_builtin): ... not here.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
On 09/30/2016 07:22 AM, Tamar Christina wrote:
Hi All,
This is v2 of the patch which adds an optimized route to the fpclassify builtin
for floating point numbers which are similar to IEEE-754 in format.
I have addressed most comments from everyone except for two things:
1) Providing a back-end
2016-10-21 Uros Bizjak
* config/i386/i386.c (ix86_fold_builtin): Handle IX86_BUILTIN_INFQ
and IX86_BUILTIN_HUGE_VALQ here ...
(ix86_expand_builtin): ... not here.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: config/i386/i3
On 10/06/2016 11:37 AM, Andris Pavenis wrote:
On 09/08/2016 12:09 PM, Thomas Schwinge wrote:
Hi!
A few review comments:
On Wed, 7 Sep 2016 20:19:20 +0300, Andris Pavenis
wrote:
This patch fixes handling header.gcc in subdirectories when command
line option -remap has been
used.
(I have not
--- gcc/testsuite/c-c++-common/Wduplicated-branches-1.c
+++ gcc/testsuite/c-c++-common/Wduplicated-branches-1.c
@@ -0,0 +1,187 @@
+/* PR c/64279 */
+/* { dg-do compile } */
+/* { dg-options "-Wduplicated-branches -O2" } */
+
+extern void foo (int);
+extern int g;
+extern int a[10];
+
+int
+f (int
I haven't had time to test the patch. I don't see
off hand anything wrong the patch. But, as you've
seen in bugzilla recent IO work has caused some
problem for a few archs. You'll probably need to
keep an eye open for new issues.
--
steve
On Thu, Oct 20, 2016 at 12:32:38PM -0700, Jerry DeLisl
2016-10-20 19:50 GMT+01:00 Jeff Law :
>
> On 10/20/2016 09:28 AM, Jiong Wang wrote:
>>
>> The current code suppose targetm.stack_protect_fail always generate
>> something.
>> But in case one target start to generate NULL_TREE, there will be ICE.
>> This
>> patch adds a simple sanity check to only c
Hi!
I became aware that there are two empty files in the test suite that
are not intentionally empty:
g++.dg/warn/Wconversion-real.C: was intended to be deleted with this
commit, but accidentally only set to empty file.
r150627 | manu | 2009-08-10 19:10:50 +0200 (Mon, 10 Aug 2009) | 12 lines
Cha
Ping (shall I proceed)
On 10/18/2016 04:48 PM, Jerry DeLisle wrote:
Hi Folks,
The attached patch does some minor cleanup and bumps the libgfortran version
number. I have wanted to reorder the dtp structure for many years now. Not
strictly needed but it has bugged me forever.
The bump is neede
On 10/20/2016 08:43 AM, Michael Matz wrote:
Hi,
On Sat, 5 Dec 2015, Jeff Law wrote:
Nit. I don't think you want a comma after "so". And it looks like your
comment got truncated as well.
With the comment above fixed, this is fine for the trunk.
I'm terribly sorry to have dropped the ball h
Bernd Schmidt writes:
> On 10/18/2016 10:30 PM, David Malcolm wrote:
>>
>> I'm not in love with the names I chose in this patch. It does seem odd
>> having an "rtx_reader" class that can't actually read hierarchical rtx.
>>
>> How about "md_reader" as the base class (with responsibility for the
>
On 10/20/2016 08:20 AM, Michael Matz wrote:
Hello,
like analyzed in the PR, combine is able to remove outer subregs that
don't do anything interesting in the context they are used
(simplify_comparison). But that currently happens outside of the loop
that retries simplifications if changes occur
On 10/20/2016 08:37 AM, David Malcolm wrote:
On Thu, 2016-10-20 at 16:24 +0200, Marek Polacek wrote:
On Thu, Oct 20, 2016 at 10:11:55AM -0400, Jason Merrill wrote:
On Wed, Oct 19, 2016 at 7:07 AM, Marek Polacek
wrote:
But since integer csts and various decls
don't carry location info, this wo
On 10/20/2016 08:57 AM, Kyrill Tkachov wrote:
Hi all,
In this PR we've got code like this:
register struct test2_s *g __asm__("x28");
void
do_something ()
{
test_fptr ();
struct test2_s *p1 = 0;
*p1 = *g;
}
And we get an ICE in gcc/ree.c:655 in get_sub_rtx.
The problem is when we try to
Hi!
This is another section that changed completely in DWARF5.
In order to decrease the size of the section, when using num > 0
entries (i.e. .LBBnn/.LBEnn labels), the patch is using DW_RLE_base_address
followed by DW_RLE_offset_pair, but needs to add another DW_RLE_base_address
if there is hot/c
This patch to libgo rewrites the interface code from C to Go.
I started to copy the Go 1.7 interface code, but the gc and gccgo
representations of interfaces are too different. So instead I rewrote
the gccgo interface code from C to Go. The code is largely the same
as it was, but the names are m
On 10/20/2016 09:28 AM, Jiong Wang wrote:
The current code suppose targetm.stack_protect_fail always generate
something.
But in case one target start to generate NULL_TREE, there will be ICE.
This
patch adds a simple sanity check to only call expand if it's not NULL_TREE.
OK for trunk?
gcc/
201
Hi!
I've noticed that the index entry for for_user points into the middle of an
paragraph without a title, fixed thusly, committed as obvious.
2016-10-20 Jakub Jelinek
* doc/gty.texi (for_user): Use @item next to @findex.
--- gcc/doc/gty.texi.jj 2016-01-13 13:28:40.0 +0100
++
Hi!
This patch changes these two manually maintained arrays into normal
vec.h vectors.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-10-20 Jakub Jelinek
* dwarf2out.c (ranges_table): Change into vec *.
(ranges_by_label): Change into vec *.
On Fri, Oct 14, 2016 at 07:31:16PM +0200, Jakub Jelinek wrote:
> This relies on the previous langhook patch (which greatly simplifies it).
>
> I'm only handling variables for now, DW_AT_const_expr is just weird on
> functions/methods, it is supposed to appear only on
> DW_TAG_inlined_subroutine?
>
Hello!
The intrinsic functions __tzcnt_{u16,u32,u64} and _lzcnt_{u16,u32,u64}
have well defined output for zero input, so they should not be
expanded via __builtin_ctz and __builtin_clz builtins.
Attached patch implements special builtins and UNSPECs to protect
these intrinsic functions from opti
On 20/10/16 10:33 -0700, Mike Stump wrote:
On Oct 20, 2016, at 9:34 AM, Jonathan Wakely wrote:
On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
I am considering leaving this in the ARM backend to force people to
think what they want to do about
On Oct 20, 2016, at 9:34 AM, Jonathan Wakely wrote:
>
> On 20/10/16 09:26 -0700, Mike Stump wrote:
>> On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
>>>
>>> I am considering leaving this in the ARM backend to force people to
>>> think what they want to do about thread safety with statics a
On 20 October 2016 at 20:08, Mike Stump wrote:
> So, from a test suite perspective, the correct fix it to make the port just
> work. I have a bare metal port, I test libstdc++.
> I'd be curious to hear from the arm folks about it.
I daresay that would be the correct fix from many other perspec
On Oct 20, 2016, at 9:51 AM, Jonathan Wakely wrote:
> If Every. Single. Test. that uses the libstdc++ library has this
> failure, and the library can't be made to be usable, the answer is
> surely to change the meaning of "dg-do run" to not link+run tests, not
> add a new directive to Every. Singl
On 20 October 2016 at 19:51, Jonathan Wakely wrote:
> add a new directive to Every. Single. Test. (and every single test we
> add in future too!)
Uh, that would be a rather unfortunate burden for every library patch
submitter, and to the maintainer
as well, because we _will_ forget it and then
On 20 October 2016 at 19:34, Jonathan Wakely wrote:
> Either way, I don't think disabling 50% of the testsuite is the
> answer. If you don't like the failures, configure the library to build
> without threadsafe statics, or configure it to depend on libatomic, or
> something else. (We might want n
On 20/10/16 10:40 +0100, Jonathan Wakely wrote:
Please CC the libstdc++ list for libstdc++ patches, this is a
requirement for patch submission, see https://gcc.gnu.org/lists.html
On 20/10/16 09:55 +0200, Christophe Lyon wrote:
Hi,
Several times I have noticed/reported test failures because so
On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
I am considering leaving this in the ARM backend to force people to
think what they want to do about thread safety with statics and C++
on bare-metal systems.
The quoting makes it look like those a
On Wed, Oct 12, 2016 at 9:50 AM, Richard Biener
wrote:
> On Wed, Oct 12, 2016 at 10:29 AM, Bin.Cheng wrote:
>> On Wed, Oct 12, 2016 at 9:12 AM, Richard Biener
>> wrote:
>>> On Tue, Oct 11, 2016 at 5:03 PM, Bin Cheng wrote:
Hi,
Given below test case,
int foo (unsigned short a[], u
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
>
> I am considering leaving this in the ARM backend to force people to
> think what they want to do about thread safety with statics and C++
> on bare-metal systems.
Not quite in the GNU spirit? The port people should decide the best way to g
> Does this fix it? It still works on Linux:
>
> 2016-10-20 Jakub Jelinek
>
> * g++.dg/cpp1z/inline-var1.C (w): Initialize to 64 + 2.
Yes, it does, thanks!
--
Eric Botcazou
On 13/10/16 20:34, Jason Merrill wrote:
> On Tue, Oct 11, 2016 at 9:39 AM, Jakub Jelinek wrote:
>
>> And, as mentioned in the DWARF mailing list, I think we should emit
>> DW_AT_inline on the inline vars (both explicit and implicit - static
>> constexpr data members in C++17 mode). I hope that
On Thu, Oct 20, 2016 at 01:22:16PM +0200, Eric Botcazou wrote:
> If fails because x == 16 and w == 0 on the first invocation to bar but, given
> that w is not modified anywhere else, this seems to be expected.
Does this fix it? It still works on Linux:
2016-10-20 Jakub Jelinek
* g++
On 10/20/2016 04:51 PM, David Malcolm wrote:
(0|scratch:DI)
with the insn as a whole looking like:
(cinsn (set (mem/v:BLK (0|scratch:DI) [0 A8])
(unspec:BLK [
(mem/v:BLK (reuse_rtx 0) [0 A8])
] UNSPEC_MEMO
On 10/20/2016 05:28 PM, Jiong Wang wrote:
This patch makes EXPR_LIST/INST_LIST/INT_LIST insertion bi-directional,
the new
node can be inserted to either the start or the end of the given list.
I can't help but feel that this is somewhat more complicated than it
needs to be.
One thing to note
The current code suppose targetm.stack_protect_fail always generate something.
But in case one target start to generate NULL_TREE, there will be ICE. This
patch adds a simple sanity check to only call expand if it's not NULL_TREE.
OK for trunk?
gcc/
2016-10-20 Jiong Wang
* function.
As discussed on PR middle-end/78016, here is the patch.
This patch makes EXPR_LIST/INST_LIST/INT_LIST insertion bi-directional, the new
node can be inserted to either the start or the end of the given list.
The existed alloc_EXPR_LIST, alloc_INSN_LIST becomes wrapper of new
bi-directional functi
> Hello.
>
> Following patch fixes issue mentioned in $subject. Problem is connected to
> thunks
> that become expanded during WPA phase of LTO.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
> Martin
> >From a41a5b1e3b7451c711c520b38f
Hello.
Following patch fixes issue mentioned in $subject. Problem is connected to
thunks
that become expanded during WPA phase of LTO.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
>From a41a5b1e3b7451c711c520b38f4603c2976a4b02 Mon Sep
Hi,
sorry for the delay. Couple of weeks ago, I have cloned the github
repo, lookaed at the diff against the trunk and reviewed that, which
resulted in the following pile of notes.
I hope they will be at least mostly understandable, if a little bit
disorganized and perhaps sometimes inconsistent
Hi all,
In this PR we've got code like this:
register struct test2_s *g __asm__("x28");
void
do_something ()
{
test_fptr ();
struct test2_s *p1 = 0;
*p1 = *g;
}
And we get an ICE in gcc/ree.c:655 in get_sub_rtx.
The problem is when we try to process the defining insn of register x28 from
On Thu, Oct 20, 2016 at 3:43 PM, Michael Matz wrote:
> Hi,
>
> On Sat, 5 Dec 2015, Jeff Law wrote:
>
>> Nit. I don't think you want a comma after "so". And it looks like your
>> comment got truncated as well.
>>
>> With the comment above fixed, this is fine for the trunk.
>
> I'm terribly sorry
On Thu, 2016-10-20 at 13:02 +0200, Bernd Schmidt wrote:
>
> On 10/20/2016 11:22 AM, Bernd Schmidt wrote:
> > On 10/20/2016 01:49 AM, David Malcolm wrote:
> > >
> > > (b) for all codes for which rtx_equal_p requires pointer
> > > equality, add
> > > some kind of extra ID to the dump, allowing the
Hi,
On Sat, 5 Dec 2015, Jeff Law wrote:
> Nit. I don't think you want a comma after "so". And it looks like your
> comment got truncated as well.
>
> With the comment above fixed, this is fine for the trunk.
I'm terribly sorry to have dropped the ball here, but I've committed this
now after
On 20/10/16 13:08 +0100, Jonathan Wakely wrote:
This patch doesn't change very much, except for adding
std::reinterpret_pointer_cast, but it makes it very easy to add array
support to shared_ptr, as defined for the Library Fundamentals TS by
https://wg21.link/n3920 and in the process of being add
That's not as straightforward on Visium as on other architectures because the
port doesn't (cannot) expose the CC register before reload, so you need to
emit a regular operation as first instruction in the expander and a branch,
which will be split into a compare and a jump after reload; in othe
On Thu, 2016-10-20 at 16:24 +0200, Marek Polacek wrote:
> On Thu, Oct 20, 2016 at 10:11:55AM -0400, Jason Merrill wrote:
> > On Wed, Oct 19, 2016 at 7:07 AM, Marek Polacek
> > wrote:
> > > But since integer csts and various decls
> > > don't carry location info, this works only partially, so the
>
On 10/20/2016 03:55 PM, David Malcolm wrote:
Currently the jump insn in question looks like this:
(cjump_insn (set (pc)
(label_ref 20))
(nil))
With explicit INSN_UIDs it would look like this:
(cjump_insn 13 (set (pc)
(label_r
On Thu, Oct 20, 2016 at 10:11:55AM -0400, Jason Merrill wrote:
> On Wed, Oct 19, 2016 at 7:07 AM, Marek Polacek wrote:
> > But since integer csts and various decls
> > don't carry location info, this works only partially, so the warning
> > warns even for e.g.
> >
> > if (TREE_STATIC (node) || D
On 10/20/2016 04:20 PM, David Malcolm wrote:
What kind of comparison would it do?
Use read-rtl to read the "after" representation and compare it on the
fly to what we actually have after running the pass under test.
Bernd
On Thu, 2016-10-20 at 16:11 +0200, Bernd Schmidt wrote:
> On 10/20/2016 03:55 PM, David Malcolm wrote:
> > Currently the jump insn in question looks like this:
> >
> > (cjump_insn (set (pc)
> > (label_ref 20))
> > (nil))
> >
> > With explicit INSN_UIDs i
Hello,
like analyzed in the PR, combine is able to remove outer subregs that
don't do anything interesting in the context they are used
(simplify_comparison). But that currently happens outside of the loop
that retries simplifications if changes occurred.
When we do that inside the loop as we
Hi Guys,
Whilst experimenting with writing a plugin for gcc I discovered that
I could cause a segfault if I attempted to register a PLUGIN_INFO
callback with any name other than the name of the plugin. The
attached patch fixes this problem and produces an error message
instead.
OK to
On Wed, Oct 19, 2016 at 7:07 AM, Marek Polacek wrote:
> But since integer csts and various decls
> don't carry location info, this works only partially, so the warning
> warns even for e.g.
>
> if (TREE_STATIC (node) || DECL_EXTERNAL (node))
> max_align = MAX_OFILE_ALIGNMENT;
> else
>
> Fixed the testcase.
It passes now, thanks!
--
Eric Botcazou
On 10/20/16 10:05, Markus Trippelsdorf wrote:
>
> Thanks for the commit. But I think the comment is wrong:
>
> + /* We will only warn on unsigned shifts here, because the majority of
>^^
> This should be »signed«.
>
Oops. Thanks for noticing.
This is what I a
On Thu, Oct 20, 2016 at 6:50 AM, Eric Botcazou wrote:
>> Similarly on arm*/aarch64*:
>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/g++.dg/cpp1z/aligned-new7.
>> C:13:41: warning: requested alignment 32 is larger than 16 [-Wattributes]
>
> Likewise on SPARC/Solaris:
>
> aligned-new7.C: In fu
On Thu, 2016-10-06 at 15:30 +0200, Bernd Schmidt wrote:
> On 10/05/2016 06:15 PM, David Malcolm wrote:
> > +;; MEM[(struct isl_obj *)&obj1] = &isl_obj_map_vtable;
> > +(insn 1045 0 1046 2 (set (reg:SI 480)
> > +(high:SI (symbol_ref:SI ("isl_obj_map_vtable")
> > +[flags 0
On Thu, Oct 20, 2016 at 01:36:12AM +0200, Jakub Jelinek wrote:
> This patch adds .debug_loclists and .debug_loclists.dwo
> support for -gdwarf-5 and -gdwarf-5 -gsplit-dwarf.
> The decrease of section size from .debug_loc section to .debug_loclists
> is really nice.
>
> The patch doesn't handle -gd
I noticed that rs6000.c rs6000_assemble_visibility has two of the
visibility keywords swapped. This only is used for ELF with dot
symbols, which are deprecated, so any problems were not apparent, but
it should be fixed.
The function defines the keywords as:
static const char * const visibi
The following fixes PR78051.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2016-10-20 Richard Biener
PR tree-optimization/78051
* tree-vrp.c (evrp_dom_walker::before_dom_children): Update stmt
and mark replaced if folding did something.
*
... and in PTA (fixing some of the missing pt_null's).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2016-10-20 Richard Biener
* tree-ssa-alias.c (ptrs_compare_unequal): Remove code duplication.
Handle decls possibly not bound.
* tree-ssa-st
On 20/10/16 14:01 +0200, Christophe Lyon wrote:
On 20 October 2016 at 11:40, Jonathan Wakely wrote:
Please CC the libstdc++ list for libstdc++ patches, this is a
requirement for patch submission, see https://gcc.gnu.org/lists.html
OK, I thought I wasn't really modifying the lib itself :-)
> Hi Richard,
>
>
> On 20/10/16 18:41, Richard Biener wrote:
> >On Thu, 20 Oct 2016, kugan wrote:
> >
> >>
> >>
> >>On 20/10/16 01:26, Jan Hubicka wrote:
> >Would excluding weak symbols (I believe I can check DECL_WEAK for this)
> >good
> >enough. Or looking for acceptable subset woul
On Wed, Oct 19, 2016 at 6:53 PM, Ian Lance Taylor wrote:
> On Wed, Oct 19, 2016 at 6:23 AM, Richard Biener
> wrote:
>> On Wed, Oct 19, 2016 at 3:17 PM, Ian Lance Taylor wrote:
>>> On Wed, Oct 19, 2016 at 4:30 AM, Richard Biener
>>> wrote:
On Mon, Oct 17, 2016 at 6:54 PM, Ian Lance Taylor
On Thu, 20 Oct 2016, kugan wrote:
> Hi Richard,
>
>
> On 20/10/16 18:41, Richard Biener wrote:
> > On Thu, 20 Oct 2016, kugan wrote:
> >
> > >
> > >
> > > On 20/10/16 01:26, Jan Hubicka wrote:
> > > > > > Would excluding weak symbols (I believe I can check DECL_WEAK for
> > > > > > this)
> >
This patch doesn't change very much, except for adding
std::reinterpret_pointer_cast, but it makes it very easy to add array
support to shared_ptr, as defined for the Library Fundamentals TS by
https://wg21.link/n3920 and in the process of being added to C++17 by
https://wg21.link/p0414r1
The mai
On 20 October 2016 at 11:40, Jonathan Wakely wrote:
> Please CC the libstdc++ list for libstdc++ patches, this is a
> requirement for patch submission, see https://gcc.gnu.org/lists.html
>
OK, I thought I wasn't really modifying the lib itself :-)
>
> On 20/10/16 09:55 +0200, Christophe Lyon wrot
Hi Richard,
On 20/10/16 18:41, Richard Biener wrote:
On Thu, 20 Oct 2016, kugan wrote:
On 20/10/16 01:26, Jan Hubicka wrote:
Would excluding weak symbols (I believe I can check DECL_WEAK for this)
good
enough. Or looking for acceptable subset would work?
I think we should add a symtab he
On 20/10/16 11:12 +0100, Jonathan Wakely wrote:
This let's std::allocator be used in situations like:
std::allocate_shared(std::allocator(), 1);
where a "proto-allocator" is required. The other members such as
allocate() and max_size() don't make sense for void, but construct and
destroy don't
> The test wants to ensure:
> 1) the foo calls in the ctors are invoked in increasing order (this is used
>for inline vars defined in both CUs)
> 2) ensure that the first bar call in the ctors is invoked after foo (5)
> 3) that bar used in ctors (it is used for inline vars defined in one or the
> Agreed, let's do that for starters.
And a small follow-up fix for a blunder.
2016-10-20 Nicolas Roche
* gcc-interface/Makefile (x86-64/Linux): Restore missing pairs.
(x86/Darwin): Likewise.
--
Eric BotcazouIndex: gcc-interface/Makefile.in
=
On 10/20/2016 11:22 AM, Bernd Schmidt wrote:
On 10/20/2016 01:49 AM, David Malcolm wrote:
(b) for all codes for which rtx_equal_p requires pointer equality, add
some kind of extra ID to the dump, allowing the loader to reconstruct
the graph. This could be the pointer itself:
(scratch:DI [
On Thu, Oct 20, 2016 at 12:50:56PM +0200, Eric Botcazou wrote:
> > testsuite/
> > * g++.dg/cpp1z/inline-var1.C: New test.
> > * g++.dg/cpp1z/inline-var1a.C: New test.
> > * g++.dg/cpp1z/inline-var1.h: New file.
>
> This one fails on SPARC/Solaris:
>
> 0xfefcaa58 in _lwp_kill () from /
On 19/10/16 22:35 +0300, Ville Voutilainen wrote:
Do the operator= SFINAE in the return type for optional,
not in the template parameters.
* include/std/optional (operator=(_Up&&)): Move SFINAE
from template parameters to the return type.
(operator=(const optional<_Up>&)): Likewise
> testsuite/
> * g++.dg/cpp1z/inline-var1.C: New test.
> * g++.dg/cpp1z/inline-var1a.C: New test.
> * g++.dg/cpp1z/inline-var1.h: New file.
This one fails on SPARC/Solaris:
0xfefcaa58 in _lwp_kill () from /lib/libc.so.1
(gdb) bt
#0 0xfefcaa58 in _lwp_kill () from /lib/libc.so.1
Hi Janne,
thanks for the fast review.
> Ok, thanks for catching this!
Well, I am quite sure, that I wrote this crab initially.
Committed as r241367.
Regards,
Andre
On Thu, 20 Oct 2016 12:57:38 +0300
Janne Blomqvist wrote:
> On Thu, Oct 20, 2016 at 11:37 AM, Andre Vehreschild wrote:
> Similarly on arm*/aarch64*:
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/g++.dg/cpp1z/aligned-new7.
> C:13:41: warning: requested alignment 32 is larger than 16 [-Wattributes]
Likewise on SPARC/Solaris:
aligned-new7.C: In function 'int main()':
aligned-new7.C:13:41: warning: requested al
On Thu, 20 Oct 2016, Andreas Schwab wrote:
> On Okt 18 2016, Richard Biener wrote:
>
> > * domwalk.c (dom_walker::walk): Use RPO order.
>
> FAIL: gcc.dg/graphite/pr35356-1.c scan-tree-dump graphite "if \\(P_8 >= P_9
> \\+ 1 && P_9 >= 0\\) \\{"
Fixed.
2016-10-20 Richard Biener
I found a problem with this patch--we can't call do_warn_duplicated_branches in
build_conditional_expr, because that way the C++-specific codes might leak into
the hasher. Instead, I should use operand_equal_p, I think. Let me rework
that part of the patch.
Marek
On Okt 18 2016, Richard Biener wrote:
> * domwalk.c (dom_walker::walk): Use RPO order.
FAIL: gcc.dg/graphite/pr35356-1.c scan-tree-dump graphite "if \\(P_8 >= P_9 \\+
1 && P_9 >= 0\\) \\{"
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F
This let's std::allocator be used in situations like:
std::allocate_shared(std::allocator(), 1);
where a "proto-allocator" is required. The other members such as
allocate() and max_size() don't make sense for void, but construct and
destroy don't depend on value_type.
PR libstdc++/78052
On 19/10/16 21:13 +0100, Jonathan Wakely wrote:
The standard says we have to enable shared_from_this for types with
an accessible and unambiguous std::enable_shared_from_this base
class, and we should be able to do that even if the class also has
an experimental::enable_shared_from_this base clas
On Thu, 20 Oct 2016, Jan Hubicka wrote:
> >
> > The following tries to address the inconsistency with folding
> > two addresses based on two decls vs. one pointer vs a decl address
> > caused by the latter not honoring interposition.
> >
> > Honza, is
> >
> > + /* If obj1 is interposable g
On 20/10/16 10:46, Kyrill Tkachov wrote:
Hi Andre,
On 14/10/16 09:25, Andre Vieira (lists) wrote:
Hi there,
This patch makes sure the pure-code tests only run for Cortex-M targets.
I was hoping '![check_effective_target_arm_arm_ok]' would do the trick
but it seems the options passed with RUNT
On Thu, Oct 20, 2016 at 11:37 AM, Andre Vehreschild wrote:
> Hi all,
>
> during hacking in gfortran I found, that for unlimited polymorphic types the
> size type of a char array stored is hard coded to be 4. This small patch
> resolves this by using the better suited constant: gfc_charlen_int_kind
On 20/10/16 10:40 +0100, Jonathan Wakely wrote:
Please CC the libstdc++ list for libstdc++ patches, this is a
requirement for patch submission, see https://gcc.gnu.org/lists.html
CCing ...
On 20/10/16 09:55 +0200, Christophe Lyon wrote:
Hi,
Several times I have noticed/reported test failure
Hi Andre,
On 14/10/16 09:25, Andre Vieira (lists) wrote:
Hi there,
This patch makes sure the pure-code tests only run for Cortex-M targets.
I was hoping '![check_effective_target_arm_arm_ok]' would do the trick
but it seems the options passed with RUNTESTFLAGS take precedence over
the one in th
On Tue, Oct 18, 2016 at 8:35 AM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on the mainline and 6 branch: the compiler now
> generates wrong code for the attached testcase at -O because of an internal
> conflict about boolean types. The sequence is as follows. In .mergephi3:
>
>
>
> The following tries to address the inconsistency with folding
> two addresses based on two decls vs. one pointer vs a decl address
> caused by the latter not honoring interposition.
>
> Honza, is
>
> + /* If obj1 is interposable give up. */
> + if (VAR_P (obj1)
> + && (TRE
Hi Paul,
after looking at your patch again, I understood why these extra copies are
needed. May be a comment would prevent future gfortran hackers from trying to
remove them again.
The patch is ok for me. Thanks for working on this.
Regards,
Andre
On Wed, 19 Oct 2016 20:02:14 +0200
An
Please CC the libstdc++ list for libstdc++ patches, this is a
requirement for patch submission, see https://gcc.gnu.org/lists.html
On 20/10/16 09:55 +0200, Christophe Lyon wrote:
Hi,
Several times I have noticed/reported test failures because some test
cases wouldn't link on arm-none-eabi usin
On Thu, Oct 20, 2016 at 12:50 AM, Eric Botcazou wrote:
>> Because BOOLEAN_TYPE types only have two values as documented in
>> tree.def:
>>
>> /* Boolean type (true or false are the only values). Looks like an
>>INTEGRAL_TYPE. */
>> DEFTREECODE (BOOLEAN_TYPE, "boolean_type", tcc_type, 0)
>
>
On Wed, 19 Oct 2016, Jeff Law wrote:
> On 10/15/2016 11:59 PM, Prathamesh Kulkarni wrote:
> > Hi,
> > After approval from Bernd Schmidt, I committed the patch to remove
> > optab functions for
> > sdivmod_optab and udivmod_optab in optabs.def, which removes the block
> > for divmod patch.
> >
> >
1 - 100 of 109 matches
Mail list logo
