Hi:
The umips-stroe16-2.c test fails after r255348, cause the r255348 does not print
"[length = NN]" but "[c=NN l=NN]".
The asm for umips-stroe16-2.c.
before r255348:
...
sb $0,0($4) # 9*movqi_internal/6 [length = 2]
...
after r255348:
...
sb $0,0($4
Hi:
The fix-r4000-n.c test fails after r255348, cause the r255348 does not print
"[length = NN]" but "[c=NN l=NN]".
The asm for fix-r4000-1.c.
before r255348:
...
mult$4,$5# 10 mulsi3_r4000[length = 8]
mflo$2
...
after r255348:
...
mult$4,$5#
On Mar 23, 2018, at 11:52 AM, Jason Merrill wrote:
>
> asan doesn't work under ulimit -v, which I want to use on shared hosts
> to avoid causing trouble with runaway processes. There doesn't seem
> to be a way within expect to access getrlimit/setrlimit, so in this
> patch I call out to the shel
The switch has been broken for a long time so its removal is long overdue.
Tested on x86-64/Linux, applied on the mainline.
2018-03-23 Eric Botcazou
PR ada/85007
* gnatlink.adb (Gnatlink): Remove handling of -b switch.
* doc/gnat_ugn/building_executable_programs_with_
On 03/23/2018 09:44 AM, Renlin Li wrote:
> Hi all,
>
> This is a simple patch to correct the comment for ADDR_EXPR tree code.
>
> The resulting expression of ADDR_EXPR is a tree with POINTER_TYPE.
> So the result mode should ptr_mode instead of Pmode.
>
> As far as I understand, Pmode is the add
This is a fallout of my fix for PR ada/83016, which allowed the --LINK option
of gnatlink to contain switches in addition to the linker itself. There is a
conflict with the switches passed with the --GCC option so this patch arranges
for the former switches to take precedence over the latter sw
Bill pointed out the following test case has been failing since January.
It ends up it needs the same fixup that the builtins-1-be.c test case got.
Segher approved this offline. Committed.
Peter
* gcc.target/powerpc/builtins-1-le.c: Filter out gimple folding disabled
message. Fi
On Tue, Feb 27, 2018 at 12:26 PM, Jason Merrill wrote:
> The logic in type_unification_real for handling template parms that
> depend on earlier template parms is a bit complicated. It already
> recognizes when the type of the parm depends on something not
> available yet, and it dealt with the c
On Fri, Mar 23, 2018 at 4:55 PM, Jason Merrill wrote:
> On Fri, Mar 23, 2018 at 12:44 PM, Jason Merrill wrote:
>> Seems like cp_fold should update CALL_EXPR_FN with "callee" if non-null.
>
> Did you try this? That should avoid it being ADDR_EXPR of a decl.
Oh, I was assuming the ICE was in the
On Fri, Mar 23, 2018 at 12:44 PM, Jason Merrill wrote:
> Seems like cp_fold should update CALL_EXPR_FN with "callee" if non-null.
Did you try this? That should avoid it being ADDR_EXPR of a decl.
Jason
On Mar 23, 2018, Jason Merrill wrote:
> On Thu, Mar 22, 2018 at 7:00 PM, Alexandre Oliva wrote:
>> fn[0]() ICEs because we end up with addr_expr of a decl, and that
>> should only happen for artificial or otherwise special internal
>> functions. For anything else, we should find the decl earlie
On Fri, Mar 23, 2018 at 3:42 PM, Jakub Jelinek wrote:
> The following patch adds C++2a stuff to cxx-status.html (list of papers from
> clang table, filled in what has notes in cp/ChangeLog-2017 + __VA_OPT__).
> For C++17 features I've just added a couple of / markings and
> added the second deduct
On Fri, Mar 23, 2018 at 3:38 PM, Alexandre Oliva wrote:
> + /* Concepts allows 'auto' in template arguments, even multiple
> + 'auto's in a single argument.
I think that's only intended for class templates; we should reject
'auto' as a template argument for function or variable templates.
J
We fail to detect unresolved explicitly-passed auto template args.
The first hunk in pt.c, that changes fn_type_unification, arranges for
us to regard the template arg list as incomplete, although that's not
necessary for any of the testcases I tried. I thought it might be
relevant in case the ar
On Fri, Mar 23, 2018 at 12:32:20PM -0400, Jason Merrill wrote:
> > 2018-03-23 Jakub Jelinek
> >
> > PR c++/85015
> > * decl.c (compute_array_index_type): Return error_mark_node if
> > mark_rvalue_use or maybe_constant_value returns error_operand_p.
> > Set osize t
OK.
On Fri, Mar 23, 2018 at 3:17 PM, Alexandre Oliva wrote:
> On Mar 23, 2018, Jakub Jelinek wrote:
>
>> On Wed, Mar 21, 2018 at 11:52:33PM -0400, Jason Merrill wrote:
>>> OK, thanks.
>
>> Note the testcase FAILs with -fconcepts when I do make check-c++-all,
>> FAIL: g++.dg/template/pr84789.C -
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85030
The patch was successfully bootstrapped on x86 and x86-64 and tested
on x86-64.
Committed as rev. 258820.
Index: ChangeLog
===
--- ChangeLog (r
On Thu, Mar 22, 2018 at 05:52:56PM -0500, Segher Boessenkool wrote:
> On Wed, Mar 21, 2018 at 11:42:01AM -0400, Michael Meissner wrote:
> > +/* Create a decl for either complex long double multiply or complex long
> > double
> > + divide when long double is IEEE 128-bit floating point. We can't
On Mar 23, 2018, Jakub Jelinek wrote:
> On Wed, Mar 21, 2018 at 11:52:33PM -0400, Jason Merrill wrote:
>> OK, thanks.
> Note the testcase FAILs with -fconcepts when I do make check-c++-all,
> FAIL: g++.dg/template/pr84789.C -std=c++17 -fconcepts (test for errors,
> line 12)
> FAIL: g++.dg/tem
asan doesn't work under ulimit -v, which I want to use on shared hosts
to avoid causing trouble with runaway processes. There doesn't seem
to be a way within expect to access getrlimit/setrlimit, so in this
patch I call out to the shell to test the current limit, and give up
if I get back a number
On 3/22/18 6:03 PM, Segher Boessenkool wrote:
> On Wed, Mar 21, 2018 at 09:10:38PM -0500, Peter Bergner wrote:
>> If you're asking about whether we also need to backport to GCC 6, I
>> believe Kaushik said in the bugzilla that he only encountered the
>> ICE on GCC 7 and trunk, so I don't think we n
OK.
On Fri, Mar 23, 2018 at 1:26 PM, Jakub Jelinek wrote:
> On Fri, Mar 23, 2018 at 12:32:20PM -0400, Jason Merrill wrote:
>> > 2018-03-23 Jakub Jelinek
>> >
>> > PR c++/85015
>> > * decl.c (compute_array_index_type): Return error_mark_node if
>> > mark_rvalue_use or ma
This is the second patch to fix PR84912, which is an ICE when calling some
extended divide builtin functions. This patch is relative to the first
patch. This fixes the ICE by adding a new mask to the builtin functions
that are ICEing and then enforcing it is set. I have also added a helpful
erro
This is the first patch to fix PR84912, which is an ICE when calling some
extended divide builtin functions. In discussing this offline, we decided
that all div*o builtin functions make no sense because we don't model the
OV bit in GCC. This patch simply removes all div*o builtins and their
assoc
On Fri, Mar 23, 2018 at 01:45:01PM -0300, Alexandre Oliva wrote:
> On Mar 23, 2018, Jakub Jelinek wrote:
>
> > On Wed, Mar 21, 2018 at 11:52:33PM -0400, Jason Merrill wrote:
> >> OK, thanks.
>
> > Note the testcase FAILs with -fconcepts when I do make check-c++-all,
>
> Hmm, I don't get that wi
On Mar 23, 2018, Jakub Jelinek wrote:
> On Wed, Mar 21, 2018 at 11:52:33PM -0400, Jason Merrill wrote:
>> OK, thanks.
> Note the testcase FAILs with -fconcepts when I do make check-c++-all,
Hmm, I don't get that with check or check-g++. Should we expand the
default std_list in g++-dg.exp, or s
On Fri, Mar 23, 2018 at 12:17 PM, Alexandre Oliva wrote:
> On Mar 23, 2018, Jason Merrill wrote:
>
>> On Thu, Mar 22, 2018 at 7:00 PM, Alexandre Oliva wrote:
>>> fn[0]() ICEs because we end up with addr_expr of a decl, and that
>>> should only happen for artificial or otherwise special internal
Hi all,
This bug has been reported against GCC 7.3.0 but it is latent in all release
branches and on trunk.
We underestimate the length of the LRSH instruction in Thumb state.
Unlike other load instructions LDRSH can be encoded in 16 bits only when using
a register offset.
In the testcase we ha
OK.
On Fri, Mar 23, 2018 at 10:18 AM, Jakub Jelinek wrote:
> On Thu, Mar 22, 2018 at 02:02:01PM -0400, Jason Merrill wrote:
>> He hadn't yet checked in the relevant change, "Disable
>> auto_is_implicit_function_template_parm_p while parsing attributes".
>> That should happen soon.
>>
>> > but wit
On Fri, Mar 23, 2018 at 10:17 AM, Jakub Jelinek wrote:
> On Fri, Mar 23, 2018 at 09:31:53AM -0400, Jason Merrill wrote:
>> On Thu, Mar 22, 2018 at 5:27 PM, Jakub Jelinek wrote:
>> > We ICE during error-recovery on the following testcase,
>> > compute_array_index_type
>> > checks size for error_o
OK.
On Fri, Mar 23, 2018 at 11:28 AM, Alexandre Oliva wrote:
> When an anon struct gets a name through a typedef, we reset its
> linkage and that of its members. Member functions may get vague
> linkage, which schedules them for deferred output, but we don't want
> to add them to the queue if th
OK.
On Fri, Mar 23, 2018 at 11:27 AM, Alexandre Oliva wrote:
> We reject extended statement-expressions in template parameters, so we
> might as well reject them in constant expressions used in noexcept
> specifications.
>
> Regstrapped on i686- and x86_64-linux-gnu. Ok to install?
>
> for gcc/
On 03/02/2018 05:55 PM, Cesar Philippidis wrote:
+ if (cfun->machine->sync_bar)
+fprintf (file, "\t\tadd.u32\t\t%%r%d, %%tidy, 1; "
+"// vector synchronization barrier\n",
+REGNO (cfun->machine->sync_bar));
I realize that atm we don't support large vector length whe
Hans-Peter Nilsson writes:
> All patches are together run through the gcc and g++ test-suites
> to check ASAN results for mipsisa32r2el-linux-gnu. As of
> r258635 those results are on par with those for
> arm-linux-gnueabihf, so without delay I present the current
> state. Maybe it's non-intrusi
On Mar 23, 2018, Jason Merrill wrote:
> On Thu, Mar 22, 2018 at 7:00 PM, Alexandre Oliva wrote:
>> fn[0]() ICEs because we end up with addr_expr of a decl, and that
>> should only happen for artificial or otherwise special internal
>> functions. For anything else, we should find the decl earlie
Hi all,
This is a simple patch to correct the comment for ADDR_EXPR tree code.
The resulting expression of ADDR_EXPR is a tree with POINTER_TYPE.
So the result mode should ptr_mode instead of Pmode.
As far as I understand, Pmode is the addressing mode. But not the mode to
represent a pointer (
We reject extended statement-expressions in template parameters, so we
might as well reject them in constant expressions used in noexcept
specifications.
Regstrapped on i686- and x86_64-linux-gnu. Ok to install?
for gcc/cp/ChangeLog
PR c++/84968
* tree.c (strip_typedefs_expr):
When an anon struct gets a name through a typedef, we reset its
linkage and that of its members. Member functions may get vague
linkage, which schedules them for deferred output, but we don't want
to add them to the queue if they're uninstantiated templates,
e.g. because the enclosing function is
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators. The file is available at:
http://translationproject.org/latest/gcc/es.po
(This file, 'gcc-8.1-b20180128.es.po',
This is the last of the infrastructure patches that I have currently done.
This adds a new reg_addr flag to note whether the d-form address is a ds-form
(bottom 2 bits must be 0). At present, nothing uses this, but I have plans for
it in the future.
2018-03-22 Michael Meissner
* confi
On Wed, Mar 21, 2018 at 11:52:33PM -0400, Jason Merrill wrote:
> OK, thanks.
Note the testcase FAILs with -fconcepts when I do make check-c++-all,
FAIL: g++.dg/template/pr84789.C -std=c++17 -fconcepts (test for errors, line
12)
FAIL: g++.dg/template/pr84789.C -std=c++17 -fconcepts (test for ex
On Fri, Mar 23, 2018 at 02:16:32PM +0100, Marek Polacek wrote:
> > So, I think you want:
> > 1) in cxx_pretty_printer::multiplicative_expression add
> > EXACT_DIV_EXPR and (like you did) RDIV_EXPR, and change the pp_slash
> > condition to code != TRUNC_MOD_EXPR
> > 2) in cxx_pretty_printer::express
On 03/22/2018 06:24 PM, Cesar Philippidis wrote:
On 03/22/2018 09:18 AM, Tom de Vries wrote:
That's obviously not good enough.
When I compile this test-case:
...
int
main (void)
{
int a[10];
#pragma acc parallel num_workers (16)
#pragma acc loop worker
for (int i = 0; i < 10; i++)
a
On Thu, Mar 22, 2018 at 02:02:01PM -0400, Jason Merrill wrote:
> He hadn't yet checked in the relevant change, "Disable
> auto_is_implicit_function_template_parm_p while parsing attributes".
> That should happen soon.
>
> > but with
> > the following patch we don't ICE, because args is NULL and
>
On 03/02/2018 05:55 PM, Cesar Philippidis wrote:
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 28ae263c867..ac2731233dd 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -1418,10 +1418,16 @@
[(set_attr "atomic" "true")])
(define_insn "nv
On Fri, Mar 23, 2018 at 09:31:53AM -0400, Jason Merrill wrote:
> On Thu, Mar 22, 2018 at 5:27 PM, Jakub Jelinek wrote:
> > We ICE during error-recovery on the following testcase,
> > compute_array_index_type
> > checks size for error_operand_p early (and it is not error operand; it is
> > > where
On 23/03/18 13:50, Kyrill Tkachov wrote:
On 23/03/18 13:31, Sudakshina Das wrote:
On 23/03/18 09:12, Kyrill Tkachov wrote:
On 23/03/18 08:47, Christophe Lyon wrote:
Hi Sudi,
On 22 March 2018 at 18:26, Sudakshina Das wrote:
Hi
On 22/03/18 16:52, Kyrill Tkachov wrote:
On 22/03/18 16:20
On 23/03/18 13:31, Sudakshina Das wrote:
On 23/03/18 09:12, Kyrill Tkachov wrote:
On 23/03/18 08:47, Christophe Lyon wrote:
Hi Sudi,
On 22 March 2018 at 18:26, Sudakshina Das wrote:
Hi
On 22/03/18 16:52, Kyrill Tkachov wrote:
On 22/03/18 16:20, Sudakshina Das wrote:
Hi Kyrill
On 22/
Hi!
This testcase has been already fixed on the trunk with r257620
aka PR84305 fix. I've tested and committed as obvious following testcase so
that PR80778 can be closed.
2018-03-23 Jakub Jelinek
PR c/80778
* gcc.dg/lto/pr80778_0.c: New test.
--- gcc/testsuite/gcc.dg/lto/pr8
On Thu, Mar 22, 2018 at 5:27 PM, Jakub Jelinek wrote:
> We ICE during error-recovery on the following testcase,
> compute_array_index_type
> checks size for error_operand_p early (and it is not error operand; it is
> > where c is of reference type with
> error_mark_node DECL_INITIAL), then calls
On 23/03/18 09:12, Kyrill Tkachov wrote:
On 23/03/18 08:47, Christophe Lyon wrote:
Hi Sudi,
On 22 March 2018 at 18:26, Sudakshina Das wrote:
Hi
On 22/03/18 16:52, Kyrill Tkachov wrote:
On 22/03/18 16:20, Sudakshina Das wrote:
Hi Kyrill
On 22/03/18 16:08, Kyrill Tkachov wrote:
Hi Sudi
On Fri, Mar 23, 2018 at 11:59:04AM +0100, Jakub Jelinek wrote:
> On Fri, Mar 23, 2018 at 11:49:00AM +0100, Marek Polacek wrote:
> > cxx_pretty_printer::multiplicative_expression didn't handle RDIV_EXPR, so
> > when
> > we tried to print a RDIV_EXPR, we printed it as a pm-expression. That led
> >
On 03/02/2018 05:55 PM, Cesar Philippidis wrote:
+/* Loop structure of the function. The entire function is described as
+ a NULL loop. */
+
struct parallel
{
/* Parent parallel. */
You dropped this comment in "vector_length extension part 1: generalize
function and variable names
On 03/02/2018 05:55 PM, Cesar Philippidis wrote:
@@ -4115,13 +4225,23 @@ nvptx_single (unsigned mask, basic_block from,
basic_block to)
pred = gen_reg_rtx (BImode);
cfun->machine->axis_predicate[mode - GOMP_DIM_WORKER] = pred;
}
-
+
It's fine to clean u
On Thu, Mar 22, 2018 at 7:00 PM, Alexandre Oliva wrote:
> fn[0]() ICEs because we end up with addr_expr of a decl, and that
> should only happen for artificial or otherwise special internal
> functions. For anything else, we should find the decl earlier, but we
> don't because we build an indirec
On Fri, Mar 23, 2018 at 6:13 AM, Paolo Carlini wrote:
> On 22/03/2018 23:26, Jason Merrill wrote:
>>
>> On Thu, Mar 22, 2018 at 5:39 PM, Paolo Carlini
>> wrote:
>>>
>>> ... with patch ;)
>>>
>>> If you are curious where the heck that INDIRECT_REF is coming from, is
>>> coming from the gimplifier,
OK.
On Fri, Mar 23, 2018 at 6:48 AM, Marek Polacek wrote:
> In this test:
>
> struct S {
> enum { X };
> };
>
> int
> foo (struct S s)
> {
> return s.X;
> }
>
> unlike in C, lookup_member in C++ is able to find X in S. So in the following
> testcase finish_offsetof happily passes the CONST
On Thu, Mar 22, 2018 at 6:58 PM, Jim Wilson wrote:
> On Wed, Mar 21, 2018 at 2:45 AM, Richard Biener
> wrote:
>> On Tue, Mar 20, 2018 at 11:10 PM, Jim Wilson wrote:
>>> This fixes a wrong-code issue on RISC-V, but in theory could be a problem
>>> for
>>> any SHIFT_COUNT_TRUNCATED target.
>
>> I
On Fri, Mar 23, 2018 at 11:49:00AM +0100, Marek Polacek wrote:
> cxx_pretty_printer::multiplicative_expression didn't handle RDIV_EXPR, so when
> we tried to print a RDIV_EXPR, we printed it as a pm-expression. That led to
> printing it as a cast-expression. That led to printing it as a
> primary
On Fri, Mar 23, 2018 at 10:58:15AM +0100, Richard Biener wrote:
> On Thu, 22 Mar 2018, Jakub Jelinek wrote:
>
> > On Thu, Mar 22, 2018 at 03:16:22PM +0100, Richard Biener wrote:
> > > the upper bound decl is global as well). Jakub, do you remember
> > > a reason for having any constraints here?
On Fri, 23 Mar 2018, Eric Botcazou wrote:
> > This should then trigger the use of DW_OP_GNU_variable_value but
> > for the Ada ACATS testcase I was looking at to debug the issue
> > (c330001, resp. c330001_0-c330001_1.ads) this doesn't work
> > because the constraints are not met (we're in global
cxx_pretty_printer::multiplicative_expression didn't handle RDIV_EXPR, so when
we tried to print a RDIV_EXPR, we printed it as a pm-expression. That led to
printing it as a cast-expression. That led to printing it as a
primary-expression. That led to printing it as a multiplicative expression.
T
In this test:
struct S {
enum { X };
};
int
foo (struct S s)
{
return s.X;
}
unlike in C, lookup_member in C++ is able to find X in S. So in the following
testcase finish_offsetof happily passes the CONST_DECL X down to fold_offsetof,
which then crashes because fold_offsetof_1 doesn't han
Hi,
On 22/03/2018 23:26, Jason Merrill wrote:
On Thu, Mar 22, 2018 at 5:39 PM, Paolo Carlini wrote:
... with patch ;)
If you are curious where the heck that INDIRECT_REF is coming from, is
coming from the gimplifier, cp_gimpliify_expr, via build_vec_init. Grrr.
Hmm, maybe build_vec_init shou
On Thu, 22 Mar 2018, Jakub Jelinek wrote:
> On Thu, Mar 22, 2018 at 03:16:22PM +0100, Richard Biener wrote:
> > the upper bound decl is global as well). Jakub, do you remember
> > a reason for having any constraints here? I've reworked the
>
> I don't, but it has been added in the
> https://gcc
On Fri, Mar 23, 2018 at 09:53:53AM +0100, Richard Biener wrote:
> > Something I wasn't really aware, apparently we allow extern vars with
> > incomplete types in "m" and "=m" constrained asm. The problem is that
> > incomplete vars have VOIDmode mode and so their MEMs do as well, apparently
> > ev
On 23/03/18 08:47, Christophe Lyon wrote:
Hi Sudi,
On 22 March 2018 at 18:26, Sudakshina Das wrote:
Hi
On 22/03/18 16:52, Kyrill Tkachov wrote:
On 22/03/18 16:20, Sudakshina Das wrote:
Hi Kyrill
On 22/03/18 16:08, Kyrill Tkachov wrote:
Hi Sudi,
On 21/03/18 17:44, Sudakshina Das wrote
On Fri, 23 Mar 2018, Jakub Jelinek wrote:
> On Fri, Mar 23, 2018 at 09:53:53AM +0100, Richard Biener wrote:
> > > Something I wasn't really aware, apparently we allow extern vars with
> > > incomplete types in "m" and "=m" constrained asm. The problem is that
> > > incomplete vars have VOIDmode m
On Thu, 22 Mar 2018, Jakub Jelinek wrote:
> Hi!
>
> match_asm_constraints_1 verifies that the mode of input and output
> is the same, with one exception - when input is VOIDmode.
> It isn't correct to allow that blindly VOIDmode CONST_INT/CONST_DOUBLE
> is only ok if the output mode is scalar int
On 03/22/2018 08:04 PM, Cesar Philippidis wrote:
I'm going to retest the variable vector length changes without it and
see if it's still necessary. On one hand, maxntid should be fairly
innocuous, but I don't like how it can mask other PTX JIT bugs. At this
point, I'm leaning towards dropping it
On Thu, 22 Mar 2018, Jakub Jelinek wrote:
> Hi!
>
> Something I wasn't really aware, apparently we allow extern vars with
> incomplete types in "m" and "=m" constrained asm. The problem is that
> incomplete vars have VOIDmode mode and so their MEMs do as well, apparently
> everything works with
On Thu, 22 Mar 2018, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, we can hit the assertion here (with code that is
> rejected only later on during expansion). Instead of the assertion, this
> patch just doesn't try to optimize those, maybe_optimize_ubsan_ptr_ifn
> is a pure optimization
Hi Sudi,
On 22 March 2018 at 18:26, Sudakshina Das wrote:
> Hi
>
>
> On 22/03/18 16:52, Kyrill Tkachov wrote:
>>
>>
>> On 22/03/18 16:20, Sudakshina Das wrote:
>>>
>>> Hi Kyrill
>>>
>>> On 22/03/18 16:08, Kyrill Tkachov wrote:
Hi Sudi,
On 21/03/18 17:44, Sudakshina Das wrote:
73 matches
Mail list logo
