Hi,
The test g++.dg/vect/slp-pr56812.cc is somewhat fragile and is currently failing
on several targets. PR81038 notes that this began with r248678, which stopped
some inferior peeling solutions from preventing vectorization that could be done
without peeling. I observed that for powerpc64le, r2
On Thu, 2018-02-01 at 12:05 +0100, Richard Biener wrote:
> On Wed, Jan 31, 2018 at 4:39 PM, David Malcolm
> wrote:
> > PR 84136 reports an ICE within sccvn_dom_walker when handling a
> > C/C++ source file that overuses the labels-as-values extension.
> > The code in question stores a jump label in
On Fri, 2 Feb 2018, Andrew Jenner wrote:
> This patch adds a section to invoke.texi for the new PowerPC SPE backend,
> mostly copied from the PowerPC backend but with irrelevant options removed.
I think a lot of the remaining options are also irrelevant to powerpcspe.
> The patch also removes do
Ping
On Fri, 2018-01-26 at 13:12 -0500, David Malcolm wrote:
> On Mon, 2017-12-11 at 17:24 -0500, Jason Merrill wrote:
> > On Wed, Nov 22, 2017 at 10:36 AM, David Malcolm > m>
> > wrote:
>
> Original post:
> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02048.html
>
> > > PR c++/81610 and PR
> I think it should be a predefined macro.
Macros cannot be used outside of the C family of languages while builtins can,
but a macro might be sufficient in practice and easier to implement indeed.
--
Eric Botcazou
On Fri, Feb 2, 2018 at 12:55 PM, Eric Botcazou wrote:
>> But, that is not what the builtin setjmp/longjmp tests have.
>
> Yes, but I don't think that we want to risk breaking a working compiler on
> some targets because peculiar tests don't pass on another. I think that
> init_eh is OK for x32 so
> But, that is not what the builtin setjmp/longjmp tests have.
Yes, but I don't think that we want to risk breaking a working compiler on
some targets because peculiar tests don't pass on another. I think that
init_eh is OK for x32 so SJLJ exceptions work and the issue is only with the
undocum
On Mon, Jan 29, 2018 at 6:29 PM, Jakub Jelinek wrote:
> Hi!
>
> In r245223 cp_parser_postfix_dot_deref_expression has been changed to
> workaround some buggy template code with a pedwarn instead of error,
> in r245440 Marek tweaked that by adding the && EXPR_P (postfix_expression)
> because we rea
On Fri, Feb 02, 2018 at 02:17:59PM +, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Segher Boessenkool writes:
> >> On Fri, Jan 26, 2018 at 01:25:51PM +, Richard Sandiford wrote:
> >>> if (SCALAR_INT_MODE_P (inmode))
> >>> new_out_reg = gen_lowpart_SUBREG (outmode, re
OK.
On Thu, Jan 25, 2018 at 4:04 PM, Paolo Carlini wrote:
> Hi,
>
> this is the complete patch, tested x86_64-linux.
>
> Thanks, Paolo.
>
>
>
On Thu, Jan 25, 2018 at 4:16 PM, Marek Polacek wrote:
> This is a similar problem to 83116: we'd cached a constexpr call, but after a
> store the result had become invalid, yet we used the wrong result again when
> encountering the same call later. This resulted in evaluating a THROW_EXPR
> which
On Fri, Feb 2, 2018 at 10:24 AM, Rainer Orth
wrote:
>
>>> the new test FAILs on Solaris 10, sparc and x86 (only, 11 is fine) at
>>> all optimization levels:
>>>
>>> +FAIL: go.go-torture/execute/printnil.go execution, -O0
>>> +FAIL: go.go-torture/execute/printnil.go execution, -O1
>>> +FAIL: go.g
The design of the attribute exclusion framework includes
support for different exclusions applying to different
kinds of declarations (functions, types, and variables
or fields), but the support is incomplete -- the logic
to consider these differences is missing. This is
because the differences a
On Fri, Feb 2, 2018 at 10:54 AM, Eric Botcazou wrote:
>> One more thing. Word can be bigger than pointer on ILP32 targets.
>> 5 pointers aren't sufficient.
>
> Yes, that's why the buffer should be 5 words, as init_eh allocates now.
>
But, that is not what the builtin setjmp/longjmp tests have.
On Feb 2, 2018, at 5:25 AM, Bernhard Reutner-Fischer
wrote:
>
> Given the overwhelming silence this proposal has received, i take it
> for granted that folks are thrilled and even up until now speechless
> :)
> -fno-ident ok for stage1?
> What about -fno-file? Clever alternative suggestions? Do
> One more thing. Word can be bigger than pointer on ILP32 targets.
> 5 pointers aren't sufficient.
Yes, that's why the buffer should be 5 words, as init_eh allocates now.
--
Eric Botcazou
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Brazilian Portuguese team of translators. The file is available at:
http://translationproject.org/latest/cpplib/pt_BR.po
(This file, 'cppl
cpplib-8.1-b20180128.pt_BR.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Fri, Feb 2, 2018 at 9:57 AM, H.J. Lu wrote:
> On Fri, Feb 2, 2018 at 9:53 AM, Eric Botcazou wrote:
>>> We currently read and write beyond the builtin jmpbuf on ILP32 targets
>>> where Pmode == DImode and ptr_mode == SImode. Since the builtin jmpbuf
>>> is an array of 5 pointers, ptr_mode shou
Hi Ian,
>> the new test FAILs on Solaris 10, sparc and x86 (only, 11 is fine) at
>> all optimization levels:
>>
>> +FAIL: go.go-torture/execute/printnil.go execution, -O0
>> +FAIL: go.go-torture/execute/printnil.go execution, -O1
>> +FAIL: go.go-torture/execute/printnil.go execution, -O2
>> +FA
On Fri, Feb 2, 2018 at 9:53 AM, Eric Botcazou wrote:
>> We currently read and write beyond the builtin jmpbuf on ILP32 targets
>> where Pmode == DImode and ptr_mode == SImode. Since the builtin jmpbuf
>> is an array of 5 pointers, ptr_mode should be used to save and restore
>> frame and program p
> We currently read and write beyond the builtin jmpbuf on ILP32 targets
> where Pmode == DImode and ptr_mode == SImode. Since the builtin jmpbuf
> is an array of 5 pointers, ptr_mode should be used to save and restore
> frame and program pointers. Since x86 only saves stack pointer in
> stack sa
This patch adds a section to invoke.texi for the new PowerPC SPE
backend, mostly copied from the PowerPC backend but with irrelevant
options removed.
The patch also removes documentation of the SPE-specific options -mspe,
-mno-spe and -mfloat-gprs from the PowerPC backend (these options have
I have committed this patch to suppress options that are not relevant to
powerpcspe targets from appearing in the output of "gcc --target-help".
For now this is done by marking such options in powerpcspe.opt as
Undocumented, and manually editing powerpcspe-tables.opt to remove most
of the CPU v
nocf_check attribute can be used with -fcf-protection -mcet to disable
control-flow check by adding NOTRACK prefix before indirect branch.
When -mindirect-branch=thunk-extern -mindirect-branch-register is added,
indirect branch via register, "notrack call/jmp reg", is converted to
call/jmp __x
Right, so here is version 2 which ends up much simpler:
The comparison function for SCHED_PRESSURE_MODEL is incorrect. If either
instruction is not in target_bb, the ordering is not well defined.
Since all instructions outside the target_bb get the highest model_index,
all we need to do is sort
On Fri, Feb 2, 2018 at 5:36 PM, H.J. Lu wrote:
> On Tue, Jan 16, 2018 at 11:48 AM, Uros Bizjak wrote:
>> On Sun, Jan 14, 2018 at 5:43 PM, Uros Bizjak wrote:
>>> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
> On Fri, Jan 12, 2018 a
On Tue, Jan 16, 2018 at 11:48 AM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 5:43 PM, Uros Bizjak wrote:
>> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
>>> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
> On Thu, Jan 11, 2
Here, strip_typedefs_expr was walking into PACK_EXPANSION_EXTRA_ARGS,
which it shouldn't do. Fixed by using cp_tree_operand_length, which
was created to address this sort of issue.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit bdf6657e3f32e903915046540c1dc6d875c32ea5
Author: Jason Merrill
Hi Richard,
On 02/02/18 15:25, Richard Earnshaw (lists) wrote:
On 02/02/18 15:10, Kyrill Tkachov wrote:
Hi all,
In this [8 Regression] PR we ICE because we can't recognise the insn:
(insn 59 58 43 7 (set (reg:DI 124)
(rotatert:DI (reg:DI 125 [ c ])
(subreg:QI (and:SI (reg
On 02/02/18 15:10, Kyrill Tkachov wrote:
> Hi all,
>
> In this [8 Regression] PR we ICE because we can't recognise the insn:
> (insn 59 58 43 7 (set (reg:DI 124)
> (rotatert:DI (reg:DI 125 [ c ])
> (subreg:QI (and:SI (reg:SI 128)
> (const_int 65535 [0x])
Hi!
On Wed, Jan 31, 2018 at 01:29:40PM -0600, Will Schmidt wrote:
> Noticed during a review of test results on an AIX platform, a few
> of the (p9 target specific) tests are expecting to see Power9 codegen, but
> are failing to build due to the environment missing P9 assembler support.
> Thus,
The interface between the Go frontend and the GCC middle-end sets the
return type of a function type that returns a zero-sized value to
void_type_node. This was done to avoid confusion with libffi, for PR
72814. However, there are various ways that Go code can correctly use
a zero-sized type retu
Hi!
On Wed, Jan 31, 2018 at 01:50:37PM -0600, Will Schmidt wrote:
> The vec-cmpne-long.c tests targets -mcpu=power8, but always dg-do-run, even
> on P7 (or earlier) systems. Add a dg-do run requirement for p8vector_hw to
> prevent illegal instruction errors.
> (noticed during review of test res
On 01/02/18 17:26, Joseph Myers wrote:
On Thu, 1 Feb 2018, Kyrill Tkachov wrote:
Hi Joseph, aarch64 maintainers,
On 28/09/17 13:31, Joseph Myers wrote:
Many GCC tests fail for AArch64 with current binutils because of
assembler warnings of the form "Warning: ignoring incorrect section
type f
Hi all,
In this [8 Regression] PR we ICE because we can't recognise the insn:
(insn 59 58 43 7 (set (reg:DI 124)
(rotatert:DI (reg:DI 125 [ c ])
(subreg:QI (and:SI (reg:SI 128)
(const_int 65535 [0x])) 0)))
This was created by the *aarch64_reg_3_neg_mas
Again. This change adjusts more tests to work with int16. For tests
that cannot be easily adjusted, added int32plus or size32plus filters.
Committed as 257333.
Johann
gcc/testsuite/
PR testsuite/52641
* gcc.c-torture/execute/pr83362.c: Make work for int16.
* gcc.dg/Wsi
Hi Luis,
On 02/02/18 14:38, Luis Machado wrote:
A customer reported the following missed opportunities to combine a couple
instructions into a sbfiz.
int sbfiz32 (int x)
{
return x << 29 >> 10;
}
long sbfiz64 (long x)
{
return x << 58 >> 20;
}
This gets converted to the following pattern
A customer reported the following missed opportunities to combine a couple
instructions into a sbfiz.
int sbfiz32 (int x)
{
return x << 29 >> 10;
}
long sbfiz64 (long x)
{
return x << 58 >> 20;
}
This gets converted to the following pattern:
(set (reg:SI 98)
(ashift:SI (sign_extend:SI (
On Fri, Feb 2, 2018 at 6:14 AM, Rainer Orth
wrote:
>
>> This patch to the Go frontend changes value methods to always check
>> that the pointer they are passed is not nil. We already dereference
>> the pointer to copy the value, but if the method does not use the
>> value then the pointer derefe
Richard Sandiford writes:
> Segher Boessenkool writes:
>> Hi!
>>
>> On Fri, Jan 26, 2018 at 01:25:51PM +, Richard Sandiford wrote:
>>> if (SCALAR_INT_MODE_P (inmode))
>>> new_out_reg = gen_lowpart_SUBREG (outmode, reg);
>>> else
>>> - new_out_reg = gen_rtx_SUBREG (ou
Hi Ian,
> This patch to the Go frontend changes value methods to always check
> that the pointer they are passed is not nil. We already dereference
> the pointer to copy the value, but if the method does not use the
> value then the pointer dereference may be optimized away. Do an
> explicit nil
This patch is part 2 of the fix for PR 81635. It means that
split_constant_offset can handle loops like:
for (unsigned int i = 0; i < n; i += 4)
{
a[i] = ...;
a[i + 1] = ...;
}
CCP records that "i" must have its low 2 bits clear, but we don't
include this information in the
On 02/02/18 12:21, Eric Botcazou wrote:
>> That's always been my interpretation too. Seems like we may be changing
>> the meaning of this macro...
>
> The main (and essentially only) effect of WORD_REGISTER_OPERATIONS in the
> compiler happens during combine and is explained by this comment take
The Go language spec says that in a range loop with a single iteration
variable, the range value is not evaluated if its length is a
constant. This only matters when the range value is an array type and
evaluating it causes some side effect. gccgo never got this right;
this patch fixes it. This
On 19 June 2016 at 22:21, Mike Stump wrote:
> On Jun 18, 2016, at 12:31 PM, Bernhard Reutner-Fischer
> wrote:
>>
>> A branch with a name matching scan-assembler pattern triggers
>> inappropriate FAIL.
>
>> The patch below adds -fno-ident if a testcase contains one of
>> scan-assembler, scan-asse
This patch reduces avr testsuite fallout for some cases that cannot be
easily adjusted or where int32plus et al. is not the right filter.
Moreover, target-supports.exp reads:
# Return 1 if according to target_info struct and explicit target list
# target disables -fdelete-null-pointer-checks.
Hi Uros,
This is an easy one to OK :-) Backport it as far back as your patience allows.
Thanks
Paul
On 2 February 2018 at 10:32, Uros Bizjak wrote:
> Hello!
>
> Attached patch removes two statements with no effect. These two
> statements operate with uninitalized variables, and - depending on
> That's always been my interpretation too. Seems like we may be changing
> the meaning of this macro...
The main (and essentially only) effect of WORD_REGISTER_OPERATIONS in the
compiler happens during combine and is explained by this comment taken from
eliminate_regs_1 and written by Jim in 1
Hello!
Attached patch removes two statements with no effect. These two
statements operate with uninitalized variables, and - depending on the
uninitialized value - can cause denormal FP exceptions when compiled
with -O0. The exception causes runtime failure on the target that
requires -mieee for f
Hi,
Thanks for your quick reply.
>> I think you should use altivec_lvx_v4si_2op_si instead?
I will look into this. I had used v4si_internal as this was generated in older
versions (> And the same needs to be done for v8hi, v16qi, v4sf, maybe more?
I did observe some other testcase failures for 32-
> By QImode addition, do you mean:
>
>(set (subreg:QI (reg:SI X1) N)
> (plus:QI (subreg:QI (reg:SI X2) N)
>(subreg:QI (reg:SI X3) N)))
>
> ?
Yes.
> I thought the point was instead that the target expected such ops
> to be done on word_mode, even if the values involved
Again. This change adjusts more tests to work with int16. For tests
that cannot be easily adjusted, added int32plus or size32plus filters.
https://gcc.gnu.org/r257327
Johann
gcc/testsuite/
PR testsuite/52641
* gcc.c-torture/execute/pr81913.c: Use types that also work for int1
> > Ah, right. The patch oversimplifies this. We need to do sth like
> > TREE_CODE (t1) == ARRAY_TYPE && ! TYPE_NONALIASED_COMPONENT (t1) && ...
> > right?
>
> Right. Any objection to me applying this?
Not form my side - lto-symtab change makes sense to me.
With LTO all array types have canoni
> Ah, right. The patch oversimplifies this. We need to do sth like
> TREE_CODE (t1) == ARRAY_TYPE && ! TYPE_NONALIASED_COMPONENT (t1) && ...
> right?
Right. Any objection to me applying this?
lto/
PR lto/83954
* lto-symtab.c (warn_type_compatibility_p): Do not recurse into the
On Fri, Feb 2, 2018 at 10:22 AM, Tsimbalist, Igor V
wrote:
>> -Original Message-
>> From: H.J. Lu [mailto:hjl.to...@gmail.com]
>> Sent: Tuesday, January 30, 2018 3:45 PM
>> To: Uros Bizjak
>> Cc: Tsimbalist, Igor V ; gcc-
>> patc...@gcc.gnu.org
>> Subject: Re: [PATCH][PR target/84066] Wro
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, January 30, 2018 3:45 PM
> To: Uros Bizjak
> Cc: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH][PR target/84066] Wrong shadow stack register size is
> saved for x32
>
> On Tue, Jan 3
57 matches
Mail list logo
