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 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
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 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!
>
> 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 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 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, 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 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
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
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
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
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
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, 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 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
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 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,
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 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 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 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 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 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
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 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/
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 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 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 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/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 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 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
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
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',
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
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):
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 (
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
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 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
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/
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
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 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
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
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
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 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
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
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
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
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
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 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
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
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 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 -
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 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
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 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 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 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 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
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
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
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
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 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
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#
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
73 matches
Mail list logo
