This avoids changing DRs for scatters/gathers in vect_analyze_data_refs
so we can share them across different VF analyses.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. I've
also built SPEC 2k6 on a haswell machine.
simd-lane to go!
Richard.
>From 37c0f2f61d6aa0d3b9b7ae984e22
On Wed, Jun 20, 2018 at 11:32 PM Martin Sebor wrote:
>
> On 06/20/2018 03:14 PM, Tom de Vries wrote:
> > Hi,
> >
> > Consider the test-case from the patch. When compiled with "-O2 -fno-dce
> > -fno-isolate-erroneous-paths-dereference -fno-tree-dce -fno-tree-vrp" and
> > run, we get:
> > ...
> > $
On Thu, Jun 21, 2018 at 1:07 AM David Malcolm wrote:
>
> All/most of the jit.dg testcases are segfaulting on cleanup of
> the 2nd in-process iteration:
>
> PATH=.:$PATH LD_LIBRARY_PATH=. LIBRARY_PATH=. \
> gdb --args \
>testsuite/jit/test-factorial.c.exe
>
> Starting program:
> /home/david/c
On 21/06/18 07:59, Christophe Lyon wrote:
On Tue, 19 Jun 2018 at 10:50, Kyrill Tkachov
wrote:
Hi Christophe,
On 17/06/18 21:23, Christophe Lyon wrote:
On Fri, 15 Jun 2018 at 17:22, Richard Earnshaw (lists)
wrote:
On 15/06/18 15:30, Christophe Lyon wrote:
Hello,
As suggested in [1], the
The original problem was fixed by the patch for PR84546. This patch
fixes a variant that appears in comment #6.
The fix is completely straightforward and described by the comments
and ChangeLogs.
Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
I am not sure that this problem is a regre
On Wed, Jun 20, 2018 at 4:37 PM Eric Botcazou wrote:
>
> > There are fixes in this patch together with the new functionality -
> > can you split
> > those out? I'm thinking of the copy_edges_for_bb hunks as well as
> > the expand_call_inline ones.
>
> Like this?
OK.
Similar factoring of remap_l
Ping!
On 19 June 2018 at 10:16, Paul Richard Thomas
wrote:
> I got caught with a wild goose chase with this one. I tried to get it
> to work before seeing the standard reference in trans-expr.c. In fact,
> it would be impossible to fix because there is no way to resolve
> different instances of t
Hey Kyrill,
I think it should be possible, I'll have a quick look.
Cheers,
Andre
From: Kyrill Tkachov
Sent: Wednesday, June 20, 2018 9:32:50 AM
To: Andre Simoes Dias Vieira; gcc-patches@gcc.gnu.org
Cc: nd; James Greenhalgh; Richard Earnshaw; Marcus Shawc
On 21/06/18 07:36 +0200, François Dumont wrote:
Working on iterator == operator I noticed that a comparison in
_Safe_iterator was inconsistent.
* include/debug/debug.h
Wrong filename in the ChangeLog here.
(_Safe_iterator<>(const _Safe_iterator<_MutableIterator,>& __x)):
Compare
Hi Hongbo,
On 20/06/18 03:54, Hongbo Zhang wrote:
HXT semiconductor's CPU core Phecda, as a variant of Qualcomm qdf24xx,
reuses the same tuning structure and pipeline with it.
This looks ok to me but you'll need approval from the maintainers.
Some comments on the ChangeLog below.
2018-06-19
PR86223 points out that we currently gimplify the testcase inconsistently.
For the incomplete CTORs we use block-clearing while for the complete
one we emit initializations of the individual elements (up to the
limits imposed in following checks).
So the following makes us always use = {}; form
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2018-06-21 Richard Biener
PR tree-optimization/86232
* tree-ssa-loop-niter.c (number_of_iterations_popcount): Adjust
max for constant niter.
* gcc.dg/torture/pr86232.c: New testcase.
diff --g
Hi Kyrill,
It was the Dragon Boat Festival for a short holiday in China, sorry to
reply later.
On 2018/6/14 15:58, Kyrill Tkachov wrote:
> Hi Shaokun,
>
> On 14/06/18 02:09, Shaokun Zhang wrote:
>> This patch adds HiSilicon's an mcpu: tsv110, which supports v8_4A.
>>
>> ---
>> gcc/ChangeLog
This patch adds HiSilicon's an mcpu: tsv110, which supports v8_4A.
It has been tested on aarch64 and no regressions from this patch.
---
gcc/ChangeLog| 8 +++
gcc/config/aarch64/aarch64-cores.def | 3 +
gcc/config/aarch64/aarch64-cost-tables.h | 103 +++
Hi,
this patch frees TYPE_VFIELD which is used only for debug info generation.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* tree.c (free_lang_data_in_type): Free all TYPE_VFIELDs.
Index: tree.c
===
--- tree.c (revisi
On Thu, 21 Jun 2018 at 10:00, Kyrill Tkachov
wrote:
>
>
> On 21/06/18 07:59, Christophe Lyon wrote:
> > On Tue, 19 Jun 2018 at 10:50, Kyrill Tkachov
> > wrote:
> >> Hi Christophe,
> >>
> >> On 17/06/18 21:23, Christophe Lyon wrote:
> >>> On Fri, 15 Jun 2018 at 17:22, Richard Earnshaw (lists)
> >>
On Thu, 21 Jun 2018, Jan Hubicka wrote:
> Hi,
> this patch frees TYPE_VFIELD which is used only for debug info generation.
> Bootstrapped/regtested x86_64-linux, OK?
OK.
Richard.
> Honza
>
> * tree.c (free_lang_data_in_type): Free all TYPE_VFIELDs.
> Index: tree.c
> =
Hi,
Atm this test in pr45882.c:
...
int d = a[i]; /* { dg-final { gdb-test 16 "d" "112" } } */
...
fails as follows with -flto:
...
FAIL: gcc.dg/guality/pr45882.c -O2 -flto -fuse-linker-plugin \
-fno-fat-lto-objects line 16 d == 112
...
In more detail, gdb fails to print the value of
On Thu, 21 Jun 2018, Tom de Vries wrote:
> Hi,
>
> Atm this test in pr45882.c:
> ...
> int d = a[i]; /* { dg-final { gdb-test 16 "d" "112" } } */
> ...
> fails as follows with -flto:
> ...
> FAIL: gcc.dg/guality/pr45882.c -O2 -flto -fuse-linker-plugin \
> -fno-fat-lto-objects line 16
Hi Shaokun,
On 21/06/18 12:07, Zhangshaokun wrote:
Hi Kyrill,
It was the Dragon Boat Festival for a short holiday in China, sorry to
reply later.
On 2018/6/14 15:58, Kyrill Tkachov wrote:
Hi Shaokun,
On 14/06/18 02:09, Shaokun Zhang wrote:
This patch adds HiSilicon's an mcpu: tsv110, which
Hi Kyrill,
On 2018/6/21 20:56, Kyrill Tkachov wrote:
> Hi Shaokun,
>
> On 21/06/18 12:07, Zhangshaokun wrote:
>> Hi Kyrill,
>>
>> It was the Dragon Boat Festival for a short holiday in China, sorry to
>> reply later.
>>
>> On 2018/6/14 15:58, Kyrill Tkachov wrote:
>>> Hi Shaokun,
>>>
>>> On 14/06
Hi,
this patch drops streaming of binfo bits we do not need. We only care
about BINFO_TYPE, BINFO_VTABLE, BASES and BINFO_OFFSET.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* lto-streamer-out.c (DFS::DFS_write_tree_body): Do not stream
BINFO_BASE_ACCESSES and BINFO_VPTR_FIEL
Hi,
this patch drops DECL_ORIGINAL_TYPE streaming and also logic handling
external decls in blocks since we no longer stream them at all.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* lto-streamer-out.c (DFS::DFS_write_tree_body): Do not
stream DECL_ORIGINAL_TYPE.
(DFS
> Hi,
> this patch drops DECL_ORIGINAL_TYPE streaming and also logic handling
> external decls in blocks since we no longer stream them at all.
>
> Bootstrapped/regtested x86_64-linux, OK?
Actually the patch dies with lto-bootstrap :(
0x9c44fc gen_member_die
../../gcc/dwarf2out.c:24947
0x9
On Thu, 21 Jun 2018, Jan Hubicka wrote:
> Hi,
> this patch drops streaming of binfo bits we do not need. We only care
> about BINFO_TYPE, BINFO_VTABLE, BASES and BINFO_OFFSET.
>
> Bootstrapped/regtested x86_64-linux, OK?
OK.
Richard.
> Honza
>
> * lto-streamer-out.c (DFS::DFS_write_tre
On Thu, 21 Jun 2018, Jan Hubicka wrote:
> Hi,
> this patch drops DECL_ORIGINAL_TYPE streaming and also logic handling
> external decls in blocks since we no longer stream them at all.
>
> Bootstrapped/regtested x86_64-linux, OK?
OK.
Thanks,
Richard.
> Honza
>
> * lto-streamer-out.c (DFS
On Thu, 21 Jun 2018, Jan Hubicka wrote:
> > Hi,
> > this patch drops DECL_ORIGINAL_TYPE streaming and also logic handling
> > external decls in blocks since we no longer stream them at all.
> >
> > Bootstrapped/regtested x86_64-linux, OK?
> Actually the patch dies with lto-bootstrap :(
> 0x9c44fc
This simply streams it all.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-06-21 Richard Biener
* lto-streamer-out.c (DFS::DFS_write_tree_body): Update outdated
comment. Follow BLOCK_ABSTRACT_ORIGIN unconditionally.
* tree-streamer-
> > however aren't we supposed to not touch these at late builds? We drop most
> > of TYPE_DECLs in favour
> > of IDENTIFIER_TYPE and thus also throwing away DECL_ORIGINAL_TYPEs.
>
> We keep quite a bit of TYPE_DECLs around for devirt.
I know, but we do not keep them systematicaly enough to make
On Thu, 21 Jun 2018, Richard Biener wrote:
>
> PR86223 points out that we currently gimplify the testcase inconsistently.
> For the incomplete CTORs we use block-clearing while for the complete
> one we emit initializations of the individual elements (up to the
> limits imposed in following check
On 06/20/2018 03:15 PM, Tom de Vries wrote:
> On 06/20/2018 11:59 PM, Cesar Philippidis wrote:
>> Now it follows the formula contained in
>> the "CUDA Occupancy Calculator" spreadsheet that's distributed with CUDA.
>
> Any reason we're not using the cuda runtime functions to get the
> occupancy (s
PR libstdc++/70940
* include/experimental/memory_resource (__resource_adaptor_common):
New base class.
(__resource_adaptor_common::_AlignMgr): Helper for obtaining aligned
pointer from unaligned, and vice versa.
(__resource_adaptor_imp::do_allocate):
On Thu, 21 Jun 2018, Jan Hubicka wrote:
> > > however aren't we supposed to not touch these at late builds? We drop
> > > most of TYPE_DECLs in favour
> > > of IDENTIFIER_TYPE and thus also throwing away DECL_ORIGINAL_TYPEs.
> >
> > We keep quite a bit of TYPE_DECLs around for devirt.
>
> I kno
I recently found two libstdc++ testcases failing on some Solaris hosts
for 32-bit only:
FAIL: 27_io/filesystem/operations/space.cc execution test
FAIL: experimental/filesystem/operations/space.cc execution test
Both file in the same way:
terminate called after throwing an instance of
'std::file
Hi.
Last part of planned clean-up where I declare ::get as PURE.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
>From 540efe3374d649cc8745445a3e6dc1c720fb79ad Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 20 Jun 2018 14:26:48 +0200
Sub
On 21/06/18 16:17 +0200, Rainer Orth wrote:
I recently found two libstdc++ testcases failing on some Solaris hosts
for 32-bit only:
FAIL: 27_io/filesystem/operations/space.cc execution test
FAIL: experimental/filesystem/operations/space.cc execution test
Both file in the same way:
terminate ca
When bootstrapping gcc on Solaris/x86 with gas, there are a couple of
comparison failures:
i386-pc-solaris2.11/amd64/libgcc/avx_savms64f.o differs
i386-pc-solaris2.11/amd64/libgcc/sse_resms64.o differs
i386-pc-solaris2.11/amd64/libgcc/sse_resms64f_s.o differs
and several more.
The differences oc
> and
>
> FAIL: gnat.dg/opt34.adb scan-tree-dump esra "Created a replacement for
> result"
>
> no time to investigate right now, so I'm putting this on hold.
> Eric, can you see if the opt34.adb FAIL is "harmless"?
A bit busy too, and the failure is at most a pessimization in any case, so no
ob
Hi Jonathan,
> No objection to this patch, but I'll just note that we have
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091 suggesting we
> should use LFS for libstdc++ unconditionally.
seems like a wise move to me. The libstdc++.so ABI didn't change on
Solaris either (that possibility had c
On 21/06/18 16:49 +0200, Rainer Orth wrote:
Hi Jonathan,
No objection to this patch, but I'll just note that we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091 suggesting we
should use LFS for libstdc++ unconditionally.
seems like a wise move to me. The libstdc++.so ABI didn't change
Am 2018-06-21 um 16:17 schrieb Rainer Orth:
I recently found two libstdc++ testcases failing on some Solaris hosts
for 32-bit only:
FAIL: 27_io/filesystem/operations/space.cc execution test
FAIL: experimental/filesystem/operations/space.cc execution test
Both file in the same way:
terminate ca
On 21/06/18 15:00 +0100, Jonathan Wakely wrote:
virtual void
- do_deallocate(void* __p, size_t __bytes, size_t __alignment)
+ do_deallocate(void* __p, size_t __bytes, size_t __alignment) noexcept
+ override
{
- using _Aligned_alloc = std::__alloc_rebind<_Alloc, ch
On Thu, Jun 21, 2018 at 09:02:53AM +0100, Paul Richard Thomas wrote:
> The original problem was fixed by the patch for PR84546. This patch
> fixes a variant that appears in comment #6.
>
> The fix is completely straightforward and described by the comments
> and ChangeLogs.
>
> Bootstrapped and r
On Thu, Jun 21, 2018 at 09:03:47AM +0100, Paul Richard Thomas wrote:
> Ping!
>
> > 2018-06-19 Paul Thomas
> >
> > PR fortran/49630
> > * resolve.c (resolve_contained_fntype): Change standard ref.
> > from F95 to F2003: C418. Correct a spelling error in a comment.
> > It is an er
Hi
with -flto -g -O2 -r -nostdlib -flinker-output=nolto-rel I get ICE on:
class a;
namespace b {
template struct c;
struct C {
typedef a d;
};
void e();
}
template class g : f {
public:
template g(i);
};
class a {
long k;
};
namespace b {
template <> struct c { template static a l(j, h);
> Hi.
>
> Last part of planned clean-up where I declare ::get as PURE.
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
OK,
thanks!
Honza
> Martin
> From 540efe3374d649cc8745445a3e6dc1c720fb79ad Mon Sep 17 00:00:00 2001
> From: marxin
> Dat
Hi,
this problem here seems to be that is_cxx returns true and at the same
time auto_die and decltype_auto_die is not initialized. Here die==NULL
and we end up calling add_type_attribute for random reasons.
I am testing the following but I am not sure it is proper fix. Are
we supposed to handle a
On 21/06/18 16:22 +0100, Jonathan Wakely wrote:
On 21/06/18 15:00 +0100, Jonathan Wakely wrote:
virtual void
- do_deallocate(void* __p, size_t __bytes, size_t __alignment)
+ do_deallocate(void* __p, size_t __bytes, size_t __alignment) noexcept
+ override
{
- using
On Wed, Jun 20, 2018 at 07:31:31PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> > This code disables the automatic multilib creation unless you use the
> > --with-advance-toolchain= option and the Advance Toolchain directoy has
> > been modi
> OK, thanks. I'll give it a try on x86/Windows once this is in.
The build of the Ada runtime miserably fails because finish_eh_generation
calls commit_edge_insertions before redirecting the EH edges from the post-
landing pads to the landing pads...
Fixed thusly, applied on the mainline as obv
When code is compiled at -O0, the RTL middle-end makes sure that location
information is preserved as much as possible by generating NOPs with the
location information (goto_locus) present on edges in the CFG, if it thinks
that these edges are the only place where a particular location is mentio
Hello Joseph,
Thanks for getting back to me on this!
> On 19 Jun 2018, at 17:50, Joseph Myers wrote:
>
> On Thu, 7 Jun 2018, Olivier Hainque wrote:
>
>> An updated version of the patch is attached, accounting for
>> your two comments and expanding on the .texi documentation a
>> bit.
>
> I s
On Thu, Jun 21, 2018 at 12:58:06PM -0400, Michael Meissner wrote:
> On Wed, Jun 20, 2018 at 07:31:31PM -0500, Segher Boessenkool wrote:
> > On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> > > This code disables the automatic multilib creation unless you use the
> > > --with-adva
On Thu, Jun 21, 2018 at 12:09:12PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 21, 2018 at 12:58:06PM -0400, Michael Meissner wrote:
> > On Wed, Jun 20, 2018 at 07:31:31PM -0500, Segher Boessenkool wrote:
> > > On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> > > > This code d
Thanks, Steve. Committed to trunk as revision 261857.
8-branch will be patched in a few days. Any opinions about 7-branch?
Cheers
Paul
On 21 June 2018 at 16:23, Steve Kargl wrote:
> On Thu, Jun 21, 2018 at 09:02:53AM +0100, Paul Richard Thomas wrote:
>> The original problem was fixed by the p
On 06/13/2018 02:58 PM, Dimitar Dimitrov wrote:
From: Dimitar Dimitrov
For some targets, Pmode != UNITS_PER_WORD. Take this into account
when marking hard registers as being used.
I tested C and C++ testsuits for x86_64 with and without this
patch. There was no regression, i.e. gcc.sum and
I've been looking at -fmem-report for a testcase from someone on the
committee, and found a couple of low-hanging fruits.
The first patch doesn't change any allocation, just makes it so
-fmem-report can see who's calling cxx_make_type.
The second patch avoids creating a vector (which we then neve
The following testcase is rejected because, for this line:
bool b = X() ?: false;
arg2 is missing and arg1 is a TARGET_EXPR. A TARGET_EXPR is a class
prvalue so we wrap it in a SAVE_EXPR. Later when building 'this' we
call build_this (SAVE_EXPR >) which triggers lvalue_error:
5856 cp_l
On Thu, Jun 21, 2018 at 06:36:28PM +0100, Paul Richard Thomas wrote:
> Thanks, Steve. Committed to trunk as revision 261857.
>
> 8-branch will be patched in a few days. Any opinions about 7-branch?
>
Well, from a selfish standpoint, I use 7 as my day-to-day
Fortran compiler at work, so a backpor
On Thu, Jun 21, 2018 at 01:26:19PM -0400, Michael Meissner wrote:
> On Thu, Jun 21, 2018 at 12:09:12PM -0500, Segher Boessenkool wrote:
> > > * config.gcc (powerpc64le*): Remove multilib support for IEEE and
> > > IBM long double.
> > > * config/rs6000/rs6000.c (rs6000_option_override_interna
On 06/21/2018 11:04 AM, Eric Botcazou wrote:
> When code is compiled at -O0, the RTL middle-end makes sure that location
> information is preserved as much as possible by generating NOPs with the
> location information (goto_locus) present on edges in the CFG, if it thinks
> that these edges are
expand_strn_compare was not using gen_int_mode or trunc_int_for_mode to
properly truncate to Pmode when creating contants in the generate rtx.
This lead to an improper constant and the ICE in PR/86222.
Testing on ppc64 with -m32, -m32 -mpowerpc64 and -m64. If regstrap
passes, ok for trunk and back
Apparently we never updated the x86_64-linux-gnu baseline for gcc-8
(so now that I'm trying to add a new symbol version on trunk, I'm
seeing errors for the get_entropy symbol added in the previous symbol
version).
Tested x86_64-linux, committed to gcc-8-branch.
commit d62e12c7a1586c397594ef9671
Hi!
On Thu, Jun 21, 2018 at 03:32:25PM -0500, Aaron Sawdey wrote:
> expand_strn_compare was not using gen_int_mode or trunc_int_for_mode to
> properly truncate to Pmode when creating contants in the generate rtx.
> This lead to an improper constant and the ICE in PR/86222.
>
> Testing on ppc64 wi
On 21/06/18 21:39 +0100, Jonathan Wakely wrote:
Apparently we never updated the x86_64-linux-gnu baseline for gcc-8
(so now that I'm trying to add a new symbol version on trunk, I'm
seeing errors for the get_entropy symbol added in the previous symbol
version).
The baseline should have been upd
Hi!
On Wed, Jun 20, 2018 at 10:32:06AM -0400, Michael Meissner wrote:
> In reworking the ordering of the 128-bit floating point modes (June 18th, 2018
> patch), I missed one conversion insn. This meant the compiler would generate
> a
> conversion to using the IF name.
Is there some existing tes
On Wed, Jun 20, 2018 at 10:38:10AM -0400, Michael Meissner wrote:
> This patch fixes the tests that use IEEE 128-bit float complex to use long
> double _Complex on systems where the default is IEEE 128-bit. Due to needing
> to use the same internal type for long double and __float128 (to get the
>
The SSO basic_string has a non-standard insert(iterator, initializer_list)
overload, from a C++0x draft. This adds the correct overload, while also
preserving the old one so that the old symbol is still exported from the
library.
The COW basic_string doesn't have any of the C++11 changes to the i
On Thu, Jun 21, 2018 at 04:25:29PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jun 20, 2018 at 10:32:06AM -0400, Michael Meissner wrote:
> > In reworking the ordering of the 128-bit floating point modes (June 18th,
> > 2018
> > patch), I missed one conversion insn. This meant the compiler
On Wed, Jun 20, 2018 at 10:42:38AM -0400, Michael Meissner wrote:
> This patch prevents the special overriding of the complex float128
> multiply/divide functions from being run twice if there are clone or target
> attributes. I wasn't aware that the hook used to initialize the built-in
> function
On Wed, Jun 20, 2018 at 10:46:04AM -0400, Michael Meissner wrote:
> This patch fixes a thinko that I had that prevented negation of __ibm128
> values
> if long double is IEEE 128-bit binary floating point.
>
> I have checked this on a little endian power8 system with builds where the
> long
> do
On 06/21/2018 11:04 AM, Eric Botcazou wrote:
> When code is compiled at -O0, the RTL middle-end makes sure that location
> information is preserved as much as possible by generating NOPs with the
> location information (goto_locus) present on edges in the CFG, if it thinks
> that these edges are
On Thu, 21 Jun 2018, Segher Boessenkool wrote:
> The comment doesn't make much sense. If long double is IBM, the long
> double complex mode is ICmode, not KCmode. "To get the IEEE128 complex
> type", perhaps? And can't you do _Complex __ieee128 or such?
You can do _Complex _Float128, in C only
On 06/19/2018 02:29 AM, Richard Biener wrote:
> On Mon, Jun 18, 2018 at 4:01 PM Wilco Dijkstra wrote:
>>
>> GCC currently defaults to -fmath-errno. This generates code assuming math
>> functions set errno and the application checks errno. Few applications
>> test errno and various systems and ma
On 06/18/2018 10:46 AM, Joseph Myers wrote:
> On Mon, 18 Jun 2018, Jeff Law wrote:
>
>> So do we need to set or check math_errhandling & MATH_ERRNO at all? Or
>
> That's a matter for libc (glibc currently sets it based on __FAST_MATH__ /
> __NO_MATH_ERRNO__, but fails to avoid including MATH_ER
On Thu, Jun 21, 2018 at 05:18:19PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:42:38AM -0400, Michael Meissner wrote:
> > This patch prevents the special overriding of the complex float128
> > multiply/divide functions from being run twice if there are clone or target
> > attribut
This libgo patch re-enables a couple of tests that are specific gccgo.
This is a port of https://golang.org/cl/120375 so that it gets more
reliable testing. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
On 06/21/2018 11:44 AM, Vladimir Makarov wrote:
>
>
> On 06/13/2018 02:58 PM, Dimitar Dimitrov wrote:
>> From: Dimitar Dimitrov
>>
>> For some targets, Pmode != UNITS_PER_WORD. Take this into account
>> when marking hard registers as being used.
>>
>> I tested C and C++ testsuits for x86_64 with
On Wed, Jun 20, 2018 at 10:54:18AM -0400, Michael Meissner wrote:
> This patch fixes the tests in the testsuite that implicitly were expecting
> long
> double to be IBM extended double to use __ibm128 if long double is configured
> to be IEEE 128-bit floating point.
And just always using __ibm128
On Thu, Jun 21, 2018 at 06:07:36PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:54:18AM -0400, Michael Meissner wrote:
> > This patch fixes the tests in the testsuite that implicitly were expecting
> > long
> > double to be IBM extended double to use __ibm128 if long double is
>
On Wed, Jun 20, 2018 at 10:49:41AM -0400, Michael Meissner wrote:
> These patches fix the tests in the testsuite that check whether -mno-float128
> works properly. In these cases, I explicitly run them with long double being
> set to IBM extended double.
So what happened without this patch?
Seg
On 06/12/2018 11:21 AM, Joseph Myers wrote:
> On Tue, 12 Jun 2018, Martin Sebor wrote:
>
>> The proposal to enable -Wstrict-prototypes discussed below
>> was considered too late for GCC 8. I'd like to revive it
>> now for GCC 9.
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00935.html
>
The explicit instantiation declarations for std::basic_string are
disabled for C++17 (and later) so that basic_string symbols get
implicitly instantiated in every translation unit that needs them. On
targets that don't support STB_GNU_UNIQUE this leads to multiple copies
of the empty rep symbol f
Hi Carl,
On Wed, Jun 20, 2018 at 05:09:00PM -0700, Carl Love wrote:
> I believe I have addressed all of your concerns with the patch.
>
> I have retested it and it looks good.
It looks good indeed. Please commit, thanks!
I noticed one more thing (follow-up patch?)
> /* { dg-final { scan-asse
On 6/21/18, Jeff Law wrote:
> On 06/12/2018 11:21 AM, Joseph Myers wrote:
>> On Tue, 12 Jun 2018, Martin Sebor wrote:
>>
>>> The proposal to enable -Wstrict-prototypes discussed below
>>> was considered too late for GCC 8. I'd like to revive it
>>> now for GCC 9.
>>>
>>> https://gcc.gnu.org/ml/
On 06/21/2018 05:14 PM, Jeff Law wrote:
On 06/12/2018 11:21 AM, Joseph Myers wrote:
On Tue, 12 Jun 2018, Martin Sebor wrote:
The proposal to enable -Wstrict-prototypes discussed below
was considered too late for GCC 8. I'd like to revive it
now for GCC 9.
https://gcc.gnu.org/ml/gcc-patches
On четвъртък, 21 юни 2018 г. 17:03:55 EEST Jeff Law wrote:
> On 06/21/2018 11:44 AM, Vladimir Makarov wrote:
> > On 06/13/2018 02:58 PM, Dimitar Dimitrov wrote:
> >> From: Dimitar Dimitrov
> >>
> >> For some targets, Pmode != UNITS_PER_WORD. Take this into account
> >> when marking hard registers
On 21 June 2018 at 17:30, Kyrill Tkachov wrote:
> Hi Hongbo,
>
> On 20/06/18 03:54, Hongbo Zhang wrote:
>>
>> HXT semiconductor's CPU core Phecda, as a variant of Qualcomm qdf24xx,
>> reuses the same tuning structure and pipeline with it.
>>
>
> This looks ok to me but you'll need approval from t
On 06/21/2018 10:01 PM, Dimitar Dimitrov wrote:
> On четвъртък, 21 юни 2018 г. 17:03:55 EEST Jeff Law wrote:
>> On 06/21/2018 11:44 AM, Vladimir Makarov wrote:
>>> On 06/13/2018 02:58 PM, Dimitar Dimitrov wrote:
From: Dimitar Dimitrov
For some targets, Pmode != UNITS_PER_WORD. Take
89 matches
Mail list logo
