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
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 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 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
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 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
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 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 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 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/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 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 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
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 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
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
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 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
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 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
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 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
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/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 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 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 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
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
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
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 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 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
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 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 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.
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:
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
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 02/18/2016 01:59 PM, Jakub Jelinek wrote:
> Ok for trunk with those changes.
>
> Jakub
Thank you for review, installed as r233524.
Martin
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
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
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
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
I merged GCC trunk revision 233515 to the gccgo branch.
Ian
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
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 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 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'
> 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 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
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 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!
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
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
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
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 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
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
> 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
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,
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
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 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
63 matches
Mail list logo
