I merged trunk revision 234923 to the gccgo branch.
Ian
The gccgo version of the reflect package was incorrectly marking the
results of Value.Call as addressable. This generally didn't matter,
but it turns out to break a use of the text/template package. This
patch fixes the problem. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committe
On 04/12/2016 04:58 PM, Nathan Sidwell wrote:
Well, I had a patch all ready, but when writing it up, I discovered the
logic behind comment #26 is wrong. Specifically, Jason's proto-patch
makes the fn_copy_table GCable, but keeps the constexpr_call_table
GC-deletable. The logic is that if we ne
This is the embarrassing dangling-else bug in sparc_compute_frame_size spotted
by the -Wparentheses warning. It went unnoticed for 5 years because the block
of code is actually a no-op (with or without the bug), it would do something
only if someone wanted to give a try to a totally new ABI for
Well, I had a patch all ready, but when writing it up, I discovered the logic
behind comment #26 is wrong. Specifically, Jason's proto-patch makes the
fn_copy_table GCable, but keeps the constexpr_call_table GC-deletable. The
logic is that if we need to recreate a particular constexpr call,
On Tue, Apr 12, 2016 at 10:14:17PM +0200, Bernd Schmidt wrote:
> >So, would you be ok with the patch if I change it that way (to be tested
> >tomorrow)?
>
> Yeah, I think so.
So here is what I'll throw at testing:
2016-04-12 Jakub Jelinek
PR debug/70628
* rtl.h (convert_memor
A revision of the patch previously posted at
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00841.html
To recap quickly, the C++ compiler has used a different calling
convention for passing empty classes, because C++ says they have size 1,
while the GCC C extension gives them size 0. But thi
On 04/12/2016 10:06 PM, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 10:02:18PM +0200, Bernd Schmidt wrote:
On 04/12/2016 05:10 PM, Jakub Jelinek wrote:
This patch arranges for a new argument to
convert_memory_address_addr_space_1 and calls it with that new argument set
to true, to make sure it
On Tue, Apr 12, 2016 at 10:02:18PM +0200, Bernd Schmidt wrote:
> On 04/12/2016 05:10 PM, Jakub Jelinek wrote:
> >This patch arranges for a new argument to
> >convert_memory_address_addr_space_1 and calls it with that new argument set
> >to true, to make sure it never emits instructions or creates p
On 04/12/2016 05:10 PM, Jakub Jelinek wrote:
This patch arranges for a new argument to
convert_memory_address_addr_space_1 and calls it with that new argument set
to true, to make sure it never emits instructions or creates pseudos.
I think the approach looks sensible, but I don't know if you n
Hi!
As the testcase shows, gimplification of the VECTOR_TYPE CONSTRUCTOR
elements can turn previously valid initializer_constant_valid_p
into a temporary (thus no longer initializer_constant_valid_p).
The following patch just clears TREE_STATIC on the ctor if that happens,
so that we expand it pr
Hi!
On Thu, Apr 07, 2016 at 08:18:28AM -0700, Nathan Sidwell wrote:
> 2016-04-06 Nathan Sidwell
>
> PR c++/70501
> * constexpr.c (cxx_eval_bare_aggregate): Handle VECTOR_TYPE
> similarly to PMF.
This patch fixed also PR70571, so I've committed the testcase after
bootstrap/re
Hi!
After clarification from Intel folks, I've committed following ABI tweak
- the boundary at which large simdlen values become unsupported is whether
the return type (or characteristic type if the former is void) can be passed
as a vector in the __regcall calling convention (thus, fits into 8 [x
On Tue, Apr 12, 2016 at 3:11 PM, Michael Meissner
wrote:
> After I moved the patches for the 70381 to my internal branch for GCC 7.0
> submissions, I noticed test float128-1.c was failing. I tracked it down to the
> fact that the pre-gcc7 branch defaults to using LRA on by default instead of
> rel
On Tue, Apr 12, 2016 at 8:10 AM, Jakub Jelinek wrote:
> Hi!
>
> Most of simplify-rtx.c attempts hard not to generate any extra instructions,
> just simplify the RTL to something equivalent and let the user try to
> recognize it, or whatever else it wishes.
> This is especially important post-reloa
After I moved the patches for the 70381 to my internal branch for GCC 7.0
submissions, I noticed test float128-1.c was failing. I tracked it down to the
fact that the pre-gcc7 branch defaults to using LRA on by default instead of
reload.
I tracked this down to using a "=" constraint on an input ar
On Tue, Apr 12, 2016 at 08:19:57PM +0200, Richard Biener wrote:
> >So you mean add another hash table that maps DECL_UIDs to these SRA
> >counters? Because if we dump there any number of say FIELD_DECL, it
> >would
> >be desirable to use the same number on any further fancy names with
> >that
> >F
On 04/05/16 17:30, Evandro Menezes wrote:
On 04/05/16 13:37, Wilco Dijkstra wrote:
I can't get any of these to work... Not only do I get a large number
of collisions and duplicated
code between these patches, when I try to resolve them, all I get is
crashes whenever I try
to use sqrt (even rsqr
On April 12, 2016 5:55:16 PM GMT+02:00, Jakub Jelinek wrote:
>On Tue, Apr 12, 2016 at 05:49:26PM +0200, Richard Biener wrote:
>> On April 12, 2016 4:54:27 PM GMT+02:00, Jakub Jelinek
> wrote:
>> >Hi!
>> >
>> >Even without the C++ FE changes, I believe there are occassional
>> >DECL_UID
>> >differe
On 04/10/2016 07:14 PM, Martin Sebor wrote:
The call to build_vla_check() in check_initializer() is to check
only explicitly initialized VLAs. The latter function may need
to complete the VLA element type and reshape the initializer so
the call cannot be made earlier. The function returns the r
On 04/04/16 11:13, Evandro Menezes wrote:
On 04/01/16 18:08, Wilco Dijkstra wrote:
Evandro Menezes wrote:
I hope that this gets in the ballpark of what's been discussed
previously.
Yes that's very close to what I had in mind. A minor issue is that
the vector
modes cannot work as they start at
On 04/04/16 14:06, Evandro Menezes wrote:
On 04/01/16 17:52, Evandro Menezes wrote:
On 04/01/16 17:45, Wilco Dijkstra wrote:
Evandro Menezes wrote:
However, I don't think that there's the need to handle any special
case
for division. The only case when the approximation differs from
divisio
On 04/12/2016 09:43 AM, Jason Merrill wrote:
On 04/10/2016 07:14 PM, Martin Sebor wrote:
+ if (TREE_CODE (type) == ARRAY_TYPE
+ && variably_modified_type_p (type, NULL_TREE)
+ && !processing_template_decl)
+{
+ /* Statically check for overflow in VLA bound
On April 12, 2016 2:12:14 PM GMT+02:00, Jan Hubicka wrote:
>> Hello.
>>
>> As release managers agreed on IRC, following patch reverts r234572
>> which introduced new PR testsuite/70577.
>>
>> I've been running bootstrap & regression tests on x86_64-linux-gnu.
>> Ready to be installed after it fi
On 04/12/2016 11:14 AM, Jakub Jelinek wrote:
Hi!
Removing DEBUG_INSNs (unless it is removed e.g. together with whole bb
as unreachable code) is always wrong, instead it should be reset,
which indicates we don't know where the var lives (removing it instead
means that the previous DEBUG_INSN for
On Tue, Apr 12, 2016 at 05:49:26PM +0200, Richard Biener wrote:
> On April 12, 2016 4:54:27 PM GMT+02:00, Jakub Jelinek
> wrote:
> >Hi!
> >
> >Even without the C++ FE changes, I believe there are occassional
> >DECL_UID
> >differences (I believe the code just cares that the ordering of the
> >uid
On April 12, 2016 4:54:27 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>Even without the C++ FE changes, I believe there are occassional
>DECL_UID
>differences (I believe the code just cares that the ordering of the
>uids
>is stable), and the fancy DEC_IGNORED names can leak into the
>-fdump-final-in
On 04/12/2016 11:19 AM, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 10:53:22AM -0400, Jason Merrill wrote:
It doesn't seem that dangerous to me. The decls are only used within
constexpr evaluation, they never escape.
The uids can be used in hashing, folding, for the various on the side
table
On 04/10/2016 07:14 PM, Martin Sebor wrote:
+ if (TREE_CODE (type) == ARRAY_TYPE
+ && variably_modified_type_p (type, NULL_TREE)
+ && !processing_template_decl)
+ {
+ /* Statically check for overflow in VLA bounds and build
+an
On 04/12/16 11:19, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 10:53:22AM -0400, Jason Merrill wrote:
It doesn't seem that dangerous to me. The decls are only used within
constexpr evaluation, they never escape.
The uids can be used in hashing, folding, for the various on the side
tables (va
On Tue, Apr 12, 2016 at 10:53:22AM -0400, Jason Merrill wrote:
> It doesn't seem that dangerous to me. The decls are only used within
> constexpr evaluation, they never escape.
The uids can be used in hashing, folding, for the various on the side
tables (value-expr, debug-expr, ...).
> >Or perha
Hi!
Removing DEBUG_INSNs (unless it is removed e.g. together with whole bb
as unreachable code) is always wrong, instead it should be reset,
which indicates we don't know where the var lives (removing it instead
means that the previous DEBUG_INSN for the corresponding var is live
even in the insns
On 04/07/2016 11:18 AM, Nathan Sidwell wrote:
On 04/06/16 07:49, Jason Merrill wrote:
Sure, but that also seems unnecessary; vector rvalues don't have
object identity
the way class and array rvalues do.
I attach 2 patches.
70501-2.patch fixes the ICE by treating VECTOR_TYPEs thesame as PMFs
Hi!
Most of simplify-rtx.c attempts hard not to generate any extra instructions,
just simplify the RTL to something equivalent and let the user try to
recognize it, or whatever else it wishes.
This is especially important post-reload, when we can't create new pseudos,
or e.g. when processing (simp
Hi!
Even without the C++ FE changes, I believe there are occassional DECL_UID
differences (I believe the code just cares that the ordering of the uids
is stable), and the fancy DEC_IGNORED names can leak into the
-fdump-final-insns= dumps (e.g. in MEM_EXPRs or REG_EXPRs.
The following patch treat
On 04/12/2016 10:32 AM, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 10:28:39AM -0400, Jason Merrill wrote:
1) I think this approach is not globally best. We're inventing another
memory-usage related heuristic, rather than relying on the already
available GC machinery. That's why I've gone wit
On Tue, Apr 12, 2016 at 10:28:39AM -0400, Jason Merrill wrote:
> >>>1) I think this approach is not globally best. We're inventing another
> >>>memory-usage related heuristic, rather than relying on the already
> >>>available GC machinery. That's why I've gone with a hard coded value
> >>>for now
On 04/12/2016 09:55 AM, Nathan Sidwell wrote:
Most of the conversation appears to be happening in bugzilla ...
On 04/12/16 09:18, Jason Merrill wrote:
I still think that -fcompare-debug being sensitive to exact DECL_UID
is the real bug here.
Plausible, IIUC Jakub's suggested patches for that?
On Tue, Apr 12, 2016 at 09:55:47AM -0400, Nathan Sidwell wrote:
> Most of the conversation appears to be happening in bugzilla ...
>
> On 04/12/16 09:18, Jason Merrill wrote:
>
> >I still think that -fcompare-debug being sensitive to exact DECL_UID is the
> >real
> >bug here.
>
> Plausible, IIU
On 04/12/2016 09:25 AM, Paolo Carlini wrote:
in this regression we have an infinite recursion affecting the
same_type_p call at parser.c:25125 which I added in the patch for
c++/38313. The issue is that for, eg, the testcase at issue, we are
passing a TYPENAME_TYPE to same_type_p. I think we can
Most of the conversation appears to be happening in bugzilla ...
On 04/12/16 09:18, Jason Merrill wrote:
I still think that -fcompare-debug being sensitive to exact DECL_UID is the real
bug here.
Plausible, IIUC Jakub's suggested patches for that?
If we go that way, I think most of the below
Hi,
I have added myself to the "Write After Approval" maintainers list.
Committed revision r234902.
Cheers,
Andre
ChangeLog:
2016-04-12 Andre Vieira
* MAINTAINERS (Write After Approval): Add myself.
Index: ChangeLog
=
Let's go with the first patch.
Jason
And this is the last one; happy to be through these :-)
Jason, anything else you see (or don't, but want to) on the C++
side?
Applied.
Gerald
Use global CSS instead of defining local styles. Simplify things
by omitting all align= attributes, leaving that to CSS.
Index: gcc-4.3/cxx0x_status.h
Hi,
in this regression we have an infinite recursion affecting the
same_type_p call at parser.c:25125 which I added in the patch for
c++/38313. The issue is that for, eg, the testcase at issue, we are
passing a TYPENAME_TYPE to same_type_p. I think we can simply handle the
problem by checking
OK.
Jason
On 04/12/2016 07:20 AM, Alan Modra wrote:
On Tue, Apr 12, 2016 at 06:53:55AM -0400, Patrick Palka wrote:
I would appreciate it if someone could backport it for me since I
won't have time today.
I'm happy to handle backporting and commit for you after approval.
OK.
Jason
On 04/12/2016 09:06 AM, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 09:01:58AM -0400, Andrew MacLeod wrote:
I poked around for a while and found a patch from late 2012 where I was
attempting to implement atomics as a gimple primitive (GIMPLE_ATOMIC). That
work did indeed add the ability of the
On 04/11/2016 03:42 PM, Nathan Sidwell wrote:
This proto patch addresses 70594, where the constexpr machinery causes
differences in -fcompare-debug checking. I'm looking for initial
comments about the approach this patch is taking.
As described in the comments of
https://gcc.gnu.org/bugzilla/sh
Hi!
On Mon, 28 Sep 2015 15:38:57 -0400, Nathan Sidwell wrote:
> --- libgomp/libgomp_g.h (revision 228086)
> +++ libgomp/libgomp_g.h (working copy)
> @@ -222,9 +222,8 @@ extern void GOACC_data_start (int, size_
> extern void GOACC_data_end (void);
> extern void GOACC_enter_exit_data
On Tue, Apr 12, 2016 at 09:01:58AM -0400, Andrew MacLeod wrote:
> I poked around for a while and found a patch from late 2012 where I was
> attempting to implement atomics as a gimple primitive (GIMPLE_ATOMIC). That
> work did indeed add the ability of the CAS primitive to return 2 values to
> op_
On 04/12/2016 12:49 AM, David Wohlferd wrote:
First draft is attached. It tests all 28 (14 conditions plus 14
inverted). I wasn't sure what to set for optimization (O2? O3? O0?),
so I left the default.
I've had it in a successful test run, and committed it with a minor
tweak (__builtin_abort
On 04/12/2016 04:35 AM, Richard Biener wrote:
On Mon, 11 Apr 2016, Jeff Law wrote:
On 04/08/2016 10:10 AM, Jakub Jelinek wrote:
On Fri, Apr 08, 2016 at 06:04:38PM +0200, Richard Biener wrote:
Hmm, don't we simply want to do this for all stmts (OK, only asm have
multiple defs...)?
For all stm
On 08/04/16 16:36 -0400, Ed Smith-Rowland wrote:
I wanted to ship the TR29124 special math functions in libstdc++ with
some documentation.
More could be done but this covers the function definitions, argument
ranges, template parms, and arguments.
There is a little mainpage with some overview,
> Hello.
>
> As release managers agreed on IRC, following patch reverts r234572
> which introduced new PR testsuite/70577.
>
> I've been running bootstrap & regression tests on x86_64-linux-gnu.
> Ready to be installed after it finishes?
OK, thanks for the revert.
I looked into the prefetch tes
On Tue, Apr 12, 2016 at 01:50:19PM +0200, Bernd Schmidt wrote:
> PR preprocessor/69650
> * directives.c (do_linemarker): Reread map after calling
> cpp_get_token.
Ok, thanks.
> --- libcpp/directives.c (revision 234831)
> +++ libcpp/directives.c (working copy)
> @@ -1
With some changes I was working on, I produced a situation where one of
the x86 peepholes made an incorrect transformation. In the prologue
expansion code, we have
/* When using red zone we may start register saving before allocating
the stack frame saving one cycle of the prologue. However
As shown by Roger Orr in the comments of this PR, cpp_get_token can
cause a reallocation that invalidates some of the variables in
do_linemarker. It seems to occur in this call to linemap_add:
/* Allocate the new line_map. However, if the current map only has a
single line we ca
Hi Cesar!
(At least several of) the issues that I pointed out (see below) have
never been fixed on gomp-4_0-branch, but the test cases have now been
merged from gomp-4_0-branch into trunk, so the regression (PASS -> FAIL
for libgomp.oacc-c-c++-common/reduction-2.c) as well as the other
"oddities"
On Tue, Apr 12, 2016 at 06:53:55AM -0400, Patrick Palka wrote:
> I would appreciate it if someone could backport it for me since I
> won't have time today.
I'm happy to handle backporting and commit for you after approval.
--
Alan Modra
Australia Development Lab, IBM
Hi!
On Mon, 04 Apr 2016 12:39:37 +0200, I wrote:
> [...] gomp-4_0-branch [...] additional (cleanup) changes [...]
> libgomp/
> [...]
> * testsuite/libgomp.oacc-c-c++-common/loop-reduction-gang-np-1.c:
> Merge this file, and...
> * testsuite/libgomp.oacc-c-c++-common/
On Tue, Apr 12, 2016 at 6:38 AM, Alan Modra wrote:
> On Mon, Mar 21, 2016 at 06:35:26PM -0400, Patrick Palka wrote:
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01221.html
>> gcc/cp/ChangeLog:
>>
>> PR c++/70096
>> * pt.c (tsubst_decl): Clear the DECL_MODE of the new decl.
>>
>> gcc
Hi!
Cesar didn't pick up my gomp-4_0-branch change in his recent trunk
commit, so here goes:
On Thu, 24 Mar 2016 17:57:55 +0100, I wrote:
> On Wed, 29 Jul 2015 18:23:12 +0100, Julian Brown
> wrote:
> > This is a set of 19 new tests for OpenACC reductions, covering several
> > ways of performing
On Mon, Mar 21, 2016 at 06:35:26PM -0400, Patrick Palka wrote:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01221.html
> gcc/cp/ChangeLog:
>
> PR c++/70096
> * pt.c (tsubst_decl): Clear the DECL_MODE of the new decl.
>
> gcc/testsuite/ChangeLog:
>
> PR c++/70096
> * g++.
Hello.
As release managers agreed on IRC, following patch reverts r234572
which introduced new PR testsuite/70577.
I've been running bootstrap & regression tests on x86_64-linux-gnu.
Ready to be installed after it finishes?
Thanks,
Martin
>From 978ddfeada20e5597767df120e5d65eef1115c1b Mon Sep 17
On Tue, 12 Apr 2016, Hurugalawadi, Naveen wrote:
+/* Fold A * 10 == B * 10 into A == B. */
+(for cmp (eq ne)
+ (simplify
+ (cmp (mult:c @0 @1) (mult:c @2 @1))
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
+ && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
+ && tree_expr_nonzero_p (@1))
+ (c
On 11/04/16 14:27, Kyrill Tkachov wrote:
>
> On 08/04/16 10:30, Richard Earnshaw (lists) wrote:
>> On 07/04/16 15:51, Kyrill Tkachov wrote:
>>> Hi all,
>>>
>>> In this wrong-code PR we have a Thumb2 peephole transforming:
>>> tstr3, #2
>>> bne.L3
>>> beq.L6
>>>
>>> into:
On Mon, Jan 04, 2016 at 12:33:21PM +0100, Dominik Vogt wrote:
> On Fri, Jan 01, 2016 at 05:53:08PM -0700, Martin Sebor wrote:
> > On 12/31/2015 04:50 AM, Dominik Vogt wrote:
> > >The attached patch fixes C++-11 handling of "alignas(0)" which
> > >should be ignored but currently generates an error m
On Mon, 11 Apr 2016, Jeff Law wrote:
> On 04/08/2016 10:10 AM, Jakub Jelinek wrote:
> > On Fri, Apr 08, 2016 at 06:04:38PM +0200, Richard Biener wrote:
> > > Hmm, don't we simply want to do this for all stmts (OK, only asm have
> > > multiple defs...)?
> >
> > For all stmts that have multiple def
Hi,
>> type is the return type of the comparison. The relevant type here is
TREE_TYPE (@0).
Done.
>>Maybe add a testcase with unsigned, to check that it
does not transform?
Added the testcase
>> you could probably use tree_expr_nonzero_p
Done.
I had !wi::eq_p (@1, 0) for INTEGER_CST, but when t
On Tue, 12 Apr 2016, Tom de Vries wrote:
> [adding cc gcc-patches ]
>
> On 12/04/16 09:25, Tom de Vries wrote:
> > Hi,
> >
> > when compiling the test-case in the patch, we run into an ICE in
> > sese_build_liveouts_use when evaluating 'TREE_CODE (use)' because use is
> > NULL_TREE:
> > ...
> >
On Tue, 12 Apr 2016, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the recent change to handle constant_decl_p
> stuff sometimes results in attempts to store the scalarized pieces again
> into constant_decl_p fields, which of course can't work, those usually live
> in read-only memory.
Thanks Vladimir for reviewing my patch.
> Thank you for the patch. The toplev.c part of the patch is ok for stage 1.
>
> As for reload1.c part, I don't see what you actually changed.
>
Please forgive my innocence, I have mistakenly thought the form-feed character
"^L" in line 415
is a type er
Hi Cesar!
On Mon, 11 Apr 2016 16:23:40 -0700, Cesar Philippidis
wrote:
> This patch backports the reduction changes in trunk to gomp-4_0-branch.
Thanks!
> Prior to this patch, gomp-4_0-branch was having the gimplifier create a
> temporary variable for reference-typed reductions. That's no long
[adding cc gcc-patches ]
On 12/04/16 09:25, Tom de Vries wrote:
Hi,
when compiling the test-case in the patch, we run into an ICE in
sese_build_liveouts_use when evaluating 'TREE_CODE (use)' because use is
NULL_TREE:
...
static void
sese_build_liveouts_use (sese_info_p region, bitmap liveouts,
Hi!
As mentioned in the PR, the recent change to handle constant_decl_p
stuff sometimes results in attempts to store the scalarized pieces again
into constant_decl_p fields, which of course can't work, those usually live
in read-only memory. This happens usually when the aggregate has some
paddin
Hi!
A recent discussion on omp lang reminded me that our firstprivate
target implementation doesn't match the final spec - while I've initially
thought that the vars are to be copied after waiting for the dependencies
(that is where map is mapped), the final spec says they are copied when
creating
77 matches
Mail list logo
