On Thu, Feb 18, 2016 at 10:51:48PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 18, 2016 at 10:45:46PM +0100, Jakub Jelinek wrote:
> > Hi!
> >
> > And here is a fix for the dynamic_cast issue I've mentioned recently.
> > Alternatively, ifnonnull could build instead NE_EXPR with swapped last
> > two a
Hello Jakub,
On 17 Feb 17:46, Jakub Jelinek wrote:
> Hi!
>
> As I wrote in the PR, fwprop is able to forward CONST0_RTX back into
> instructions even if CSE optimized them, but the problem in that case is
> that for vector_move_operand "0C" operands if they appear inside of
> (vec_select ... (para
On 01/31/2016 06:49 AM, Jason Merrill wrote:
These patches fix a couple of abi_tag bugs that were reported to me
recently.
...
The second is an issue where the multiple-initialization guard for a
tagged variable was not itself tagged.
That didn't completely fix the issue. Trying again:
co
On Thu, Feb 18, 2016 at 03:43:07AM -0600, Segher Boessenkool wrote:
> Either combine should delete the note (my current patch), or it can
Works for me. I'm not sure I'd want to promise that combine won't
ever create what you call "invalid RTL", in notes.
--
Alan Modra
Australia Development Lab,
> Hello.
>
> As I finally hunted issue in Firefox that was responsible for start-up
> segfault, I would like
> to describe a new behavior of the compiler that emits clobbers to class
> constructors (w/ -flifetime-dse).
> As also Richi spotted quite similar issue in openjade package, I think it
Ping:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00809.html
On 02/11/2016 02:58 PM, Martin Sebor wrote:
The more than decennnial rtl-optimization/19705 - -fno-branch-count-reg
doesn't prevent decrement and branch instructions on a count register
points out that the documentation of the optio
On 18/02/16 16:27, Richard Biener wrote:
Attached is what I have for now, it works if you call it like
(gdb) dot-fn cfun
(gdb) dot-fn cfun, 1<<6
w/o that arg parsing;)
I'll play with it some more tomorrow.
This version:
- uses arg parsing
- adds error handling
- uses a temp file instead of a
On 02/18/2016 02:56 AM, Richard Biener wrote:
Right. But handling that has never been part of DSE's design goals. Once
there's a use, DSE has always given up.
Yeah, which is why I in the end said we need a "better" DSE ...
Well, I don't see a rewrite/redesign in the mid-term horizon.
Ha
On Thu, Feb 18, 2016 at 10:45:46PM +0100, Jakub Jelinek wrote:
> Hi!
>
> And here is a fix for the dynamic_cast issue I've mentioned recently.
> Alternatively, ifnonnull could build instead NE_EXPR with swapped last
> two arguments on the COND_EXPR, and then I believe the cp_fold change would
> no
Hi!
And here is a fix for the dynamic_cast issue I've mentioned recently.
Alternatively, ifnonnull could build instead NE_EXPR with swapped last
two arguments on the COND_EXPR, and then I believe the cp_fold change would
not be needed.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
Hi!
Here is an attempt to fix up the token reclassification after for statement,
where we lexed the next token with the declaration from for in scope and
need to undo that if it wasn't else.
If token->id_kind is C_ID_CLASSNAME (ObjC only), then token->value has
changed already, but in that case I
On Thu, Feb 18, 2016 at 08:19:22PM +, Bernd Edlinger wrote:
> > Could you add 'PR testsuite/68580' to the log entry when committing?
> >
>
> Yes, of course, thanks.
>
> Could someone take the time and review this patch?
> I don't think it can cause any trouble for gcc-6 and/or gcc-5
> even at
Hi Andreas,
Sorry I haven't responded sooner; I was on vacation and have been
unpiling things since then. The test case had already been updated
since the patch you cited, adding
/* { dg-require-effective-target powerpc64 } */
Is this the version you're testing with?
Thanks,
Bill
On Sat, 2016
On 18.02.2016 12:36, Tom de Vries wrote:
> On 15/02/16 12:29, Bernd Edlinger wrote:
>> Here is a patch that puts each value on it's own 8-byte aligned memory
>> location. From my experience with tsan tests, sharing shadow memory
>> slots between v and q or o is the most likely explanation for the
> Ulrich Weigand wrote:
>> Kevin Nilsen wrote:
>
>> This patch has bootstrapped and tested on powerpc64le-unknown-linux-gnu and=
>> powerpc64be-unknown-linux-gnu (both 32-bit and 64-bit) and=20
>> powerpc64-unknown-freebsd11.0 (big endian) with no regressions. Is it ok to
>> fix this on t
On Thu, 2016-02-18 at 18:26 +0100, Tom de Vries wrote:
> On 18/02/16 16:43, Tom de Vries wrote:
> > On 18/02/16 16:27, Richard Biener wrote:
> > > > > > I would be nice if we could avoid the ${1,2,3} printouts
> > > > > > and value
> > > > > > > > > > history
> > > > > > > > > > assignments, but I'
On Thu, Feb 11, 2016 at 11:20 PM, Patrick Palka wrote:
> Hi Jason,
>
> Your recent fix for PR c++/10200 seems to have fixed this longstanding
> PR too. Should I add its test case to the testsuite and close the PR?
Never mind, this PR is no longer resolved following the most recent
changes to c++
On Wed, Feb 17, 2016 at 10:51 PM, Jason Merrill wrote:
> OK.
Is this an approval of the 2nd patch for next stage 1?
On Thu, Feb 18, 2016 at 11:45 AM, Michael Meissner
wrote:
> This patch to rs6000.md (which is essentially the same as #3) fixes the
> problem
> by removing the early clobber. The patches to predicates.md, and the fusion
> tests revert my changes on February 9th that originally 'solved' the probl
I merged GCC trunk revision 233515 to the gccgo branch.
Ian
Kevin Nilsen wrote:
> This patch has bootstrapped and tested on powerpc64le-unknown-linux-gnu and=
> powerpc64be-unknown-linux-gnu (both 32-bit and 64-bit) and=20
> powerpc64-unknown-freebsd11.0 (big endian) with no regressions. Is it ok t=
> o fix this on the trunk?
>
> The problem described i
On 18/02/16 16:43, Tom de Vries wrote:
On 18/02/16 16:27, Richard Biener wrote:
I would be nice if we could avoid the ${1,2,3} printouts and value
>>> >history
>>> >assignments, but I'm not sure how to do that.
>>> >
Using gdb.parse_and_eval does the trick.
This updated version uses gdb.pa
Hi!
As the testcases show, delete[] this; can also introduce artificial
comparison that -Wnonnull-compare incorrectly warns on, and the
folding can also drop TREE_NO_WARNING if optimizing the operands
of the comparison.
There is another case in rtti, but I'll need to still test a fix for that,
so
Hi!
While this likely isn't a regression, it looks severe enough that IMHO we
should fix this even in stage4 - apparently cp_parser_std_attribute_spec_seq
can drop some of the attributes on the floor, by blindly assuming that
there is just a single attribute inside of [[ ]], but there could be man
On 02/18/2016 01:59 PM, Jakub Jelinek wrote:
> Ok for trunk with those changes.
>
> Jakub
Thank you for review, installed as r233524.
Martin
This patch to rs6000.md (which is essentially the same as #3) fixes the problem
by removing the early clobber. The patches to predicates.md, and the fusion
tests revert my changes on February 9th that originally 'solved' the problem by
not allowing fusion of ADDI values. We have tested the fix us
On 18/02/16 16:27, Richard Biener wrote:
Attached is what I have for now, it works if you call it like
(gdb) dot-fn cfun
(gdb) dot-fn cfun, 1<<6
w/o that arg parsing ;)
I'll play with it some more tomorrow.
Richard.
2016-02-18 Richard Biener
+ /* Overload with additional flag argumen
Ping:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00765.html
On Thu, 2016-02-11 at 10:12 -0500, David Malcolm wrote:
> I've (mostly) ported gcc-python-plugin to gcc 6. The attached patch
> for the gcc website starts a new "Plugin issues" section, and covers
> the biggest issue I ran into (FWIW
On 18/02/16 16:27, Richard Biener wrote:
I would be nice if we could avoid the ${1,2,3} printouts and value
>>> >history
>>> >assignments, but I'm not sure how to do that.
>>> >
Using gdb.parse_and_eval does the trick.
This updated version uses gdb.parse_and_eval, and adds error handling.
On Thu, Feb 18, 2016 at 4:18 PM, Tom de Vries wrote:
> On 18/02/16 16:10, Richard Biener wrote:
>>
>> On Thu, Feb 18, 2016 at 3:29 PM, Tom de Vries
>> wrote:
>>>
>>> >On 17/02/16 14:42, Richard Biener wrote:
>>
>>On Wed, Feb 17, 2016 at 1:41 PM, Tom de Vries
>>wrote:
>
On Thu, 18 Feb 2016, Jan Hubicka wrote:
> >
> > This fixes the IPA inline analysis quadraticness that arises when we
> > inline functions into the same function many times via
> > inline_to_all_callers as we do in the testcase for PR37448. In that
> > case updating the overall summary of the cal
On 18/02/16 16:10, Richard Biener wrote:
On Thu, Feb 18, 2016 at 3:29 PM, Tom de Vries wrote:
>On 17/02/16 14:42, Richard Biener wrote:
>>
>>On Wed, Feb 17, 2016 at 1:41 PM, Tom de Vries
>>wrote:
>>>
>>>Hi,
>>>
>>>once in a while I'm in a gdb debug session debugging cc1, and want to
>>>print
>
> This fixes the IPA inline analysis quadraticness that arises when we
> inline functions into the same function many times via
> inline_to_all_callers as we do in the testcase for PR37448. In that
> case updating the overall summary of the caller is done for each
> inlined call instead of just
On Thu, Feb 18, 2016 at 3:29 PM, Tom de Vries wrote:
> On 17/02/16 14:42, Richard Biener wrote:
>>
>> On Wed, Feb 17, 2016 at 1:41 PM, Tom de Vries
>> wrote:
>>>
>>> Hi,
>>>
>>> once in a while I'm in a gdb debug session debugging cc1, and want to
>>> print
>>> the current function to file.
>>>
>
This patch has bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64be-unknown-linux-gnu (both 32-bit and 64-bit) and
powerpc64-unknown-freebsd11.0 (big endian) with no regressions. Is it ok to
fix this on the trunk?
The problem described in PR66337
(https://gcc.gnu.org/bugzi
The following experiment resulted from looking at making
array_ref_low_bound and array_ref_element_size non-mutating. Again
I wondered why we do this strange scaling by offset/element alignment.
This exposes sth to GIMPLE (the division) that is in the end not
necessary while costing extra tree
On 17/02/16 14:42, Richard Biener wrote:
On Wed, Feb 17, 2016 at 1:41 PM, Tom de Vries wrote:
Hi,
once in a while I'm in a gdb debug session debugging cc1, and want to print
the current function to file.
There's a debug function debug_function that prints a function to stderr,
and there are m
On Thu, Feb 18, 2016 at 11:31:02AM +0100, Christophe Lyon wrote:
> On 17 February 2016 at 17:06, Kyrill Tkachov
> wrote:
> > Hi all,
> >
> > I've thought about this check a bit more and I think we can compactly
> > auto-generate checks
> > for any aarch64 architecture extension support in the asse
On Wed, Feb 17, 2016 at 03:00:00PM +0100, Richard Biener wrote:
> On Wed, Feb 17, 2016 at 2:51 PM, Marek Polacek wrote:
> > On Wed, Feb 17, 2016 at 02:45:36PM +0100, Richard Biener wrote:
> >> OTOH I have in my local trees a more convenient form (attached).
> >>
> >> (gdb) call debug_dot_cfg (cfun
On 18/02/16 13:22, Bernd Schmidt wrote:
On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
Here is the reformatted patch:
This will probably have to wait until stage1.
+ const int code = GET_CODE (op2);
+ if (code != IOR)
+{
+ if (code == EQ_ATTR)
All the formatting
On 18/02/16 13:28, Christophe Lyon wrote:
On 18 February 2016 at 14:20, Nick Clifton wrote:
Hi Christophe,
Could you modify your new testcases, such that they call
check_effective_target_arm_arm_ok ?
Good idea - done.
I'm just realizing that we currently generate arm_arch_vX_ok
for X >=4
On 18 February 2016 at 14:20, Nick Clifton wrote:
> Hi Christophe,
>
>> Could you modify your new testcases, such that they call
>> check_effective_target_arm_arm_ok ?
>
> Good idea - done.
>
>> I'm just realizing that we currently generate arm_arch_vX_ok
>> for X >=4 only. Maybe you should also a
Hi Christophe,
> Could you modify your new testcases, such that they call
> check_effective_target_arm_arm_ok ?
Good idea - done.
> I'm just realizing that we currently generate arm_arch_vX_ok
> for X >=4 only. Maybe you should also add v3?
Possibly. I am not at all sure how important v3 suppo
On Thu, Feb 18, 2016 at 01:02:05PM +0100, Martin Liška wrote:
> gcc/ChangeLog:
>
> 2016-02-18 Jakub Jelinek
> Martin Liska
>
> PR sanitizer/69863
> * cfgexpand.c (asan_sanitize_stack_p): New function.
> (partition_stack_vars): Use the function.
> (expand_sta
On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
Here is the reformatted patch:
This will probably have to wait until stage1.
+ const int code = GET_CODE (op2);
+ if (code != IOR)
+{
+ if (code == EQ_ATTR)
All the formatting still looks completely mangled. This was p
On 02/18/2016 12:22 PM, Marek Polacek wrote:
On Thu, Feb 18, 2016 at 11:53:04AM +0100, Christophe Lyon wrote:
FWIW, I'm seeing the new test failing on the 4.9 branch:
gcc/testsuite/gcc.dg/pr69522.c:2:8: error: struct has no members [-Wpedantic]
gcc/testsuite/gcc.dg/pr69522.c:9:8: error: ISO C fo
Hi.
Following patch was suggested by Jakub (and suggested to be installed in this
stage4).
I've been thinking about a test-case (which would require an assembler scan of
red zone emission).
Should I come up with a ?86 test-case that will scan that?
Bootstrap and regression tests have been runni
On 15/02/16 12:29, Bernd Edlinger wrote:
Here is a patch that puts each value on it's own 8-byte aligned memory
location. From my experience with tsan tests, sharing shadow memory
slots between v and q or o is the most likely explanation for the occasional
inability to spot the race condition on
On Thu, Feb 18, 2016 at 11:53:04AM +0100, Christophe Lyon wrote:
> FWIW, I'm seeing the new test failing on the 4.9 branch:
> gcc/testsuite/gcc.dg/pr69522.c:2:8: error: struct has no members [-Wpedantic]
> gcc/testsuite/gcc.dg/pr69522.c:9:8: error: ISO C forbids empty
> initializer braces [-Wpedant
Hi Honza,
sorry for not being able to review the earlier version you had
sent in a timely manner. This looks good (= please commit) once
you made the two changes Jonathan suggested and the ones below.
And impressive list of contributions!!
On Thu, 18 Feb 2016, Jan Hubicka wrote:
> + Linke
On 16/02/16 16:24, Jakub Jelinek wrote:
Passing the - and ftree-parallelize-loops= stuff looks weird,
and we have %* that substitutes just the variable part of the option,
so in addition to fixing the case of multiple options I've also changed
%:gt() behaviour, so that it now gets just the number
On 16 February 2016 at 16:37, Jeff Law wrote:
> On 02/16/2016 07:21 AM, Bernd Schmidt wrote:
>>
>> On 02/08/2016 05:30 PM, Jeff Law wrote:
>>>
>>> On 01/29/2016 04:40 AM, Bernd Schmidt wrote:
c/
PR c/69522
* c-parser.c (c_parser_braced_init): New arg outer_obstack. All
On 17/02/16 17:07, Sandra Loosemore wrote:
On 02/17/2016 12:14 AM, Tom de Vries wrote:
Here's the documentation entry for the gt spec function (I forgot to add
it when introducing the function), using the new semantics.
Copy-pasting from the resulting .info viewed in emacs for a
human-readable
On Wed, Feb 17, 2016 at 09:07:42AM -0700, Sandra Loosemore wrote:
> On 02/17/2016 12:14 AM, Tom de Vries wrote:
> >
> >Here's the documentation entry for the gt spec function (I forgot to add
> >it when introducing the function), using the new semantics.
> >
> >Copy-pasting from the resulting .info
On 17 February 2016 at 17:06, Kyrill Tkachov
wrote:
> Hi all,
>
> I've thought about this check a bit more and I think we can compactly
> auto-generate checks
> for any aarch64 architecture extension support in the assembler.
> This is done in a similar way we autogenerate the arm_arch_*_ok checks
On 16 February 2016 at 18:19, Nick Clifton wrote:
> Hi Richard, Hi Ramana,
>
> The ARM backend has some problems compiling for the old ARMv3
> architecture. See:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
>
> for an example of this. v3 is very old now, and I am not sure how
On 18/02/16 05:19 +0100, Jan Hubicka wrote:
Hi,
it seems I have updated the patch for comments received but did not send
updated version to the ML. Here it is.
Honza
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/c
On 17 February 2016 at 11:22, Kyrill Tkachov
wrote:
>
> On 17/02/16 10:20, Christophe Lyon wrote:
>>
>> On 17 February 2016 at 11:05, Kyrill Tkachov
>> wrote:
>>>
>>> On 17/02/16 10:03, Christophe Lyon wrote:
On 15 February 2016 at 12:32, Kyrill Tkachov
wrote:
>
> On 04/02
This fixes the IPA inline analysis quadraticness that arises when we
inline functions into the same function many times via
inline_to_all_callers as we do in the testcase for PR37448. In that
case updating the overall summary of the caller is done for each
inlined call instead of just once.
The
On Wed, Feb 17, 2016 at 5:10 PM, Jeff Law wrote:
> On 02/17/2016 07:13 AM, Richard Biener wrote:
>>>
>>> - /* Continue walking until we reach a kill. */
>>> - while (!stmt_kills_ref_p (temp, ref));
>>> + /* Continue walking until we reach a full kill as a single statement
>>> + or there ar
On Thu, Feb 18, 2016 at 09:41:49AM +1030, Alan Modra wrote:
> On Wed, Feb 17, 2016 at 06:31:45AM -0600, Segher Boessenkool wrote:
> > > Corresponding content of "op" which causes the ICE:
> > > gdb) p debug_rtx (op)
> > > (gtu:SI (reg:CC 166) -- (operator and mode doesn't
> >
On Wed, Feb 17, 2016 at 7:51 PM, Andreas Krebbel
wrote:
> I'm having this patchset in my local tree for quite a while now.
> Posting it was so far prevented by some internal process hurdles. I'm
> aware it isn't stage 4 material. I nevertheless would like to commit
> this since:
>
> * It is z13
On Wed, Feb 17, 2016 at 09:20:01PM -0700, Martin Sebor wrote:
> >The reason why MAX_STACK_ALIGNMENT is wrong is that on most targets
> >it is terribly small number (a couple of bytes usually), only i?86/x86_64 is
> >an exception, because it is the only target that supports dynamic stack
> >realignm
63 matches
Mail list logo
