On Tue, 19 Jun 2018, Cary Coutant wrote:
> > On testcases like that from PR60243 CFG build is dominated by
> > assign_discriminators because it expands locations again and again
> > and this got more expensive over the time.
> >
> > Cary - can you explain the overall logic of assign_discriminators
On 06/13/2018 01:21 PM, Richard Biener wrote:
> On Fri, Jun 8, 2018 at 1:10 PM Martin Liška wrote:
>>
>> Hi.
>>
>> Second follow-up patch uses flags_from_decl_or_type in LTO merging
>> of declarations. Hope it's more cleaner approach.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regr
On Wed, Jun 20, 2018 at 12:25 AM Eric Botcazou wrote:
>
> Hi,
>
> the Ada compiler uses small functions defined in its runtime to implement
> various intrinsic operations and it always inlines them, even at -O0. But it
> doesn't want location information from the runtime files to appear in the
>
Richard Biener writes:
> On Mon, Jun 18, 2018 at 4:53 PM Richard Sandiford
> wrote:
>>
>> A pattern's PATTERN_DEF_SEQ was attached to both the original statement
>> and the main pattern statement, which made it harder to update later.
>> This patch attaches it to just the original statement. In
Hi Andre,
On 18/06/18 10:38, Andre Simoes Dias Vieira wrote:
Hi,
This patch teaches the AArch64 backend that the AESE and AESD unspecs are
commutative (which correspond to the vaeseq_u8 and vaesdq_u8 intrinsics). This
improves register allocation around their corresponding instructions avoidi
On Wed, Jun 20, 2018 at 10:03 AM Martin Liška wrote:
>
> On 06/13/2018 01:21 PM, Richard Biener wrote:
> > On Fri, Jun 8, 2018 at 1:10 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> Second follow-up patch uses flags_from_decl_or_type in LTO merging
> >> of declarations. Hope it's more cleaner app
On 06/12/2018 09:41 PM, Jeff Law wrote:
> On 06/04/2018 07:32 AM, marxin wrote:
>> gcc/ChangeLog:
>>
>> 2018-06-07 Martin Liska
>>
>> * tree-switch-conversion.c (MAX_CASE_BIT_TESTS): Remove.
>> (hoist_edge_and_branch_if_true): Likewise.
>> (expand_switch_using_bit_tests_p): Likewi
Hi Tamar,
On 19/06/18 15:14, Tamar Christina wrote:
Hi All,
This patch requires https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01145.html to
work,
it has been accepted once already but caused a regression on certain
configuratoins.
I am re-submitting it with the required mid-end change and req
On 06/12/2018 10:44 PM, Jeff Law wrote:
> On 06/05/2018 01:15 AM, marxin wrote:
>> gcc/ChangeLog:
>>
>> 2018-06-07 Martin Liska
>>
>> * tree-switch-conversion.c (switch_conversion::collect):
>> Record m_uniq property.
>> (switch_conversion::expand): Bail out for special conditi
On 06/19/2018 09:11 PM, James Greenhalgh wrote:
On Mon, Jun 18, 2018 at 08:43:04AM -0500, Siddhesh Poyarekar wrote:
r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of
which this comment about X30 not being marked as call-clobbered is no
longer accurate.
Is the second paragrap
Hi Kyrill,
Many thanks for the review!
The 06/19/2018 16:47, Kyrill Tkachov wrote:
> Hi Tamar,
>
> On 19/06/18 15:07, Tamar Christina wrote:
> > Hi All,
> >
> > This fixes a regression where we don't have an instruction for pre Armv8.2-a
> > to do a move of an fp16 value from a GP reg to a SIMD
Richard Biener writes:
> On Mon, Jun 18, 2018 at 5:04 PM Richard Sandiford
> wrote:
>>
>> When following the definitions of SSA names, some recognisers
>> already cope with statements that have been replaced by patterns.
>> This patch makes that happen automatically for users of
>> type_conversio
Although the first pattern match wins in the sense that no later
function can match the *old* gimple statement, it still seems worth
letting them match the *new* gimple statements, just like we would if
the original IR had included that sequence from the outset.
This is mostly true after the later
This patch adds helper functions for detecting widened operations and
generalises the existing code to handle more cases.
One of the main changes is to recognise multi-stage type conversions,
which are possible even in the original IR and can also occur as a
result of earlier pattern matching (esp
vect_recog_rotate_pattern had code to prevent operations
on invariants being vectorised unnecessarily:
if (dt == vect_external_def
&& TREE_CODE (oprnd1) == SSA_NAME
&& is_a (vinfo))
{
struct loop *loop = as_a (vinfo)->loop;
ext_def = loop_preheader_edge (loop);
Hi Kyrill,
Many thanks for the review!
The 06/20/2018 09:43, Kyrill Tkachov wrote:
> Hi Tamar,
>
> On 19/06/18 15:14, Tamar Christina wrote:
> > Hi All,
> >
> > This patch requires
> > https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01145.html to work,
> > it has been accepted once already but ca
This patch is the main part of PR85694. The aim is to recognise at least:
signed char *a, *b, *c;
...
for (int i = 0; i < 2048; i++)
c[i] = (a[i] + b[i]) >> 1;
as an over-widening pattern, since the addition and shift can be done
on shorts rather than ints. However, it ended up being
The main over-widening patch can introduce quite a few extra casts,
and in many cases those casts simply "tap into" an intermediate
point in an existing extension. E.g. if we have:
unsigned char a;
int ax = (int) a;
and a later operation using ax is shortened to "unsigned short",
we woul
On Tue, Jun 12, 2018 at 10:44 PM, Jeff Law wrote:
> On 06/05/2018 01:15 AM, marxin wrote:
>>
>> + The definition of "much bigger" depends on whether we are
>> + optimizing for size or for speed. If the former, the maximum
>> + ratio range/count = 3, because this was found to be the opt
When turning a user-defined numerical literal into an operator
invocation the literal needs to be translated to the execution
character set.
Bootstrapped and regtested on s390x. x86_64 still running.
Ok to apply if x86_64 is clean?
Bye,
-Andreas-
gcc/cp/ChangeLog:
2018-06-20 Andreas Krebbel
PING^1
On 05/16/2018 01:53 PM, Martin Liška wrote:
> On 12/21/2017 10:13 AM, Martin Liška wrote:
>> On 12/20/2017 06:45 PM, Jakub Jelinek wrote:
>>> Another thing is that the "/" in there is wrong, so
>>> const char dir_separator_str[] = { DIR_SEPARATOR, '\0' };
>>> char *b = concat (profile_d
PING^1 (for the whole series).
On 05/14/2018 02:41 PM, Martin Liška wrote:
> On 04/26/2018 01:13 AM, David Malcolm wrote:
>> [moving from gcc to gcc-patches mailing list]
>>
>> On Wed, 2018-04-25 at 15:12 +0200, Martin Liška wrote:
>>> On 04/24/2018 06:27 PM, David Malcolm wrote:
On Tue, 2018
Hi.
This is second part of IPA summaries clean-up. It removes some not needed
::get_create in ipa-pure.const.c.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
>From 932bcf9d0247189700edf86e2b07301ba1fa1f87 Mon Sep 17 00:00:00 2001
From: m
Hi,
for make check-fixincludes I'm seeing:
...
cmp: EOF on
/home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h
*** ioLib.h 2018-06-20 14:14:40.035956737 +0200
--- /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h
2018-06-20 14:14:28.183925247 +0200
***
On 06/20/2018 02:19 PM, Tom de Vries wrote:
> Hi,
>
> for make check-fixincludes I'm seeing:
> ...
> cmp: EOF on
> /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h
> *** ioLib.h 2018-06-20 14:14:40.035956737 +0200
> --- /home/vries/gcc_versions/devel/src/fixincludes/tests/base
Hi James,
Many thanks for the review!
The 06/19/2018 22:23, James Greenhalgh wrote:
> On Tue, Jun 19, 2018 at 09:09:27AM -0500, Tamar Christina wrote:
> > Hi All,
> >
> > This changes the movmem code in AArch64 that does copy for data between 4
> > and 7
> > bytes to use the smallest possible m
On 20/06/18 11:33, Tamar Christina wrote:
Hi Kyrill,
Many thanks for the review!
The 06/20/2018 09:43, Kyrill Tkachov wrote:
Hi Tamar,
On 19/06/18 15:14, Tamar Christina wrote:
Hi All,
This patch requires https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01145.html to
work,
it has been accep
> Hi.
>
> This is second part of IPA summaries clean-up. It removes some not needed
> ::get_create in ipa-pure.const.c.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
OK, thanks!
Honza
> Martin
> From 932bcf9d0247189700edf86e2b07301ba1
Hi,
the fix for PR target/81736 unconditionally overrules -fno-omit-frame-pointer,
including at -O0 where it is implicit. That seems brutal and unnecessary so
the attached patch reverts it at -O0 and thus fixes 135 failures in the GDB
testsuite:
=== gdb Summary ===
-# of exp
On Sat, Jun 16, 2018 at 02:13:32PM +0200, Eric Botcazou wrote:
> > Now committed after successful bootstrap/regtest on x86_64-linux and
> > i686-linux. Is the cfgrtl.c change ok for trunk too?
> > http://gcc.gnu.org/ml/gcc-patches/2018-06/msg00967.html
>
> Don't we actually need to verify that al
I'm going to post long double transition fixes that fix most of the problems
when you switch the long double format as follow-ups to this message. A few of
the fixes to the tests were previously posted, but I've added some comments.
Here are the remaining failures in the C/C++ tests after these p
> This also passes bootstrap/regtest for me (dwarf exceptions only though).
> So is this ok for trunk instead?
>
> 2018-06-20 Jakub Jelinek
>
> * cfgrtl.c (rtl_verify_edges): Formatting fix. If bb->preds has any
> EDGE_EH edges, verify they are all EDGE_EH.
OK, thanks. I'll give
Hi!
On the second following testcase, we call vrp_meet on [1B, 2B] and ~[0B, 1B]
and instead of computing the right ~[0B, 0B], we compute invalid ~[0B, -1B].
Similarly, on the first testcase, vrp_meet on [4, 8] and ~[2, 6] computes
~[2, 1] which is invalid and is canonicalized into VARYING, while
Hi!
In PR65321 I've added lower_subreg call on the last argument of ASHIFT, but
as the following testcase shows, use_narrower_mode_test has not been updated
correspondingly to verify lower_subreg will actually work.
On the testcase validate_subreg actually is happy about it, but because op1
is alr
When we started down the road of transitioning long double to IEEE 128-bit, we
thought the only way to do it was to add multi-lib support. Since then with
work underway in both GLIBC and libstdc++ we no longer feel that we need to use
multilibs.
The code as it is now for GCC 8.x and trunk will au
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.
I have tested this on a little endian power8 system with long double set to
IEEE 128-bit and IBM extended,
Hi!
This patch fixes a regression caused by C++ delayed folding, when
check_nonnull_arg is called, the arguments aren't folded yet and so unlike
GCC 4.8 and earlier we don't report -Wnonnull warning unless the argument is
literal NULL without any folding.
Fixed thusly, bootstrapped/regtested on x
This patch fixes 85634, an ice during tsubst where we encounter an
unmarked lookup. Such lookups could be mutated by declarations added
after the template definition containing them. That would be bad.
I had originally wanted to mark these lookups once we knew we were
saving them, but this
On Wed, 20 Jun 2018, Jakub Jelinek wrote:
> Hi!
>
> On the second following testcase, we call vrp_meet on [1B, 2B] and ~[0B, 1B]
> and instead of computing the right ~[0B, 0B], we compute invalid ~[0B, -1B].
>
> Similarly, on the first testcase, vrp_meet on [4, 8] and ~[2, 6] computes
> ~[2, 1]
Hi,
Consider the test-case from the patch. When compiled with "-O2
-ftree-parallelize-loops=2 -fno-tree-dce", it ICEs like this:
...
error: mismatching comparison operand types
signed int
unsigned int
if (ivtmp_32 < 3)
during GIMPLE pass: parloops
pr86097.c:4:1: internal compiler error: verify_gim
> 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?
* tree-inline.c (copy_edges_for_bb): Minor tweak.
(maybe_move_debug_stmts_to_succe
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
mangling correct and make templates work), you can't really use KF or KC
On Wed, 20 Jun 2018, Jakub Jelinek wrote:
> Hi!
>
> In PR65321 I've added lower_subreg call on the last argument of ASHIFT, but
> as the following testcase shows, use_narrower_mode_test has not been updated
> correspondingly to verify lower_subreg will actually work.
> On the testcase validate_su
On Wed, 20 Jun 2018, Tom de Vries wrote:
> Hi,
>
> Consider the test-case from the patch. When compiled with "-O2
> -ftree-parallelize-loops=2 -fno-tree-dce", it ICEs like this:
> ...
> error: mismatching comparison operand types
> signed int
> unsigned int
> if (ivtmp_32 < 3)
> during GIMPLE pas
On Mon, 2018-05-14 at 14:50 +0200, Martin Liška wrote:
> First part with introduction of auto_string_vec class.
>
FWIW, I'm fine with the changes to the jit subdir, but I don't think I
have approval rights on the vec.h changes.
BTW, was the move of vec_alloc in vec.h intentional? (I take it tha
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
functions is run each time you change the target options. The built-in
function h
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
double is set to IEEE and IBM 128-bit binary floating point, and it fixes some
tests
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.
I have tested these on a little endian power8 system using two builds with long
double being set to IEEE and IBM 1
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.
Note, test pr70117.c will still fail due to bugs in isnormal code generation
for __ibm128. However, expl
On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:
> Second part refactors function from gcc.c into a new class
> option_proposer.
>
> Martin
[...snip...]
diff --git a/gcc/c-family/cppspec.c b/gcc/c-family/cppspec.c
index 1e0a8bcd294..66540239f53 100644
--- a/gcc/c-family/cppspec.c
+++ b/gcc
On Wed, Jun 20, 2018 at 7:41 AM, Andreas Krebbel
wrote:
> When turning a user-defined numerical literal into an operator
> invocation the literal needs to be translated to the execution
> character set.
>
> Bootstrapped and regtested on s390x. x86_64 still running.
> Ok to apply if x86_64 is clean
On 06/20/2018 02:38 AM, Martin Liška wrote:
> On 06/12/2018 09:41 PM, Jeff Law wrote:
>> On 06/04/2018 07:32 AM, marxin wrote:
>>> gcc/ChangeLog:
>>>
>>> 2018-06-07 Martin Liska
>>>
>>> * tree-switch-conversion.c (MAX_CASE_BIT_TESTS): Remove.
>>> (hoist_edge_and_branch_if_true): Likewise
On 06/20/2018 02:47 AM, Martin Liška wrote:
> On 06/12/2018 10:44 PM, Jeff Law wrote:
>> On 06/05/2018 01:15 AM, marxin wrote:
>>> gcc/ChangeLog:
>>>
>>> 2018-06-07 Martin Liska
>>>
>>> * tree-switch-conversion.c (switch_conversion::collect):
>>> Record m_uniq property.
>>> (swit
On 06/20/2018 05:25 AM, Steven Bosscher wrote:
> On Tue, Jun 12, 2018 at 10:44 PM, Jeff Law wrote:
>> On 06/05/2018 01:15 AM, marxin wrote:
>>>
>>> + The definition of "much bigger" depends on whether we are
>>> + optimizing for size or for speed. If the former, the maximum
>>> + ratio
On Wed, Jun 20, 2018 at 09:15:08AM -0600, Jeff Law wrote:
> > Thank you for the trust. I tried to split it into multiple patches, but
> > it wasn't readable enough.
> Yea, it can be painful to find the right way to structure a series. In
> fact, I'm going to be faced with that shortly for a target
On 06/20/2018 09:20 AM, Jakub Jelinek wrote:
> On Wed, Jun 20, 2018 at 09:15:08AM -0600, Jeff Law wrote:
>>> Thank you for the trust. I tried to split it into multiple patches, but
>>> it wasn't readable enough.
>> Yea, it can be painful to find the right way to structure a series. In
>> fact, I'm
On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:
> Main part where I still need to write ChangeLog file and
> gcc.sh needs to be moved to bash-completions project.
>
> Martin
As before, I'm not an official reviewer for it, but it touches code
that I wrote, so here goes.
Overall looks good
On Wed, Jun 20, 2018 at 10:32 AM, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes a regression caused by C++ delayed folding, when
> check_nonnull_arg is called, the arguments aren't folded yet and so unlike
> GCC 4.8 and earlier we don't report -Wnonnull warning unless the argument is
> literal N
The recent change introducing ABSU_EXPR neglected to also handle this code
in cxx_eval_constant_expression so this patch puts it there. Also two
other spots for good measure. It's possible we'll find out that we need
to fix other spots too.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK.
On Wed, Jun 20, 2018 at 11:34 AM, Marek Polacek wrote:
> The recent change introducing ABSU_EXPR neglected to also handle this code
> in cxx_eval_constant_expression so this patch puts it there. Also two
> other spots for good measure. It's possible we'll find out that we need
> to fix othe
On Tue, Jun 19, 2018 at 4:55 PM, Paolo Carlini wrote:
> Hi,
>
> the below implements a couple of independent ideas. First, adds a const
> cp_decl_specifier_seq * parameter, similarly to grokvardecl: this way the
> function has available locations[ds_inline], locations[ds_constexpr],
> locations[ds
On 18/06/18 19:00 +0100, Jonathan Wakely wrote:
This issue hasn't been voted into the working draft yet, but it's been
approved by LWG and is obviously correct.
* include/std/chrono (duration, operator*, operator/, operator%): Use
const-qualified type as source type in is_convert
On Tue, Jun 19, 2018 at 09:59:09AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the C FE.
>
> Is it OK for trunk?
>
> Cesar
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
> gcc/c/
> * c
On Tue, Jun 19, 2018 at 09:58:26AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the C++ FE.
>
> Is it OK for trunk?
>
> Cesar
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
> gcc/cp/
>
Committed to CVS.
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.8
diff -u -r1.8 changes.html
--- htdocs/gcc-9/changes.html 8 Jun 2018 15:28:59 - 1.8
+++ htdocs/
On Tue, Jun 19, 2018 at 09:59:57AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the
> Fortran FE.
>
> Is it OK for trunk?
>
> Cesar
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
> gcc/fortra
On Tue, Jun 19, 2018 at 10:00:37AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the
> middle end.
>
> Is it OK for trunk?
>
> Cesar
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
> gcc/c-fami
On Tue, Jun 19, 2018 at 10:01:20AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in libgomp.
>
> Is it OK for trunk?
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
> libgomp/
> * libgomp.h (
And here's the patch for gcc-8.
nathan
--
Nathan Sidwell
2018-06-20 Nathan Sidwell
PR c++/85634 - tsubst ICE on unmarked lookup
* parser.c (cp_parser_primary_expression): Keep lookup in template.
PR c++/85634 - tsubst ICE on unmarked lookup
* g++.dg/lookup/pr85634.C: New.
Index: gcc/cp/
On 06/20/2018 09:45 AM, Jakub Jelinek wrote:
> On Tue, Jun 19, 2018 at 10:01:20AM -0700, Cesar Philippidis wrote:
>> >From 53ee03231c5e6e4747b4ef01335079a2d4a98480 Mon Sep 17 00:00:00 2001
>> From: Cesar Philippidis
>> Date: Tue, 19 Jun 2018 09:33:04 -0700
>> Subject: [PATCH 7/7] runtime changes
On Wed, Jun 20, 2018 at 09:59:29AM -0700, Cesar Philippidis wrote:
> > I'm not entirely happy about this, it grows the structure for not just
> > OpenACC, but also OpenMP which will never use it. Are there any fields
> > not used by OpenACC? E.g. is link_key used?
> > Or could the dynamic refcoun
On 06/20/2018 10:03 AM, Jakub Jelinek wrote:
> On Wed, Jun 20, 2018 at 09:59:29AM -0700, Cesar Philippidis wrote:
>> If it means anything, we have a significant async change that removes
>> the async_refcount field in that struct.
>
> Wasn't async_refcount removed 2 years ago?
You're right. I wa
Hi all,
Please find below a patch to fix PR 86213. This changes the runtime
code for -fsplit-stack to move a couple of calls (getenv, etc) from
the routine called by __morestack to a function called on startup,
so as to avoid having the calls clobber SSE input regs.
Thanks, Than
---
libgcc/Chan
On 06/20/2018 10:33 AM, Nathan Sidwell wrote:
This patch fixes 85634, an ice during tsubst where we encounter an
unmarked lookup. Such lookups could be mutated by declarations added
after the template definition containing them. That would be bad.
This patch is needed on trunk, to handle fr
Construct the program-wide resource objects using placement new. This
means they have dynamic storage duration and won't be destroyed during
termination.
PR libstdc++/70966
* include/experimental/memory_resource (__resource_adaptor_imp): Add
static assertions to enforce re
On Wed, Jun 20, 2018 at 12:02 PM, Than McIntosh wrote:
>
> Please find below a patch to fix PR 86213. This changes the runtime
> code for -fsplit-stack to move a couple of calls (getenv, etc) from
> the routine called by __morestack to a function called on startup,
> so as to avoid having the call
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:
...
$ ./a.out
Floating point exception
...
The problem is introduced by -ftree-tail-merge (enabled by -O2), so it
executes fine when
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:
...
$ ./a.out
Floating point exception
...
The problem is introduced by -ftree-tail-mer
On Wed, Jun 20, 2018 at 2:11 PM, Ian Lance Taylor wrote:
> On Wed, Jun 20, 2018 at 12:02 PM, Than McIntosh wrote:
>>
>> Please find below a patch to fix PR 86213. This changes the runtime
>> code for -fsplit-stack to move a couple of calls (getenv, etc) from
>> the routine called by __morestack t
At present, the nvptx libgomp plugin does not take into account the
amount of shared resources on GPUs (mostly shared-memory are register
usage) when selecting the default num_gangs and num_workers. In certain
situations, an OpenACC offloaded function can fail to launch if the GPU
does not have suf
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 (see PR85590 - [nvptx, libgomp, openacc] Use cuda runtim
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/coding-3/gcc-git-static-analysis/build/gcc/testsuite/jit/test-factorial.c
Segher:
I believe I have addressed all of your concerns with the patch.
I have retested it and it looks good.
Please let me know if the patch looks OK for GCC mainline.
Carl Love
>From 8d354f93c5ddb5161b
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 modified to have the lib64/ieee128 and/or lib64/ibm128 directories for
> multili
Working on iterator == operator I noticed that a comparison in
_Safe_iterator was inconsistent.
* include/debug/debug.h
(_Safe_iterator<>(const _Safe_iterator<_MutableIterator,>& __x)):
Compare __x base iterator with a default initialized iterator of the
same type.
Tested under
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
86 matches
Mail list logo
