Hi,
Current vectorizer doesn't support masked loads for SLP. We should add that, to
allow things like:
void
f (int *restrict x, int *restrict y, int *restrict z, int n)
{
for (int i = 0; i < n; i += 2)
{
x[i] = y[i] ? z[i] : 1;
x[i + 1] = y[i + 1] ? z[i + 1] : 2;
}
}
to be
PR target/88861 reports an ICE in "ce2" due to an unreachable
basic block.
The block becomes unreachable in "combine" when delete_noop_moves
deletes an insn with a REG_EH_REGION, deleting the EH edge, the
only edge leading to the basic block.
Normally, rest_of_handle_combine would call
The original runtime testcases are incorrect and I have fixed them as attached.
Is it ok to do the revert and fix the testcases for trunk?
Wei
2019-01-16 Wei Xiao
* gcc.target/i386/avx512f-vfixupimmpd-2.c: Fix the test cases for
VFIXUPIMM* intrinsics.
*
On Wed, Jan 16, 2019 at 04:11:44AM -0800, H.J. Lu wrote:
> > Why? What is so special about C and (implicit?) casts where the rhs isn't
> > ADDR_EXPR? Aren't all casts (explicit or implicit) from one pointer type
> > to another pointer and satisfy the rules something that should be warned
>
>
> > Yes, but please test the compiler after the revert. Please also create
> > a runtime testcase out of the testcase in the PR.
Yes, we have tested it but current runtime testcase can't cover the corner
case to expose the incorrectness of SDM. We will add some after the revert.
> For r267160,
On Mon, Jan 14, 2019 at 10:00:11AM -0800, H.J. Lu wrote:
> On Mon, Jan 14, 2019 at 6:22 AM Jakub Jelinek wrote:
> >
> > On Sun, Jan 13, 2019 at 06:54:05AM -0800, H.J. Lu wrote:
> > > > What always matters is whether we take address of a packed structure
> > > > field/non-static data member or
On Wed, Jan 16, 2019 at 10:26 AM Martin Liška wrote:
>
> And there's patch with Richi's validation check that he provided.
> It fails on following 2 tests in test-suite:
>
> $ ./xgcc -B.
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr68674.c
> DECL_MODE BLK vs TYPE_MODE V8SI
On Wed, Jan 16, 2019 at 12:59 PM Jakub Jelinek wrote:
>
> On Wed, Jan 16, 2019 at 12:50:23PM +0100, Richard Biener wrote:
> > I guess so. There's not much we can do about this other than making
> > DECL_MODE dynamic the same way as TYPE_MODE. I still believe
> > this is the wrong direction and
On Wed, Jan 16, 2019 at 3:30 AM Jakub Jelinek wrote:
>
> On Mon, Jan 14, 2019 at 10:00:11AM -0800, H.J. Lu wrote:
> > On Mon, Jan 14, 2019 at 6:22 AM Jakub Jelinek wrote:
> > >
> > > On Sun, Jan 13, 2019 at 06:54:05AM -0800, H.J. Lu wrote:
> > > > > What always matters is whether we take address
I can't approve the patch, but I agree this is the right fix.
Bill
On 1/16/19 3:29 AM, Kewen.Lin wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87306, it's older POWER
> hardware specific test case issue. On POWER7 and earlier, we implicitly
> set flag -mno-allow-movmisalign
Hi,
On target rs6000, for all types, use of vec_ld/vec_st historically permits the
dereferenced pointer to be of a scalar type or the corresponding vector type.
But for vector unsigned/signed long long and double, we have an omission in our
table for vec_ld/vec_st.
Ok for trunk, and eventual
On Wed, 16 Jan 2019, Jakub Jelinek wrote:
> In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or
> defined(__ILP64__) and similar, but in these headers we can't, as no
> preprocessing is happening.
(With such preprocessing, the mechanism glibc uses for gnu/stubs.h and
While looking into 88815, a 9 regression, I realized we'll have to fix 78244
first. This patch fixes one half of 78244. The problem was that we never
detected narrowing conversion in a template, because the IMPLICIT_CONV_EXPR
template code doesn't have the information whether it was initialized
Hi!
This testcase violates aliasing and so is "miscompiled" e.g. on powerpc64
or aarch64 at -O2. Fixed thusly, tested on powerpc64-linux, committed to
trunk as obvious.
2019-01-16 Jakub Jelinek
PR c/51628
PR target/88682
* c-c++-common/pr51628-10.c
On Wed, Jan 16, 2019 at 12:50:23PM +0100, Richard Biener wrote:
> I guess so. There's not much we can do about this other than making
> DECL_MODE dynamic the same way as TYPE_MODE. I still believe
> this is the wrong direction and instead RTL expansion should properly
> adjust DECL_RTL and
On Wed, Jan 16, 2019 at 10:42:13AM +0100, Martin Liška wrote:
> On 1/15/19 6:45 PM, Joseph Myers wrote:
> > On Mon, 14 Jan 2019, Martin Liška wrote:
> >
> >> Thanks for review, fixed that in updated version of the patch.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression
On Wed, 16 Jan 2019, Martin Liška wrote:
> Now we should add the header file into glibc, I kicked a discussion here:
> https://sourceware.org/ml/libc-help/2018-11/msg00015.html
libc-help is for user questions. It's not suitable for glibc development
discussions.
--
Joseph S. Myers
On Wed, Jan 16, 2019 at 10:20 AM Martin Liška wrote:
>
> Hi.
>
> The patch is about resetting TYPE_MODE of vector types. This is problematic
> when an inlining among different ISAs happen. Then we end up with a different
> mode than when it's expected from debug info.
>
> When creating a new
On Wed, Jan 16, 2019 at 11:03:41AM -0600, Tamar Christina wrote:
> Hi All,
>
> We had multiple patches in flight that required used of scratch registers in
> frame layout code. As it happens two of these features picked the same
> register
> and landed at around the same time. As such there is
Hi!
Thanks for working on this.
On Wed, Jan 16, 2019 at 10:20:26AM -0500, David Malcolm wrote:
> PR target/88861 reports an ICE in "ce2" due to an unreachable
> basic block.
>
> The block becomes unreachable in "combine" when delete_noop_moves
> deletes an insn with a REG_EH_REGION, deleting
On 16-01-19 02:02, Ian Lance Taylor wrote:
> On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries wrote:
>>
>> Add an altlink field to struct dwarf_data, and initialize it with the pointer
>> to the struct dwarf_data for the .gnu_debugaltlink.
>>
>> 2018-11-11 Tom de Vries
>>
>> * dwarf.c
On 16-01-19 02:15, Ian Lance Taylor wrote:
> On Tue, Dec 11, 2018 at 2:15 AM Tom de Vries wrote:
>>
>> Factor out the common handling of DW_AT_abstract_origin and
>> DW_AT_specification from read_function_entry and read_referenced_name.
>>
>> 2018-12-10 Tom de Vries
>>
>> * dwarf.c
On Wed, Jan 16, 2019 at 8:26 AM Tom de Vries wrote:
>
> On 16-01-19 01:56, Ian Lance Taylor wrote:
> > On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries wrote:
> >>
> >> Read the elf file pointed at by the .gnu_debugaltlink section, and verify
> >> that
> >> the build id matches.
> >>
> >>
Hi!
On Wed, Jan 16, 2019 at 05:29:30PM +0800, Kewen.Lin wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87306, it's older POWER
> hardware specific test case issue. On POWER7 and earlier, we implicitly
> set flag -mno-allow-movmisalign which disables vectorization when to
> vectorize the
On Wed, 16 Jan 2019, Joseph Myers wrote:
> On Wed, 16 Jan 2019, Jakub Jelinek wrote:
>
> > In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or
> > defined(__ILP64__) and similar, but in these headers we can't, as no
> > preprocessing is happening.
>
> (With such
Hi All,
We had multiple patches in flight that required used of scratch registers in
frame layout code. As it happens two of these features picked the same register
and landed at around the same time. As such there is a clash when both are used
at the same time. This patch changes the
On Wed, Jan 16, 2019 at 8:33 AM Tom de Vries wrote:
>
> > Why is it void**?
>
> It's really struct dwarf_data *, but struct dwarf_data is a type
> declared in dwarf.c, so it's not known in other files.
It woud be OK to add "struct dwarf_data;" to internal.h and refer to
the struct, without
On Wed, Jan 16, 2019 at 05:42:06PM +, Joseph Myers wrote:
> On Wed, 16 Jan 2019, Joseph Myers wrote:
>
> > On Wed, 16 Jan 2019, Jakub Jelinek wrote:
> >
> > > In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4
> > > or
> > > defined(__ILP64__) and similar, but in these
On Tue, Jan 15, 2019 at 09:29:46AM -0600, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds a tuning struct for the Arm Ares CPU and uses it for
> -m{cpu,tune}=ares.
> The tunings are an initial attempt and may be improved upon in the future,
> but they serve
> as a decent starting point for
On Wed, Jan 16, 2019 at 8:37 AM Tom de Vries wrote:
>
> On 16-01-19 02:15, Ian Lance Taylor wrote:
> > On Tue, Dec 11, 2018 at 2:15 AM Tom de Vries wrote:
> >>
> >> Factor out the common handling of DW_AT_abstract_origin and
> >> DW_AT_specification from read_function_entry and
On 16-01-19 01:56, Ian Lance Taylor wrote:
> On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries wrote:
>>
>> Read the elf file pointed at by the .gnu_debugaltlink section, and verify
>> that
>> the build id matches.
>>
>> 2018-11-11 Tom de Vries
>>
>> * elf.c (elf_add): Add and handle
Hi All,
The test tries to link with -shared and compile with -fPIC
without checking to see if the target actually supports this.
This patch adds effective-target requirements for fpic and shared.
Regtested on aarch64-none-elf and x86_64-unknown-linux-gnu and no
issues.
Committed under the GCC
On 1/16/19 7:32 AM, Marek Polacek wrote:
While looking into 88815, a 9 regression, I realized we'll have to fix 78244
first. This patch fixes one half of 78244. The problem was that we never
detected narrowing conversion in a template, because the IMPLICIT_CONV_EXPR
template code doesn't have
On 16-01-19 02:19, Ian Lance Taylor wrote:
> On Tue, Dec 11, 2018 at 2:16 AM Tom de Vries wrote:
>>
>> 2018-11-11 Tom de Vries
>>
>> * configure.ac (DWZ): Set with AC_CHECK_PROG.
>> (HAVE_DWZ): Set with AM_CONDITIONAL.
>> * configure: Regenerate.
>> *
Hi Kewen,
On Wed, Jan 16, 2019 at 10:08:46PM +0800, Kewen.Lin wrote:
> On target rs6000, for all types, use of vec_ld/vec_st historically permits
> the dereferenced pointer to be of a scalar type or the corresponding vector
> type. But for vector unsigned/signed long long and double, we have an
On 1/15/19 5:27 PM, Paolo Carlini wrote:
Hi Martin,
On 15/01/19 21:42, Martin Sebor wrote:
On 1/15/19 9:58 AM, Paolo Carlini wrote:
Hi,
something a little different from my last patches but nevertheless
pretty straightforward (noticed while I was wondering whether we
should immediately
On Wed, Jan 16, 2019 at 8:35 AM Tom de Vries wrote:
>
> On 16-01-19 02:06, Ian Lance Taylor wrote:
> > On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries wrote:
> >>
> >> Handle DW_FORM_GNU_strp_alt and DW_FORM_GNU_ref_alt references robustly in
> >> presence of missing .gnu_debugaltlink file.
> >>
>
On Wed, Jan 16, 2019 at 10:28 AM James Greenhalgh
wrote:
>
> On Tue, Jan 15, 2019 at 09:29:46AM -0600, Kyrill Tkachov wrote:
> > Hi all,
> >
> > This patch adds a tuning struct for the Arm Ares CPU and uses it for
> > -m{cpu,tune}=ares.
> > The tunings are an initial attempt and may be improved
Further investigation showed that my previous patch for this issue was
still incomplete.
The problem stemmed from what I suspect was a mis-understanding of the
way overflow is calculated on aarch64 when values are subtracted (and
hence in comparisons). In this case, unlike addition, the carry
Hello!
Attached patch corrects handing of split _Complex float variable
arguments. Alpha is not able to pass 32bit floats in float registers
as variable arguments (see the comment in alpha_pass_by_reference), so
we pass them by reference. However, complex float arguments are split
to their real
On Mon, Jan 14, 2019 at 12:49:33PM -0600, Aaron Sawdey wrote:
> The patch for this was committed to trunk as 267562 (see below). Is this also
> ok for backport to 8?
Yes please. Thanks!
Segher
> On 12/20/18 5:44 PM, Segher Boessenkool wrote:
> > On Thu, Dec 20, 2018 at 05:34:54PM -0600,
On Mon, Jan 14, 2019 at 08:01:47AM -0600, Tamar Christina wrote:
> Hi All,
>
>
> This patch fixes some ICEs when the fcmla_lane intrinsics are used on
> big endian by correcting the lane indices and removing the hardcoded byte
> offset from subreg calls and instead use subreg_lowpart_offset.
On Wed, Jan 16, 2019 at 10:48:28PM +0800, Wei Xiao wrote:
> The original runtime testcases are incorrect and I have fixed them as
> attached.
> Is it ok to do the revert and fix the testcases for trunk?
LGTM.
> 2019-01-16 Wei Xiao
>
> * gcc.target/i386/avx512f-vfixupimmpd-2.c: Fix
Hi,
On Mon, Dec 10 2018, Richard Biener wrote:
> On Fri, Dec 7, 2018 at 3:59 PM Martin Jambor wrote:
>>
>> Hi,
>>
>> ICE in PR 88214 happens because a type-mismatch in K C code makes
>> IPA-CP analysis call ao_ref_init_from_ptr_and_size on an integer
>> SSA_NAME, this function in turn constructs
On 16-01-19 17:33, Tom de Vries wrote:
> On 16-01-19 02:02, Ian Lance Taylor wrote:
>> On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries wrote:
>>>
>>> Add an altlink field to struct dwarf_data, and initialize it with the
>>> pointer
>>> to the struct dwarf_data for the .gnu_debugaltlink.
>>>
>>>
On 16-01-19 02:06, Ian Lance Taylor wrote:
> On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries wrote:
>>
>> Handle DW_FORM_GNU_strp_alt and DW_FORM_GNU_ref_alt references robustly in
>> presence of missing .gnu_debugaltlink file.
>>
>> 2018-11-11 Tom de Vries
>>
>> * dwarf.c (enum
On Wed, Jan 16, 2019 at 8:39 AM Tom de Vries wrote:
>
> On 16-01-19 02:19, Ian Lance Taylor wrote:
> > On Tue, Dec 11, 2018 at 2:16 AM Tom de Vries wrote:
> >>
> >> 2018-11-11 Tom de Vries
> >>
> >> * configure.ac (DWZ): Set with AC_CHECK_PROG.
> >> (HAVE_DWZ): Set with
On Wed, 16 Jan 2019, Jakub Jelinek wrote:
> Perhaps easier would be to add optional if clause to the !GCC$ builtin
> with constant expression argument which if present and evaluates to .false.
> would tell us to ignore the attribute. Or, add !GCC$ if/else/end if which
> would act like
On 16-01-19 17:34, Tom de Vries wrote:
> On 16-01-19 17:33, Tom de Vries wrote:
>> On 16-01-19 02:02, Ian Lance Taylor wrote:
>>> On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries wrote:
Add an altlink field to struct dwarf_data, and initialize it with the
pointer
to the struct
On Wed, Jan 16, 2019 at 03:48:07PM -0700, Jeff Law wrote:
> > 2019-01-16 Jakub Jelinek
> >
> > PR rtl-optimization/88870
> > * dce.c (deletable_insn_p): Never delete const/pure calls that can
> > throw if we can't alter the cfg or delete dead exceptions.
> > (mark_insn): Don't
* config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Add exports for fstream
constructors and open members taking wide strings. Fix patterns for
filesystem::path members to match wstring_view parameters. Add
exports for shared_ptr members used by directory iterators.
PR c++/88699 reports an ICE within this assertion in add_method:
gcc_assert (!current_fns || !DECL_DESTRUCTOR_P (method));
when adding an overloaded operator to a class via a using_decl, due to
DECL_DESTRUCTOR_P requiring a FUNCTION_DECL, but "method" being a
USING_DECL.
This patch weakens
Hi,
This patches fixes one of the problems noted in PR d/87824, where
exception chaining does not work as per expected semantics if
-forder-blocks-and-partition is enabled on i386.
Having it default off if not explicitly given seems the most
reasonable thing to do, as there's no alternative way
This patch by Cherry Zhang marks the syscall functions that call into
C code as noescape, so that calling syscall functions that take
pointers do not require allocation. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
Hi!
While looking at this PR (I've just started) I've noticed that
add_stack_var_conflict is quite often called with x == y.
We don't really need to record that a variable conflicts with itself,
the only reader of the conflicts bitmaps, stack_var_conflict_p,
starts with
if (x == y)
return
On 16-01-19 18:14, Ian Lance Taylor wrote:
> On Wed, Jan 16, 2019 at 8:26 AM Tom de Vries wrote:
>>
>> On 16-01-19 01:56, Ian Lance Taylor wrote:
>>> On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries wrote:
Read the elf file pointed at by the .gnu_debugaltlink section, and verify
that
On 1/16/19 3:43 PM, Jakub Jelinek wrote:
> Hi!
>
> For normal instructions, deletable_insn_p has:
> /* Don't delete insns that may throw if we cannot do so. */
> if (!(cfun->can_delete_dead_exceptions && can_alter_cfg)
> && !insn_nothrow_p (insn))
> return false;
>
> The following
On Wed, Jan 16, 2019 at 2:48 PM Tom de Vries wrote:
>
> For now, I've dropped the error callback for .gnu_debugaltlink.
This version is OK.
Thanks.
Ian
On Wed, Jan 16, 2019 at 2:20 PM Tom de Vries wrote:
>
> On 16-01-19 17:34, Tom de Vries wrote:
> > On 16-01-19 17:33, Tom de Vries wrote:
> >> On 16-01-19 02:02, Ian Lance Taylor wrote:
> >>> On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries wrote:
>
> Add an altlink field to struct
On 1/16/19 3:49 PM, Jakub Jelinek wrote:
> Hi!
>
> While looking at this PR (I've just started) I've noticed that
> add_stack_var_conflict is quite often called with x == y.
> We don't really need to record that a variable conflicts with itself,
> the only reader of the conflicts bitmaps,
On Mon, Jan 14, 2019 at 03:23:07PM -0800, H.J. Lu wrote:
> There are no regressions with this patch:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00792.html
As the patch seems to be a step forward and fixes an important regression,
the patch is ok for trunk, but I'd like to keep discussions
On 1/11/19 2:27 PM, Joseph Myers wrote:
On Fri, 11 Jan 2019, Martin Sebor wrote:
gcc/testsuite/ChangeLog:
PR c/88718
* gcc.dg/inline-40.c: New test.
* gcc.dg/inline-41.c: New test.
We already have tests inline-40.c and inline-41.c; these need to be
renumbered
This PR reports a bug where we select a non-const operator function and
then apply it to a const object. That's happening because the
expression 'c[0]' is not dependent, so we figure end up resolving it.
But the lambda capture logic doesn't capture 'c' at that point and we
have a non-const
On Wed, 2019-01-16 at 08:50 +, Richard Sandiford wrote:
>
> I suggest for now we add:
>
> /* { dg-excess-errors "partial simd clone support" { target { aarch64*-*-* }
> } } */
OK, that works.
>
> ...this doesn't handle explicit simdlen correctly. The vecsize_int and
> vecsize_float
On 1/16/19 4:48 PM, Nathan Sidwell wrote:
This PR reports a bug where we select a non-const operator function and
then apply it to a const object. That's happening because the
expression 'c[0]' is not dependent, so we figure end up resolving it.
But the lambda capture logic doesn't capture
Hi!
For normal instructions, deletable_insn_p has:
/* Don't delete insns that may throw if we cannot do so. */
if (!(cfun->can_delete_dead_exceptions && can_alter_cfg)
&& !insn_nothrow_p (insn))
return false;
The following patch adds that for the const/pure non-looping calls
that
On 16-01-19 18:17, Ian Lance Taylor wrote:
> On Wed, Jan 16, 2019 at 8:33 AM Tom de Vries wrote:
>>
>>> Why is it void**?
>>
>> It's really struct dwarf_data *, but struct dwarf_data is a type
>> declared in dwarf.c, so it's not known in other files.
>
> It woud be OK to add "struct dwarf_data;"
On Wed, Jan 16, 2019 at 2:18 PM Tom de Vries wrote:
>
> On 16-01-19 18:17, Ian Lance Taylor wrote:
> > On Wed, Jan 16, 2019 at 8:33 AM Tom de Vries wrote:
> >>
> >>> Why is it void**?
> >>
> >> It's really struct dwarf_data *, but struct dwarf_data is a type
> >> declared in dwarf.c, so it's not
This libgo patch by Cherry Zhang changes the runtime package to call
dropg before changing the g status to _Grunnable/_Gwaiting.
Currently, we dropg (which clears gp.m) after we CAS the g status to
_Grunnable or _Gwaiting. Immediately after CASing the g status,
another thread may CAS it to
On 1/16/19 11:10 PM, Alexandre Oliva wrote:
On Jan 8, 2019, Jason Merrill wrote:
On 12/28/18 2:45 PM, Alexandre Oliva wrote:
+ if (template_placeholder_p (t)
+ && DECL_P (CLASS_PLACEHOLDER_TEMPLATE (t))
+ && TYPE_IDENTIFIER (TREE_TYPE (CLASS_PLACEHOLDER_TEMPLATE (t
On Wed, Jan 16, 2019 at 01:28:26PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 16, 2019 at 04:11:44AM -0800, H.J. Lu wrote:
> > > Why? What is so special about C and (implicit?) casts where the rhs isn't
> > > ADDR_EXPR? Aren't all casts (explicit or implicit) from one pointer type
> > > to
On 1/16/19 6:14 PM, Jeff Law wrote:
On 1/15/19 8:21 AM, Martin Sebor wrote:
On 1/15/19 4:07 AM, Richard Biener wrote:
On Tue, Jan 15, 2019 at 1:08 AM Martin Sebor wrote:
The gimple_fold_builtin_memory_op() function folds calls to memcpy
and similar to MEM_REF when the size of the copy is a
On Jan 4, 2019, Jason Merrill wrote:
> if (tree fn = cp_get_callee_fndecl_nofold (expr))
> if (DECL_CONSTRUCTOR_P (fn) || DECL_DESTRUCTOR_P (fn))
> ? The other patch is OK with that change.
Thanks, I've regstrapped this on x86_64- and i686-linux-gnu, and I'm
checking it in momentarily.
On 1/15/19 8:21 AM, Martin Sebor wrote:
> On 1/15/19 4:07 AM, Richard Biener wrote:
>> On Tue, Jan 15, 2019 at 1:08 AM Martin Sebor wrote:
>>>
>>> The gimple_fold_builtin_memory_op() function folds calls to memcpy
>>> and similar to MEM_REF when the size of the copy is a small power
>>> of 2, but
On 1/15/19 9:31 AM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html
>
> Jeff, do you have any more questions/concerns or is this patch
> good to commit?
I think both Jakub and I were concerned about handling expressions in
this code. I don't recall a
On 1/16/19 11:26 PM, Alexandre Oliva wrote:
On Jan 2, 2019, Jason Merrill wrote:
On 12/30/18 11:31 PM, Alexandre Oliva wrote:
Concepts-checking and other kinds of early tsubsting may often take
place while location wrappers are suppressed, e.g. because we've
triggered template instantiation
Hi all,
To facilitate more complete Fortran 2018 failed images support, I'm
particularly interested in interested in seeing PR 87939 eventually
resolved (i.e., allow STAT= and ERRMSG= specifiers in FORM TEAM,
CHANGE TEAM, SYNC TEAM, END TEAM, and CRITICAL statements). To get the
ball rolling (I
On Wed, Jan 16, 2019 at 4:17 PM Tom de Vries wrote:
>
> this handles DW_FORM_GNU_ref_alt which references the .debug_info
> section in the .gnu_debugaltlink file.
>
> OK for trunk?
>
> Thanks,
> - Tom
>
> On 11-12-18 11:14, Tom de Vries wrote:
> > 2018-12-10 Tom de Vries
> >
> > *
On Wed, 16 Jan 2019, Martin Sebor wrote:
> + /* Iterate over tentative records (all those at the head of the list
> + with a null FUNCTION) and either associate them with DECL when ADD
> + is set or remove them from it otherwise. */
> + for (c_inline_static *csi = c_inline_statics,
On Jan 2, 2019, Jason Merrill wrote:
> On 12/30/18 11:31 PM, Alexandre Oliva wrote:
>> Concepts-checking and other kinds of early tsubsting may often take
>> place while location wrappers are suppressed, e.g. because we've
>> triggered template instantiation within template parameter lists.
>>
Hi,
this handles DW_FORM_GNU_ref_alt which references the .debug_info
section in the .gnu_debugaltlink file.
OK for trunk?
Thanks,
- Tom
On 11-12-18 11:14, Tom de Vries wrote:
> 2018-12-10 Tom de Vries
>
> * dwarf.c (enum attr_val_encoding): Add ATTR_VAL_REF_ALT_INFO.
> (struct
On 7/5/18 2:22 PM, Jeff Law wrote:
On 06/28/2018 09:14 AM, Martin Sebor wrote:
On 06/27/2018 11:20 PM, Jeff Law wrote:
On 06/26/2018 05:32 PM, Martin Sebor wrote:
Attached is an updated patch to tighten up the warning and also
prevent ICEs in the middle-end like in PR 86308 or PR 86202.
I
Nathan,
Thanks for taking an interesting in improving gfortran. A
scan of the bug database certainly suggests we can use the
help particularly with coarray bugs. Before we can go much
further, do you have a copyright assignment on file the FSF.
If not, please see
Hi Gerald,
Updated version, please review.
Thanks.
On Mon, Jan 14, 2019 at 7:46 AM Gerald Pfeifer wrote:
>
> Hi Paul,
>
> On Mon, 31 Dec 2018, Paul Hua wrote:
> > The attached patch mention Loongson 3a1000 3a2000 3a3000 2k1000 support
> > in gcc9.
>
> thanks for putting this together. Only a
On Jan 8, 2019, Jason Merrill wrote:
> On 12/28/18 2:45 PM, Alexandre Oliva wrote:
>> + if (template_placeholder_p (t)
>> + && DECL_P (CLASS_PLACEHOLDER_TEMPLATE (t))
>> + && TYPE_IDENTIFIER (TREE_TYPE (CLASS_PLACEHOLDER_TEMPLATE (t
> Are these extra checks needed?
Nope,
Hello world,
the attached patch fixes PR 88871, a regression introduced by
my recent patch for removing unnecessary substrings.
Regression-tested; this now also works with valgrind on Linux,
where the failure did not show up otherwise.
No test case because, well - it did show up on a few
On Wed, Jan 16, 2019 at 2:37 PM Alejandro Martinez Vicente
wrote:
>
> Hi,
>
> Current vectorizer doesn't support masked loads for SLP. We should add that,
> to
> allow things like:
>
> void
> f (int *restrict x, int *restrict y, int *restrict z, int n)
> {
> for (int i = 0; i < n; i += 2)
>
On Thu, Jan 17, 2019 at 2:51 AM Martin Sebor wrote:
>
> On 1/16/19 6:14 PM, Jeff Law wrote:
> > On 1/15/19 8:21 AM, Martin Sebor wrote:
> >> On 1/15/19 4:07 AM, Richard Biener wrote:
> >>> On Tue, Jan 15, 2019 at 1:08 AM Martin Sebor wrote:
>
> The gimple_fold_builtin_memory_op()
Hi Tamar,
On 15/01/19 17:05, Tamar Christina wrote:
Hi All,
We are a bit inconsistent when it comes to lane index endianness on Arm,
we don't seem to always stick to the expected GCC vector extensions index
endianness, for these tests since they are modelled as UNSPEC anyway just
keep the
On Fri, 11 Jan 2019 13:00:22 -0700
Jeff Law wrote:
> On 12/30/18 4:51 AM, Jozef Lawrynowicz wrote:
> >
> > The attached patch adds an assertion that SET_{DECL,TYPE}_ALIGN is called
> > with
> > a value which is a power of 2, or 0, for targets which support a partial int
> > mode. This should
And there's patch with Richi's validation check that he provided.
It fails on following 2 tests in test-suite:
$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr68674.c
DECL_MODE BLK vs TYPE_MODE V8SI [V8SI]: a
...
$ ./xgcc -B.
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87306, it's older POWER
hardware specific test case issue. On POWER7 and earlier, we implicitly
set flag -mno-allow-movmisalign which disables vectorization when to
vectorize the code requires that misaligned loads and stores. For POWER8
and
On 1/15/19 6:45 PM, Joseph Myers wrote:
> On Mon, 14 Jan 2019, Martin Liška wrote:
>
>> Thanks for review, fixed that in updated version of the patch.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>
> This patch is OK.
>
Great, thank
On 1/15/19 5:25 PM, H.J. Lu wrote:
> On Tue, Jan 15, 2019 at 7:05 AM Martin Liška wrote:
>>
>> On 1/15/19 3:19 PM, H.J. Lu wrote:
>>> On Tue, Jan 15, 2019 at 6:07 AM Martin Liška wrote:
On 1/14/19 3:14 PM, H.J. Lu wrote:
> On Mon, Jan 14, 2019 at 5:53 AM Richard Biener
>
Hi,
this adds myself to MAINTAINERS in the Write After Approval section.
Committed to trunk as r267965.
---
Index: ChangeLog
===
--- ChangeLog (revision 267964)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2019-01-16 Kewen
Hi.
The patch is about resetting TYPE_MODE of vector types. This is problematic
when an inlining among different ISAs happen. Then we end up with a different
mode than when it's expected from debug info.
When creating a new function decl in target_clones, we must valid_attribute_p
early
so that
Steve Ellcey writes:
> Here are the failures I am getting with this patch:
>
> c-c++-common/gomp/pr63328.c
> gcc.dg/gomp/pr87895-2.c
>
> These tests include another test (which passes) and the included tests
> have a dg-warning check. For some reason the dg-warning in the include
> is ignored
97 matches
Mail list logo
