Tested and committed to gcc 9 branch.
On Wed, Jan 22, 2020 at 2:35 AM Jim Wilson wrote:
> On Mon, Jan 20, 2020 at 6:44 PM Kito Cheng wrote:
> > Thanks, fixed and committed, and it's OK to commit to gcc 8/9 next week?
>
> Yes, that is OK with me.
>
> Jim
>
On Thu, 30 Jan 2020, Jakub Jelinek wrote:
> Hi!
>
> This is something that has been discussed already a few months ago, but
> seems to have stalled. Here is Paul's patch from the PR except for the
> TREE_STATIC hunk which is wrong, and does the most conservative fn spec
> tweak for the problemat
Hi Thomas,
On 29.01.20 18:44, Thomas Schwinge wrote:
>> + size_t len = sizeof hsa_context.driver_version_s;
>> + int printed = snprintf (hsa_context.driver_version_s, len,
>> + "HSA Runtime %hu.%hu", (unsigned short int)major,
>> + (unsigned short int)m
On Thu, Jan 30, 2020 at 1:23 AM Jakub Jelinek wrote:
>
> Hi!
>
> Some time ago, patterns were added to optimize move mask followed by zero
> extension from 32 bits to 64 bit. As the testcase shows, the intrinsics
> actually return int, not unsigned int, so it will happen quite often that
> one ac
On Thu, Jan 30, 2020 at 1:18 AM Jakub Jelinek wrote:
>
> Hi!
>
> Like any other instruction with 32-bit GPR destination operand in 64-bit
> mode, popcntl also clears the upper 32 bits of the register (and other bits
> too, it can return only 0 to 32 inclusive).
>
> During combine, the zero or sign
On Tue, 28 Jan 2020 at 17:17, Richard Biener wrote:
>
> On Fri, Jan 24, 2020 at 7:04 AM Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 20 Jan 2020 at 15:44, Richard Biener
> > wrote:
> > >
> > > On Wed, Jan 8, 2020 at 11:20 AM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Tue, 5 Nov 2019 a
Joseph, you were the last one in this part of
c_parser_switch_statement, but the change you made was for supporting
atomics. I'm not sure if you'll have context here or not.
PR88660 is a false positive warning for a set-but-unused object. We
can see trivially from the testcase that "i" is used
This libgo patch by Svante Signell adds a couple of hurd build to the
runtime and syscall packages. Bootstrapped on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
66af5a226acd0edfbafcbcac76ed268cee0612ed
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 8d08e91211d..40529518b2
This patch by Svante Signell updates runtime/netpoll_hurd.go for the
changes in the Go 1.14beta1 release. Bootstrapped on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
58d788fafbc4cc8cc25ca432e8127e1effdc0672
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 49312fa10f7..8d0
Since expand_stack_vars and such know how to deal with variables aligned
beyond MAX_SUPPORTED_STACK_ALIGNMENT, we shouldn't reject alignas of large
alignments. And if we don't do that, there's no point in having
check_cxx_fundamental_alignment_constraints at all, since
check_user_alignment already
Hi!
Some time ago, patterns were added to optimize move mask followed by zero
extension from 32 bits to 64 bit. As the testcase shows, the intrinsics
actually return int, not unsigned int, so it will happen quite often that
one actually needs sign extension instead of zero extension. Except for
Hi!
Like any other instruction with 32-bit GPR destination operand in 64-bit
mode, popcntl also clears the upper 32 bits of the register (and other bits
too, it can return only 0 to 32 inclusive).
During combine, the zero or sign extensions of it show up as paradoxical
subreg of the popcount & 63
Hi!
This is something that has been discussed already a few months ago, but
seems to have stalled. Here is Paul's patch from the PR except for the
TREE_STATIC hunk which is wrong, and does the most conservative fn spec
tweak for the problematic two builtins we are aware of (to repeat what is in
t
Hi!
The test uses __int128_t, so won't work on targets that don't support it.
Fixed thusly, tested on x86_64-linux -m32/-m64, committed to trunk as
obvious.
2020-01-30 Jakub Jelinek
PR tree-optimization/92706
* gcc.dg/tree-ssa/pr92706-1.c: Require int128 effective target.
---
My fix for 60503 fixed handling of C++11 attributes following the
lambda-declarator. My patch for 89640 re-added support for GNU attributes,
but attributes after the trailing return type were parsed as applying to the
return type rather than to the function. This patch adjusts parsing of a
traili
On 29.01.2020. 12:06, Tobias Burnus wrote:
> Hi Dragan,
>
> I think your committed patch was incomplete – at least I see the
> following bits when running --enable-maintainer-mode (see attachment,
> line numbers wrong as I edited my changes out).
>
> Can you re-check?
>
> (The other change in gcc/
Hi,
On 29/01/20 19:00, Jason Merrill wrote:
On 1/29/20 4:31 AM, Paolo Carlini wrote:
Hi,
in this regression we issue a diagnostic about an incomplete type
(only a warning by default) and then we crash when we try to query
has_attribute on a member of the type because in such cases the
membe
I think this patch is still waiting to be applied. I checked that it applies
against trunk (with line offsets) and reg tests cleanly and posted an updated
version (diff'd against current trunk) at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103#c7
I'm happy to go ahead and commit this if Be
This test got fixed by r10-1976-gdaaa6fcc70ffe66bd56f5819ad4ee78fecd54bb6
so let's add it to the testsuite.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/88092
* g++.dg/cpp2a/nontype-class31.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/nontype-class31.C | 19 ++
On Wed, 2020-01-29 at 10:00 +0100, Richard Biener wrote:
>
> P2 please (make _b_o_s const). No idea why it wasn't that way in the first
> place. As you say the value-dependence on the result keeps everything
> live and stores or loads are completely irrelevant to the size of objects.
>
> So OK
Andreas Schwab writes:
> On Jan 27 2020, Richard Sandiford wrote:
>
>> * simplify-rtx.c (simplify_truncation): Extend sign/zero_extract
>> simplification to handle subregs as well as bare regs.
>
> That breaks gcc.target/m68k/pr39726.c
Gah. Jeff pointed out off-list that it also broke
On 29/01/20 09:57 -0800, Thomas Rodgers wrote:
Looks good to me, ok for trunk.
Committed.
On 1/29/20 12:35 PM, Marek Polacek wrote:
Here we fail to compile the attached test, stating that the use of
T in T::T() {} is "invalid use of incomplete type". It is a
function definition so grokdeclarator checks that the qualifying type
is complete.
When we parsed the class T, finish_struct g
On 1/28/20 6:34 PM, Marek Polacek wrote:
This PR points out an ICE with an alias template and class NTTP, but I
found that there are more issues. Trouble arise when we use a
(non-type) template parameter as an argument to the template arg list of
a template that accepts a class NTTP and a conver
On 1/29/20 4:31 AM, Paolo Carlini wrote:
Hi,
in this regression we issue a diagnostic about an incomplete type (only
a warning by default) and then we crash when we try to query
has_attribute on a member of the type because in such cases the member
remains an IDENTIFIER_NODE which of course d
On 29/01/2020 17:44, Thomas Schwinge wrote:
@@ -1513,6 +1518,23 @@ init_hsa_context (void)
+ size_t len = sizeof hsa_context.driver_version_s;
+ int printed = snprintf (hsa_context.driver_version_s, len,
+ "HSA Runtime %hu.%hu", (unsigned short int)major,
+
Looks good to me, ok for trunk.
Thanks.
Jonathan Wakely writes:
> Fix synchronization issues in . Replace shared_ptr with
> _Stop_state_ref and a reference count embedded in the shared state.
> Replace std::mutex with spinlock using one bit of a std::atomic<> that
> also tracks whether a stop re
On 1/29/20 12:42 PM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
Hi all,
This fixes:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93300
Genmodes.c was generating the "wider_mode" chain as follows:
HF -> BF -> SF - > DF -> TF -> VOID
This caused issues in some rare cases where
Hi!
On 2020-01-29T10:52:57+0100, "Harwath, Frederik"
wrote:
> On 28.01.20 16:42, Andrew Stubbs wrote:
>> On 28/01/2020 14:55, Harwath, Frederik wrote:
>>
>> If we're going to use a fixed-size buffer then we should use snprintf and
>> emit GCN_WARNING if the return value is greater than
>> "si
Here we fail to compile the attached test, stating that the use of
T in T::T() {} is "invalid use of incomplete type". It is a
function definition so grokdeclarator checks that the qualifying type
is complete.
When we parsed the class T, finish_struct gave the class a non-null
TYPE_SIZE, making i
On 29/01/2020 15:40, Tobias Burnus wrote:
Hi Andrew,
On 1/29/20 2:01 PM, Andrew Stubbs wrote:
On 29/01/2020 12:53, Tobias Burnus wrote:
With LLVM 9, the old variant is only accepted when also passing
"-mattr=-code-object-v3" to the compiler; that's a"-" after the "="
to disable V3. […]
it t
Thanks Tobias and Gerald - that change is now committed:
https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=commit;h=b88b1edba71bbca44429c28b7518d76678ab6acb
On Wednesday, January 29, 2020 11:57:02 AM PST Tobias Burnus wrote:
> LGTM – and also to Gerald. Hence, go ahead!
>
> Thanks for the patch,
>
>
On Wed, 29 Jan 2020, Patrick Palka wrote:
On Wed, 29 Jan 2020, Jonathan Wakely wrote:
On 21/01/20 17:26 -0500, Patrick Palka wrote:
It seems that in practice std::sentinel_for is always true, and so
the
Doh, good catch.
test_range container doesn't help us detect bugs in ranges code in whi
On Wed, 29 Jan 2020, Jonathan Wakely wrote:
On 21/01/20 17:26 -0500, Patrick Palka wrote:
It seems that in practice std::sentinel_for is always true, and so
the
Doh, good catch.
test_range container doesn't help us detect bugs in ranges code in which we
wrongly assume that a sentinel can be
Hi Andrew,
On 1/29/20 2:01 PM, Andrew Stubbs wrote:
On 29/01/2020 12:53, Tobias Burnus wrote:
With LLVM 9, the old variant is only accepted when also passing
"-mattr=-code-object-v3" to the compiler; that's a"-" after the "="
to disable V3. […]
it turned out that at last the assembler of LLV
Hi Nathan,
Nathan Sidwell wrote:
> On 1/28/20 11:14 AM, Iain Sandoe wrote:
>> + if (!error_emitted &&
>> + (traits_decl == NULL_TREE || traits_decl == error_mark_node))
>> {
>>error_at (kw, "cannot find % template");
>> + error_emitted = true;
>>return NULL_TREE;
On Tue, 28 Jan 2020, Jeff Law wrote:
> On Tue, 2019-10-08 at 18:04 +0300, Alexander Monakov wrote:
> > On Thu, 3 Oct 2019, Jeff Law wrote:
> >
> > > You may want to review the 2018 discussion:
> > >
> > > https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg185287.html
> > >
> > > THe 2018 d
On Jan 27 2020, Richard Sandiford wrote:
> * simplify-rtx.c (simplify_truncation): Extend sign/zero_extract
> simplification to handle subregs as well as bare regs.
That breaks gcc.target/m68k/pr39726.c
@@ -67,39 +67,39 @@ Disassembly of section .text:
0088 :
88: 302f 0006
Hi!
On 2020-01-29T15:28:49+0100, "Harwath, Frederik"
wrote:
> we should handle acc_device_radeon in the name_of_acc_device_t function
> which is used in libgomp/oacc-init.c to display the name of devices
> in several error messages.
(Not sure why that was missing in the GCC trunk commit of the
On 1/28/20 3:55 PM, Iain Sandoe wrote:
While looking at Pr93458, I spotted the following non-fatal, but
unhelpful diagnostic output.
If the user's coroutine return type omits the mandatory promise
type then we will currently restate that error each time we see
a coroutine keyword, which doesn't
On 21/01/2020 15:34, Richard Sandiford wrote:
> Szabolcs Nagy writes:
>> gcc/ChangeLog:
>>
>> 2020-01-21 Szabolcs Nagy
>>
>> * config/aarch64/aarch64.c (aarch64_declare_function_name): Set
>> cfun->machine->label_is_assembled.
>> (aarch64_print_patchable_function_entry): New.
>>
On 1/28/20 11:14 AM, Iain Sandoe wrote:
Hi,
Since coroutine-ness is discovered lazily, we encounter the diagnostics
during each keyword parse. We were not handling the case where a user code
failed to include fundamental information (e.g. the traits) in a graceful
manner (nor tolerating that le
Hi,
we should handle acc_device_radeon in the name_of_acc_device_t function
which is used in libgomp/oacc-init.c to display the name of devices
in several error messages.
Ok to commit this patch to master?
Best regards,
Frederik
From 6aacba3e8123ce5e0961857802fd7d8a103aa96b Mon Sep 17 00:00:00 2
On 29/01/20 13:47 +, Jonathan Wakely wrote:
--- a/libstdc++-v3/libsupc++/compare
+++ b/libstdc++-v3/libsupc++/compare
@@ -525,7 +525,9 @@ namespace std
// BUILTIN-PTR-THREE-WAY(T, U)
template
concept __3way_builtin_ptr_cmp
- = convertible_to<_Tp, const volatile void*>
+
Ping
On Sat, Nov 23, 2019 at 12:30 AM Christian Biesinger
wrote:
>
> Normally the toplevel Makefile will pass various CC=foo and other
> flags down to subdir Makefiles. However, for Gnulib this is a problem
> because Gnulib's configure specifically sets CC to something that
> includes a -std=gnu1
Am Mittwoch, den 29.01.2020, 09:45 +0100 schrieb Richard Biener:
> On Tue, Jan 28, 2020 at 1:24 PM Uecker, Martin
> wrote:
> > >
> > > Note for the current PTA implementation there's almost no cases we can
> > > handle conservatively enough. Consider the simple
> > >
> > > int a[4];
> > > in
Hi,
As discussed in the PR, this simple patch refines data dependence of two write
references storing the same constant with the same bytes. It simply detects
the case with some restrictions and treats it as no dependence. For now the
added interface in tree-data-ref.c is only used in loop distr
Currently types that cannot be compared using <=> but which are
convertible to pointers will be compared by converting to pointers
first. They should not be comparable.
PR libstdc++/93479
* libsupc++/compare (__3way_builtin_ptr_cmp): Require <=> to be valid.
* testsuite/18_
On 21/01/20 17:26 -0500, Patrick Palka wrote:
It seems that in practice std::sentinel_for is always true, and so the
Doh, good catch.
test_range container doesn't help us detect bugs in ranges code in which we
wrongly assume that a sentinel can be manipulated like an iterator. Make the
test_
Hi!
I've investigated a bit, because some of the following confused me while
working with some local 9.2-based branch.
Documentation issues:
(0) See patch for install.texi at the bottom, two possible values are
not documented. Ok for master? Backports?
(1) For me it seems confusing to have 'tr
On 29/01/2020 12:53, Tobias Burnus wrote:
Cf. PR93409 comments 4 and later. The comments 1–3 of the PR are covered
by patch https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01663.html (skip
building libgomp's HSA/GCN plugin with -mx32).
For AMDGCN, the LLVM assembler is used. While for LLVM 7+8,
On Tue, 28 Jan 2020, Martin Jambor wrote:
> Hi,
>
> PR 92486 shows that DSE, when seeing a "normal" gimple aggregate
> assignment coming from a C struct assignment and one a representing a
> folded memcpy, can kill the latter and keep in place only the former,
> which does not copy padding - at l
On 29/01/2020 12:30, Thomas Schwinge wrote:
Hi Andrew!
On 2019-11-22T11:06:14+, Andrew Stubbs wrote:
This test case causes an ICE (reformatted for email):
void test(int k)
{
unsigned int x = 1;
#pragma acc parallel loop async(x)
for (int i = 0; i < k; i++) { }
Cf. PR93409 comments 4 and later. The comments 1–3 of the PR are covered
by patch https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01663.html (skip
building libgomp's HSA/GCN plugin with -mx32).
For AMDGCN, the LLVM assembler is used. While for LLVM 7+8, GCC
generates code which is the same as LL
Stam Markianos-Wright writes:
> Hi all,
>
> This fixes:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93300
>
> Genmodes.c was generating the "wider_mode" chain as follows:
>
> HF -> BF -> SF - > DF -> TF -> VOID
>
> This caused issues in some rare cases where conversion between modes
> was nee
On 1/29/20 1:39 PM, Jan Hubicka wrote:
diff --git a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c
b/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c
index 61612b5b628..bbba0521018 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/indir-ca
> > diff --git a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c
> > b/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c
> > index 61612b5b628..bbba0521018 100644
> > --- a/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c
> > +++ b/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c
>
> This
Hi Andrew!
On 2019-11-22T11:06:14+, Andrew Stubbs wrote:
> This test case causes an ICE (reformatted for email):
>
>void test(int k)
>{
> unsigned int x = 1;
>#pragma acc parallel loop async(x)
> for (int i = 0; i < k; i++) { }
>}
Curious, why didn't you include suc
On 1/29/20 12:46 PM, Jan Hubicka wrote:
Hi,
this fixes indirect call speculation ICE Martin (Liska) reduced from
spec GCC. The problem here was in resolve_speculation that if called to
resolve the second edge in multi-target speculative call resolved first
on instead. This is bug I did not catc
Hi all,
This fixes:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93300
Genmodes.c was generating the "wider_mode" chain as follows:
HF -> BF -> SF - > DF -> TF -> VOID
This caused issues in some rare cases where conversion between modes was needed,
such as the above PR93300 where BFmode was b
Hi,
this fixes indirect call speculation ICE Martin (Liska) reduced from
spec GCC. The problem here was in resolve_speculation that if called to
resolve the second edge in multi-target speculative call resolved first
on instead. This is bug I did not catch during the API change.
Other problem is
Hi Andrew,
I think when committing this patch, you missed to regenerate gcc/configure.
At least with --enable-maintainer-mode, I see the attached changes – and
I think they come from your patch. (Line numbers might be off as I
edited out my changes.) — The other changes are due to
https://gcc
Hi Dragan,
I think your committed patch was incomplete – at least I see the
following bits when running --enable-maintainer-mode (see attachment,
line numbers wrong as I edited my changes out).
Can you re-check?
(The other change in gcc/configure seems to be due to Andrew Burgess's
e7c26e04
Hi Andrew,
On 29.01.20 11:38, Andrew Stubbs wrote:
> On 29/01/2020 09:52, Harwath, Frederik wrote:
>
> Patch 1 is OK with the formatting fixed.
> Patch 2 is OK.
>
> Thanks very much,
>
Committed as 2e5ea57959183bd5bd0356739bb5167417401a31 and
87c3fcfa6bbb5c372d4e275276d21f601d0b62b0.
Thank
LGTM – and also to Gerald. Hence, go ahead!
Thanks for the patch,
Tobias
On 1/29/20 1:45 AM, Andrew Benson wrote:
Hi Tobias,
On Tuesday, January 28, 2020 6:49:54 PM PST Tobias Burnus wrote:
Thus, I do not think it is a real problem in practice. We could be nice,
however, and add a note to th
On 29/01/2020 09:52, Harwath, Frederik wrote:
@@ -1513,6 +1518,23 @@ init_hsa_context (void)
GOMP_PLUGIN_error ("Failed to list all HSA runtime agents");
}
+ uint16_t minor, major;
+ status = hsa_fns.hsa_system_get_info_fn (HSA_SYSTEM_INFO_VERSION_MINOR,
&minor);
+ if (status
On Tue, 28 Jan 2020, Martin Jambor wrote:
> Hi,
>
> the previous patch unfortunately does not fix the first testcase in PR
> 92706 and since I am afraid it might be the important one, I also
> focused on that. The issue here is again total scalarization accesses
> clashing with those representin
On Tue, 28 Jan 2020, Martin Jambor wrote:
> Hi,
>
> this patch fixes the second testcase in PR 92706 by performing total
> scalarization only quite a bit later, when we already have access
> trees constructed and even done propagation of accesses from RHSs of
> assignment to LHSs.
>
> The new co
On 1/28/20 9:40 PM, Jan Hubicka wrote:
Hi,
I will try to reming this next stage1 since it is not regression fix.
I found it useful to have bit of sanity checking of the topn profiles to
work out the bugs in merging and updating that was there.
Hi.
Even though it's not a regression, I would lik
Hi Andrew,
On 28.01.20 16:42, Andrew Stubbs wrote:
> On 28/01/2020 14:55, Harwath, Frederik wrote:
>
> If we're going to use a fixed-size buffer then we should use snprintf and
> emit GCN_WARNING if the return value is greater than
> "sizeof(driver_version_s)", even though that is unlikely. Do
Hi,
in this regression we issue a diagnostic about an incomplete type (only
a warning by default) and then we crash when we try to query
has_attribute on a member of the type because in such cases the member
remains an IDENTIFIER_NODE which of course doesn't have a TREE_TYPE
neither a DECL_AT
On Tue, Jan 28, 2020 at 1:02 PM Jakub Jelinek wrote:
>
> On Tue, Jan 28, 2020 at 05:09:36PM +0530, Prathamesh Kulkarni wrote:
> > On Tue, 28 Jan 2020 at 17:00, Jakub Jelinek wrote:
> > >
> > > On Tue, Jan 28, 2020 at 04:56:59PM +0530, Prathamesh Kulkarni wrote:
> > > > Thanks for the suggestions.
On Tue, 28 Jan 2020, Andrew Benson wrote:
> I've attached a draft patch to update the release notes about this ABI
> breakage. I don't know if I've explained it sufficiently clearly though?
I do not speak Fortran, but your description was easy to read and
understand for me. :-)
Thank you, and ok
Pushed, though it would be really good for someone familiar with this
area to go through the whole document, too, for any updates.
Hans-Peter, any chance?
Gerald
---
htdocs/simtest-howto.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/simtest-howto.html b/htdocs/s
On Wed, Jan 29, 2020 at 3:55 AM Jeff Law wrote:
>
>
> Here's two approaches to fix the regression in 89689. Note this only
> fixes the regression in the originally reported testcase. THe deeper
> issue Martin raises in C#1 is not addressed. Thus if we go forward
> with either patch ISTM that we
Hi!
If the typeinfo decls appear in OpenMP default(none) regions, as we no longer
predetermine const with no mutable members, they are diagnosed as errors,
but it isn't something the users can actually provide explicit sharing for in
the clauses.
This patch makes those predetermined shared.
Boots
Hi!
As the testcase shows, some EXEC_OACC_* codes weren't handled in
oacc_code_to_statement. Fixed thusly.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2020-01-29 Jakub Jelinek
PR fortran/93463
* openmp.c (oacc_code_to_statement): Handle
On Tue, Jan 28, 2020 at 1:24 PM Uecker, Martin
wrote:
>
> Am Dienstag, den 28.01.2020, 11:01 +0100 schrieb Richard Biener:
> > On Tue, Jan 28, 2020 at 8:20 AM Alexander Monakov
> > wrote:
> > >
> > > On Tue, 28 Jan 2020, Uecker, Martin wrote:
> > >
> > > > > (*) this also shows the level of "obf
On Tue, Jan 28, 2020 at 5:53 PM Andrew Stubbs wrote:
>
> This patch fixes an ICE compiling fast-math-pr55281.c for amdgcn.
>
> The problem is that an "iv" is created in which both base and step are
> pointer types,
How did you get a POINTER_TYPE step? That's where the issue lies
I think.
> but
With SLP now being a graph with shared nodes across instances we have
to make sure to compute the load permutation of nodes once, not
overwriting the result of earlier analysis.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2020-01-28 Richard Biener
PR tree-o
80 matches
Mail list logo
