Hi!
On Fri, 24 Jan 2014 18:24:56 +0100, I wrote:
> [...] Jakub [...] suggested that I "take over" the [gomp-4_0-branch]
> branch [...]
;-) It's just been a year -- better late than never (I just now found
this page...) -- committed to wwwdocs as r1.200:
Index: htdocs/svn.html
===
On Thu, Jan 29, 2015 at 04:13:38PM +1030, Alan Modra wrote:
> On Thu, Jan 29, 2015 at 06:07:16AM +0100, Jan Hubicka wrote:
> > > On Wed, Jan 28, 2015 at 08:56:22PM +0100, Jan Hubicka wrote:
> > > > -const char * const tls_model_names[]={"none", "tls-emulated",
> > > > "tls-real",
> > > > -
Hi DJ, thanks for review.
> I don't think anything in the toplevel configury looks "sane" any
more, but I think this patch is OK.
I'm sorry, I didn't understand this clearly. Does this mean that I
should wait until Stage 1 starts and commit then, or it is OK now?
-Maxim
On Wed, Jan 28, 2015 at 5:03 PM, Uros Bizjak wrote:
> Hello!
>
>> Currently ix86_conditional_register_usage code may mark EBX as a fixed
>> register if it is called
>> when pic_offset_table_rtx is NULL even if we are going to use pseudo PIC
>> register. It already
>> caused some problem in comb
Hi!
On Sat, 10 Jan 2015 20:21:46 +0100, I wrote:
> On Wed, 12 Nov 2014 15:43:06 -0500, David Malcolm wrote:
> > On Wed, 2014-11-12 at 21:30 +0100, Jakub Jelinek wrote:
> > > On Wed, Nov 12, 2014 at 03:22:21PM -0500, David Malcolm wrote:
> > > > On Wed, 2014-11-12 at 14:47 +0100, Jakub Jelinek wro
Jeff Law wrote:
> OK. I'm a bit surprised we're still finding this kind of stuff 10
> years after NOTE_INSN_SWITCH_TEXT_SECTIONS went in. Sigh.
Thanks for reviewing. I've committed it as revision 220235
after testing the patch independently.
Regards,
kaz
On Thu, Jan 29, 2015 at 9:13 AM, Uros Bizjak wrote:
>>> Currently ix86_conditional_register_usage code may mark EBX as a fixed
>>> register if it is called
>>> when pic_offset_table_rtx is NULL even if we are going to use pseudo PIC
>>> register. It already
>>> caused some problem in combinati
On 28 Jan 2015, at 18:16, Richard Henderson wrote:
> On 01/28/2015 10:10 AM, Dominique d'Humières wrote:
>>> I can't think of any reason they shouldn't work. Were they not running
>>> before,
>>> or did something else change?
>>
>> AFAIU the commit, the tests were not run on x86_64-*-*, so the
Apparently I failed to update this text when doing the gnu89 -> gnu11
change.
Ok?
2015-01-29 Marek Polacek
* doc/standards.texi: Reflect that the default for C is gnu11.
diff --git gcc/doc/standards.texi gcc/doc/standards.texi
index fef81ae..97b12c8 100644
--- gcc/doc/standards.texi
> From: pins...@gmail.com [mailto:pins...@gmail.com]
> Sent: Wednesday, January 28, 2015 6:18 PM
> > +
> > + int get_id ();
> > + std::list *get_roots ();
>
> Why use std::list rather than vec?
When I experimented I realized that better code was generated
if the forests were ordered as they wer
On Thu, Jan 29, 2015 at 10:46:24AM +0100, Marek Polacek wrote:
> Apparently I failed to update this text when doing the gnu89 -> gnu11
> change.
>
> Ok?
>
> 2015-01-29 Marek Polacek
>
> * doc/standards.texi: Reflect that the default for C is gnu11.
>
> diff --git gcc/doc/standards.texi
On Thu, Jan 29, 2015 at 10:49:49AM +0100, Marek Polacek wrote:
> On Thu, Jan 29, 2015 at 10:46:24AM +0100, Marek Polacek wrote:
> > Apparently I failed to update this text when doing the gnu89 -> gnu11
> > change.
> >
> > Ok?
> >
> > 2015-01-29 Marek Polacek
> >
> > * doc/standards.texi:
Hi Alexandre,
> On Jan 28, 2015, Mike Stump wrote:
>
>> On Jan 28, 2015, at 2:27 AM, Rainer Orth
>> wrote:
>>> There are two ways to fix this:
>>>
>>> * Remove the definition of _XOPEN_SOURCE completely. This is slightly
>>> more risky, but more future-proof since defining features test macro
Hi,
Incorrect folding happen when a bitfield in a union is accessed and the union
was initialized via another field. This is a reminiscence of GCC32RM-325 due to
sccvn not passing the right size to fold_ctor_reference. sccvn uses TYPE_SIZE
which gives the size of the container integer for a bit
On Thu, Jan 29, 2015 at 06:27:36PM +0800, Thomas Preud'homme wrote:
> Incorrect folding happen when a bitfield in a union is accessed and the union
> was initialized via another field. This is a reminiscence of GCC32RM-325 due
> to sccvn not passing the right size to fold_ctor_reference. sccvn us
I have filed pr64855.
Dominique
> Le 29 janv. 2015 à 10:10, Iain Sandoe a écrit :
>
>
> On 28 Jan 2015, at 18:16, Richard Henderson wrote:
>
>> On 01/28/2015 10:10 AM, Dominique d'Humières wrote:
I can't think of any reason they shouldn't work. Were they not running
before,
o
On Thu, Jan 29, 2015 at 11:39 AM, Jakub Jelinek wrote:
> On Thu, Jan 29, 2015 at 06:27:36PM +0800, Thomas Preud'homme wrote:
>> Incorrect folding happen when a bitfield in a union is accessed and the
>> union was initialized via another field. This is a reminiscence of
>> GCC32RM-325 due to sccv
On 29 Jan 09:50, Uros Bizjak wrote:
> On Thu, Jan 29, 2015 at 9:13 AM, Uros Bizjak wrote:
>
> >>> Currently ix86_conditional_register_usage code may mark EBX as a fixed
> >>> register if it is called
> >>> when pic_offset_table_rtx is NULL even if we are going to use pseudo PIC
> >>> register.
On Thu, Jan 29, 2015 at 02:27:30PM +0300, Ilya Enkovich wrote:
> Thank you for review! Here is an updated version with proposed changes.
> Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
>
> Thanks,
> Ilya
> --
> 2015-01-29 Ilya Enkovich
Perhaps mention Uros as co-author
Hi all,
This is another cleanup patch that simplifies some expressions of the
form ( ? true : false) or if (boolean == true) and other minor
cleanups.
Tested arm-none-eabi.
Ok for trunk? Or should this wait for the next stage?
Thanks,
Kyrill
2015-01-29 Kyrylo Tkachov
* config/arm/a
On Thu, Jan 29, 2015 at 12:27 PM, Ilya Enkovich wrote:
> On 29 Jan 09:50, Uros Bizjak wrote:
>> On Thu, Jan 29, 2015 at 9:13 AM, Uros Bizjak wrote:
>>
>> >>> Currently ix86_conditional_register_usage code may mark EBX as a fixed
>> >>> register if it is called
>> >>> when pic_offset_table_rtx is
Hi All,
Test gcc.dg/pr64809.c has been deleted as erroneous.
Yuri.
2015-01-28 20:28 GMT+03:00 Jakub Jelinek :
> On Wed, Jan 28, 2015 at 09:23:55AM -0800, H.J. Lu wrote:
>> On Tue, Jan 27, 2015 at 6:52 AM, Yuri Rumyantsev wrote:
>> > Hi All,
>> >
>> > Here is a simple patch that cures ICE - skip
On Wed, 28 Jan 2015, Kyrill Tkachov wrote:
> Hi Richard,
>
> On 28/01/15 14:14, Richard Biener wrote:
> > This fixes PR64829 where widening shift pattern detection fails to
> > verify the widening operation is used only in the shift.
> >
> > Bootstrap and regtest running on x86_64-unknown-linux-
The following fixes double accounting of loads in loops peeled for
alignment. It also adjusts some dump stuff to be more informative
in failing cases.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-01-29 Richard Biener
PR tree-optimization/6484
On Fri, Jan 23, 2015 at 5:35 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> In a process of testing omp-simd tests we found out that couple
> important benchmark did not show any speed-up with aggressive
> if-conversion since the hottest loops have not been vectorized.
> Here is a simple patch that reso
Jakub Jelinek writes:
> On Wed, Jan 28, 2015 at 01:42:47PM -0700, Jeff Law wrote:
>> >2015-01-28 Rainer Orth
>> >
>> >gcc/testsuite:
>> >* gcc.dg/guality/guality.h (main): Add argv[0] to
>> >guality_gdb_command.
>> OK.
>>
>> As for what to do with guality, I haven't a clue. They'
On Wed, Jan 28, 2015 at 11:03 PM, Jan Hubicka wrote:
> Hi,
> the PR is about function not being inlined because it is called via a wrapper
> introduced by ICF merging code. cgraph_node::create_wrapper set
> call_stmt_cannot_inline_p that I suggested to Martin to try to figure out how
> much of mer
On 29/01/15 11:40, Kyrill Tkachov wrote:
Hi all,
This is another cleanup patch that simplifies some expressions of the
form ( ? true : false) or if (boolean == true) and other minor
cleanups.
Tested arm-none-eabi.
Ok for trunk? Or should this wait for the next stage?
Thanks,
Kyrill
2015-01
Bruce Korb writes:
> On 01/28/15 10:15, Bruce Korb wrote:
>> On 01/28/15 10:13, Bruce Korb wrote:
>>> Hi Rainer,
>>>
>>> Sorry for the long delay. Anyway:
>>>
>>> On 01/28/15 06:12, Rainer Orth wrote:
>> * In test_text, I had to backslash-escape the trailing \, otherwise they
>>were
This fixes PR64853 by restricting what we lookup from
match-and-simplifiers further in propagator engine using passes.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-01-29 Richard Biener
PR tree-optimization/64853
* tree-vrp.c (vrp_valueize_1):
Alan,
sorry for letting the ball drop on this one.
> Well, I'd be happy with that. Curiously, that patch is identical to what I
> have here...and that's not what I got having built gcc with
> --target=sparc-sun-solaris2.11, but on further investigation it looks like
> the require-effective-target
Hello!
2015-01-29 Uros Bizjak
* config/i386/i386.c (ix86_mode_after): Make static.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32},
committed to mainline SVN.
Uros.
Index: config/i386/i386.c
===
--- confi
Here is the completed patch. Bootstrapped and regression tested
powerpc64-linux. Is this OK to apply? If not now, then when gcc is
in stage1 again?
gcc/
PR target/64703
* target.def (has_function_descriptors): New hook.
* doc/tm.texi.in: Add TARGET_HAS_FUNCTION_DESCRIPTO
On 29/01/15 12:44, Richard Biener wrote:
On Wed, 28 Jan 2015, Kyrill Tkachov wrote:
Hi Richard,
On 28/01/15 14:14, Richard Biener wrote:
This fixes PR64829 where widening shift pattern detection fails to
verify the widening operation is used only in the shift.
Bootstrap and regtest running
So here's the updated patch which handles all 4 testcases from the PR as
well as a couple of my own.
As discussed earlier this week, we have to twiddle the heuristic for
when to enable 4 insn combinations to make 4-insn combos where the first
insn is a load and the last a store profitable.
On Sat, Jan 17, 2015 at 01:12:49PM +0100, Richard Biener wrote:
> On January 17, 2015 1:37:12 AM CET, Alan Modra wrote:
> >On Fri, Jan 16, 2015 at 11:03:24AM -0600, Segher Boessenkool wrote:
> >> On Fri, Jan 16, 2015 at 08:12:27PM +1030, Alan Modra wrote:
> >> > OK, so we need to fix this in the r
Hello!
> So here's the updated patch which handles all 4 testcases from the PR as well
> as a couple of my own.
@@ -0,0 +1,33 @@
+/* PR 15184 first two tests, plus two addition ones. */
+/* { dg-do compile } */
+/* { dg-options "-O2 -m32 -march=pentiumpro" } */
No, we don't want -m32 in dg-opt
On Thu, Jan 29, 2015 at 03:44:25PM +0100, Uros Bizjak wrote:
> Hello!
>
> > So here's the updated patch which handles all 4 testcases from the PR as
> > well as a couple of my own.
>
> @@ -0,0 +1,33 @@
> +/* PR 15184 first two tests, plus two addition ones. */
> +/* { dg-do compile } */
> +/* {
On Thu, Jan 29, 2015 at 3:47 PM, Jakub Jelinek wrote:
>> > So here's the updated patch which handles all 4 testcases from the PR as
>> > well as a couple of my own.
>>
>> @@ -0,0 +1,33 @@
>> +/* PR 15184 first two tests, plus two addition ones. */
>> +/* { dg-do compile } */
>> +/* { dg-options
On Thu, Jan 29, 2015 at 03:54:34PM +0100, Uros Bizjak wrote:
> On Thu, Jan 29, 2015 at 3:47 PM, Jakub Jelinek wrote:
>
> >> > So here's the updated patch which handles all 4 testcases from the PR as
> >> > well as a couple of my own.
> >>
> >> @@ -0,0 +1,33 @@
> >> +/* PR 15184 first two tests,
On Thu, Jan 29, 2015 at 3:14 PM, Alan Modra wrote:
> Here is the completed patch. Bootstrapped and regression tested
> powerpc64-linux. Is this OK to apply? If not now, then when gcc is
> in stage1 again?
It's ok to apply as it is a wrong-code fix. It would also be ok to backport
if needed.
On Thu, Jan 29, 2015 at 4:05 PM, Richard Biener
wrote:
> On Thu, Jan 29, 2015 at 3:14 PM, Alan Modra wrote:
>> Here is the completed patch. Bootstrapped and regression tested
>> powerpc64-linux. Is this OK to apply? If not now, then when gcc is
>> in stage1 again?
>
> It's ok to apply as it is
On Thu, Jan 29, 2015 at 4:12 PM, Richard Biener
wrote:
> On Thu, Jan 29, 2015 at 4:05 PM, Richard Biener
> wrote:
>> On Thu, Jan 29, 2015 at 3:14 PM, Alan Modra wrote:
>>> Here is the completed patch. Bootstrapped and regression tested
>>> powerpc64-linux. Is this OK to apply? If not now, the
gcc/
PR target/64703
* target.def (has_function_descriptors): New hook.
* doc/tm.texi.in: Add TARGET_HAS_FUNCTION_DESCRIPTORS.
* doc/tc.texi: Regenerate.
* tree-ssa-alias.c (pt_solution_includes_base): New function,
extracted from..
(ref_maybe_used_by_call_p_1): ..here. Handle potential memory
ref
On Thu, Jan 29, 2015 at 04:21:15PM +0100, Richard Biener wrote:
> >>> PR target/64703
> >>> * target.def (has_function_descriptors): New hook.
> >>> * doc/tm.texi.in: Add TARGET_HAS_FUNCTION_DESCRIPTORS.
> >>> * doc/tc.texi: Regenerate.
> >>> * tree-ssa-alias
An erroneous return statement should not lead to a warning about a
missing return statement.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2b9ed36f61ed17ee014cc8cd883eba6df2c9ef88
Author: Jason Merrill
Date: Thu Jan 29 10:16:03 2015 -0500
PR c++/49508
* semantics.c (finish_
The decloning patch reversed the order of the calls to maybe_clone_body
and import_export_decl; as a result, the linkage flags copying that
happens in the former hasn't happened yet in the latter, and so we can
have a DECL_REALLY_EXTERN clone of a !DECL_REALLY_EXTERN constructor.
But since repo
On 01/29/2015 01:10 AM, Iain Sandoe wrote:
>
> On 28 Jan 2015, at 18:16, Richard Henderson wrote:
>
>> On 01/28/2015 10:10 AM, Dominique d'Humières wrote:
I can't think of any reason they shouldn't work. Were they not running
before,
or did something else change?
>>>
>>> AFAIU th
> On Thu, Jan 29, 2015 at 04:13:38PM +1030, Alan Modra wrote:
> > On Thu, Jan 29, 2015 at 06:07:16AM +0100, Jan Hubicka wrote:
> > > > On Wed, Jan 28, 2015 at 08:56:22PM +0100, Jan Hubicka wrote:
> > > > > -const char * const tls_model_names[]={"none", "tls-emulated",
> > > > > "tls-real",
> > > >
On Thu, Jan 29, 2015 at 05:31:14PM +0100, Jan Hubicka wrote:
> > Even the tls.pdf mentions sometimes Global Dynamic and sometimes General
> > Dynamic. But the Global Dynamic is in additions made by me apparently.
> >
> > Anyway, I think it is too late to change this now on the GCC side,
> > we it
On 29 Jan 2015, at 16:22, Richard Henderson wrote:
>>
>> Well, somewhat confusingly "x86/darwin_c.c" is shared between darwin and the
>> various Windows 32 bit implementations.
>
> It's not shared with anything. It's a copy of the old x86/ffi.c
> prior to the merge from upstream.
yeah, I get
Dear All,
I noticed last night that the component array version of Michael's
testcase doesn't even get past resolution. The attached is an updated
version of the patch that fixes that. Although the additional bits of
the patch do not fix a regression, I think that it is worth having the
extra func
On Wed, Jan 28, 2015 at 2:58 PM, Caroline Tice wrote:
> Since all the pieces of this patch have been approved, I will commit
> it later today (since Patrick does not have commit privileges).
I got
configure: error: conditional "VTV_CYGMIN" was never defined.
Usually this means the macro was only
r220254 broke bootstrap on the trunk:
configure: error: conditional "VTV_CYGMIN" was never defined.
Usually this means the macro was only invoked conditionally.
Makefile:12932: recipe for target 'configure-stage1-target-libstdc++-v3' failed
make[4]: *** [configure-stage1-target-libstdc++-v3] Error
On Thu, Jan 29, 2015 at 9:48 AM, H.J. Lu wrote:
> On Wed, Jan 28, 2015 at 2:58 PM, Caroline Tice wrote:
>> Since all the pieces of this patch have been approved, I will commit
>> it later today (since Patrick does not have commit privileges).
>
> I got
>
> configure: error: conditional "VTV_CYGMI
I (sadly) committed this patch in two pieces, one last night and one
this morning. In the commit last night, I had forgotten to commit the
Makefile.in and configure files that got generated by autoconf and
automake. Did you sync your sources before or after the second
commit?
-- Caroline Tice
O
that fixes the build failure. ok to commit?
2015-01-29 Matthias Klose
* acinclude.m4 (GLIBCXX_ENABLE_VTABLE_VERIFY): Define VTV_CYGMIN
unconditionally.
* configure: Regenerate.
On 01/29/2015 06:52 PM, Matthias Klose wrote:
> r220254 broke bootstrap on the trunk:
>
> c
On 29/01/15 19:05 +0100, Matthias Klose wrote:
that fixes the build failure. ok to commit?
2015-01-29 Matthias Klose
* acinclude.m4 (GLIBCXX_ENABLE_VTABLE_VERIFY): Define VTV_CYGMIN
unconditionally.
* configure: Regenerate.
OK, thanks.
On Thu, Jan 29, 2015 at 10:05 AM, Matthias Klose wrote:
> that fixes the build failure. ok to commit?
>
> 2015-01-29 Matthias Klose
>
> * acinclude.m4 (GLIBCXX_ENABLE_VTABLE_VERIFY): Define VTV_CYGMIN
> unconditionally.
> * configure: Regenerate.
>
This is wrong. You
On Thu, Jan 29, 2015 at 10:11 AM, Jonathan Wakely wrote:
> On 29/01/15 19:05 +0100, Matthias Klose wrote:
>>
>> that fixes the build failure. ok to commit?
>>
>> 2015-01-29 Matthias Klose
>>
>>* acinclude.m4 (GLIBCXX_ENABLE_VTABLE_VERIFY): Define VTV_CYGMIN
>>unconditionally.
>>
On 01/29/2015 07:12 PM, H.J. Lu wrote:
> On Thu, Jan 29, 2015 at 10:05 AM, Matthias Klose wrote:
>> that fixes the build failure. ok to commit?
>>
>> 2015-01-29 Matthias Klose
>>
>> * acinclude.m4 (GLIBCXX_ENABLE_VTABLE_VERIFY): Define VTV_CYGMIN
>> unconditionally.
>> *
On Thu, Jan 29, 2015 at 10:13 AM, H.J. Lu wrote:
> On Thu, Jan 29, 2015 at 10:11 AM, Jonathan Wakely wrote:
>> On 29/01/15 19:05 +0100, Matthias Klose wrote:
>>>
>>> that fixes the build failure. ok to commit?
>>>
>>> 2015-01-29 Matthias Klose
>>>
>>>* acinclude.m4 (GLIBCXX_ENABLE_VTAB
On Thu, Jan 29, 2015 at 10:16 AM, H.J. Lu wrote:
> On Thu, Jan 29, 2015 at 10:13 AM, H.J. Lu wrote:
>> On Thu, Jan 29, 2015 at 10:11 AM, Jonathan Wakely wrote:
>>> On 29/01/15 19:05 +0100, Matthias Klose wrote:
that fixes the build failure. ok to commit?
2015-01-29 Matthias
On Thu, Jan 29, 2015 at 10:12:38AM -0800, H.J. Lu wrote:
> On Thu, Jan 29, 2015 at 10:05 AM, Matthias Klose wrote:
> > that fixes the build failure. ok to commit?
> >
> > 2015-01-29 Matthias Klose
> >
> > * acinclude.m4 (GLIBCXX_ENABLE_VTABLE_VERIFY): Define VTV_CYGMIN
> > uncon
On Thu, Jan 29, 2015 at 07:16:17PM +0100, Matthias Klose wrote:
> On 01/29/2015 07:12 PM, H.J. Lu wrote:
> > On Thu, Jan 29, 2015 at 10:05 AM, Matthias Klose wrote:
> >> that fixes the build failure. ok to commit?
> >>
> >> 2015-01-29 Matthias Klose
> >>
> >> * acinclude.m4 (GLIBCXX_ENA
On Thu, Jan 29, 2015 at 10:26 AM, Jakub Jelinek wrote:
> On Thu, Jan 29, 2015 at 07:16:17PM +0100, Matthias Klose wrote:
>> On 01/29/2015 07:12 PM, H.J. Lu wrote:
>> > On Thu, Jan 29, 2015 at 10:05 AM, Matthias Klose wrote:
>> >> that fixes the build failure. ok to commit?
>> >>
>> >> 2015-01-29
On Thu, Jan 29, 2015 at 10:28:17AM -0800, H.J. Lu wrote:
> >> --- acinclude.m4(revision 220257)
> >> +++ acinclude.m4(working copy)
> >> @@ -2320,8 +2320,6 @@
> >>AC_MSG_CHECKING([for vtable verify support])
> >>AC_MSG_RESULT([$enable_vtable_verify])
> >>
> >> - AM_CONDITIO
On Thu, Jan 29, 2015 at 10:30 AM, Jakub Jelinek wrote:
> On Thu, Jan 29, 2015 at 10:28:17AM -0800, H.J. Lu wrote:
>> >> --- acinclude.m4(revision 220257)
>> >> +++ acinclude.m4(working copy)
>> >> @@ -2320,8 +2320,6 @@
>> >>AC_MSG_CHECKING([for vtable verify support])
>> >>
On Sun, Jan 25, 2015 at 7:44 PM, Bill Schmidt
wrote:
> Hi,
>
> A not uncommon idiom on Power for vector floating-point computation is
> used to convert a double-precision value to single-precision and copy it
> to all elements of a vector float. For this we see a specific convert
> UNSPEC feeding
>>> Is it correct that block_num has 1-1 mapping with block_table. And
>>> block_table has 1-1 mapping with logical_table?
>>
>> The first part, yes -- there's one entry in block_table for each
>> block_num in the function tree. But two or more blocks may map to a
>> single logical, and some blocks
On Fri, Jan 30, 2015 at 01:05:54AM +1030, Alan Modra wrote:
> Segher, does this one look better to you? The previous patch turned
> off constant propagation for fixed registers as well as register copy
> propagation. The latter is all I really meant to do.
I'm still not happy about not constant
As discussed in the PR and referenced by the comment in the testcase
itself, the failure is expected on PowerPC and also occurs on SPARC.
Thanks, David
* gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL for powerpc*-*-* and sparc*-*-*.
Index: ssa-dom-cse-2.c
===
On Fri, Jan 23, 2015 at 12:23 PM, Bill Schmidt
wrote:
> Hi,
>
> The POWER8 processor greatly improves performance of unaligned vector
> loads and stores. Except for certain corner cases the compiler can't
> readily track, an unaligned vector load or store performs equivalently
> to an aligned one
On Fri, Jan 30, 2015 at 12:44:37AM +1030, Alan Modra wrote:
> Index: gcc/testsuite/gcc.target/powerpc/pr64703.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/pr64703.c(revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/pr64703.c
On Thu, Jan 29, 2015 at 01:55:22PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 30, 2015 at 12:44:37AM +1030, Alan Modra wrote:
> > Index: gcc/testsuite/gcc.target/powerpc/pr64703.c
> > ===
> > --- gcc/testsuite/gcc.target/powerpc/pr
On Thu, Jan 29, 2015 at 09:01:31PM +0100, Jakub Jelinek wrote:
> > . matches newline; use [^,]*, instead?
>
> \[^,\]* or \[^,]* , otherwise dejagnu/tcl eats it.
Right; I did mention to use {} instead of "" in a previous mail :-)
Segher
On Thu, Jan 29, 2015 at 07:30:31AM -0700, Jeff Law wrote:
> @@ -2643,6 +2644,34 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
> rtx_insn *i0,
> || GET_CODE (src) == LSHIFTRT)
> nshift++;
> }
> +
> + /* If I0 loads a memory and I3 sets the same memo
ping!
On 27 January 2015 at 20:38, Paul Richard Thomas
wrote:
> Dear All,
>
> This patch enables the passing of an allocatable class object, scalar
> or array, to a derived type of the declared type, either in an
> assignment or as an actual argument. Much of the effort went into
> sorting out th
David Edelsohn writes:
> As discussed in the PR and referenced by the comment in the testcase
> itself, the failure is expected on PowerPC and also occurs on SPARC.
>
> Thanks, David
>
> * gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL for powerpc*-*-* and sparc*-*-*.
>
> Index: ssa-dom-cse-2.c
> ===
As pointed out to me by Damian (and to him by one of his course
attendees), the description wrongly claimed that the source-image
argument of co_broadcast is optional. (Thanks!)
Fixed by the attached patch (Rev. 220261).
It was probably a copy'n'paste error as CO_MAX etc. take an optional
RES
On Thu, Jan 29, 2015 at 6:56 AM, Jakub Jelinek wrote:
> On Thu, Jan 29, 2015 at 03:54:34PM +0100, Uros Bizjak wrote:
>> On Thu, Jan 29, 2015 at 3:47 PM, Jakub Jelinek wrote:
>>
>> >> > So here's the updated patch which handles all 4 testcases from the PR
>> >> > as well as a couple of my own.
>>
On Thu, Jan 29, 2015 at 01:27:24PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 30, 2015 at 01:05:54AM +1030, Alan Modra wrote:
> > Segher, does this one look better to you? The previous patch turned
> > off constant propagation for fixed registers as well as register copy
> > propagation. The
2015-01-29 14:27 GMT+00:00 Kyrill Tkachov :
>
> On 29/01/15 12:44, Richard Biener wrote:
>>
>>
>> Can you test?
>
two issues during bootstrapping the patch on arm board on top of r220249
* one warning treated as error.
declaration of "new_stmt" need to be removed in
vect_handle_widen_op_by_
Hi!
The SAVE_EXPR was needed here only in the previous implementation where
we emitted more code inline early, now that we have UBSAN_VPTR internal call
that is lowered during sanopt, we use it just once.
Furthermore, the SAVE_EXPR caused e.g. the following two testcases to
misbehave, as a shared
Here the problem is that we issue a bogus "missing initializer" warning
even for zero-initializer "{ 0 }". So in case we're sure we have such
a zero-initializer, suppress the warning. If the constructor has a single
element which is not zero, don't set anything; it might be a constructor
from ano
On Thu, Jan 29, 2015 at 09:50:45PM +0100, Marek Polacek wrote:
> Here the problem is that we issue a bogus "missing initializer" warning
> even for zero-initializer "{ 0 }". So in case we're sure we have such
> a zero-initializer, suppress the warning. If the constructor has a single
> element wh
Here's a very slightly revised patch, fixing a couple of bugs found
during GDB testing.
In out_logical_entry, I should pass along the value of is_stmt when
creating a logical for the calling context, so that we get a
breakpoint location for the point of call:
context = out_logical_entry (t
The issue was first reported by Joachim Wieland to the list
g...@gcc.gnu.org, on Wed,
Jan 19, 2011 (Subject: PLUGIN_FINISH_TYPE not executed for enums).
A description of the problem/bug and how my patch addresses it.
patch is ok for google branch.
Dehao
On Thu, Jan 29, 2015 at 1:11 PM, Cary Coutant wrote:
> Here's a very slightly revised patch, fixing a couple of bugs found
> during GDB testing.
>
> In out_logical_entry, I should pass along the value of is_stmt when
> creating a logical for the calling conte
The attached patch fixes PR64855 by not setting targetabis on
darwin in testsuite/lib/libffi.exp as suggested by Iain Sandoe.
Confirmed on x86_64-apple-darwin14 to eliminate the libffi regressions
at -m32/-m64. Okay for gcc trunk?
Jack
2015-01-29 Jack Howarth
PR libffi/64855
On 01/29/2015 01:53 PM, Jack Howarth wrote:
> PR libffi/64855
> * testsuite/lib/libffi.exp: Don't set targetabis on darwin.
Ok.
r~
On Jan 29, 2015, at 11:39 AM, David Edelsohn wrote:
>
> This is a reasonable change, but please ask a vect maintainer like
> Richi or a testsuite maintainer to approve.
So, my perspective, looks usual and customary.
I do worry about the turing complete nature of testing and the endless lets
bu
On Jan 29, 2015, at 1:56 PM, Richard Henderson wrote:
> On 01/29/2015 01:53 PM, Jack Howarth wrote:
>> PR libffi/64855
>> * testsuite/lib/libffi.exp: Don't set targetabis on darwin.
>
> Ok.
Committed revision 220264.
I can't say if this fixes a bug important enough for stage4, but if
someone wants to claim that, you won't have to wait for stage 1 :-)
Paul Richard Thomas wrote:
ping!
[...]
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.
Groucho Marx
It has been pointed out that with the advent of ebook readers, the
latter is no longer true. Additionally, it is uncertain whether he
actually said this
On Mon, 26 Jan 2015, Mike Stump wrote:
> +@item #pragma GCC unroll @var{"n"}
> +@cindex pragma GCC unroll @var{"n"}
@var contains the name of a metasyntactic variable; it doesn't make sense
for quotes to be included in that name. And as far as I can tell, the
quotes aren't part of the syntax e
On Mon, 26 Jan 2015, Mike Stump wrote:
> + if (!INTEGRAL_TYPE_P (TREE_TYPE (expr))
> + || TREE_CODE (expr) != INTEGER_CST
> + || (lunroll = tree_to_shwi (expr)) < 0
> + || lunroll > USHRT_MAX)
> +{
> + c_parser_error (parser, "%<#pragma GCC unroll%> requires a
> non-negat
On Mon, 29 Dec 2014, Mikhail Maltsev wrote:
> diff --git a/gcc/testsuite/gcc.dg/Wconversion-complex-c99.c
> b/gcc/testsuite/gcc.dg/Wconversion-complex-c99.c
> new file mode 100644
> index 000..b1aaf54
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/Wconversion-complex-c99.c
> @@ -0,0 +1,139 @@
>
There was bug in the fix for PR 61880: it only worked fully correctly
for code compiled with -fgo-pkgpath. For code that used -fgo-prefix,
or that used neither option, the '.' separating the prefix and the
package name was converted to an underscore, which did not happen
before. This broke SWIG a
The problem in this PR is that rs6000_stack_info spends an enormous amount
of time when compiling thunks. This turns out to be a loop in
compute_vrsave_mask that loops (almost) 4G times because the loop counter
is unsigned and the reversed loop is not written in a way that can handle
crtl->args.in
1 - 100 of 114 matches
Mail list logo
