Hi Richard,
DJ is on vacation at the moment, but he asked me to ping you about
backporting this patch:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02321.html
to the 4.5 and 4.6 branches:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02683.html
May I apply the patch there please ?
Che
On Mon, Aug 8, 2011 at 7:11 PM, Uros Bizjak wrote:
>> Moves are special as far as reload is concerned. If there is already
>> a move instruction present *before* reload, it will get fixed up
>> according to its constraints as any other instruction.
>>
>> However, reload will *introduce* new move
On Mon, 8 Aug 2011, Ulrich Weigand wrote:
> Richard Guenther wrote:
>
> > Of course testing for the fold makes sure we also test for the crash ...
> > so yes, the idea was to also test for the fold. As the LTO testing
> > harness does not support scanning dumps (sigh...) link tests are
> > the o
I forgot to include the dwarf2out.c:file_table. Stats are printed when -g.
See attached patch. Additional Changelog:
* dwarf2out.c (dwarf2out_finish): Call htab_dump_statistics() if
-fmem-report.
Dimitris
=== modified file 'gcc/dwarf2out.c'
--- gcc/dwarf2out.c 2011-06-06 1
On Mon, 8 Aug 2011, Uros Bizjak wrote:
> Hello!
>
> One notable omission from x87 rounding sequences is plain round(),
> since x87 does not support round-to-nearest, away-from-zero directly.
> However, this function can be synthesized as round(a) = sgn(a) *
> floor(fabs(a) + 0.5). Fortunately, we
Hello,
actual the remaining issue about this PR is that vrp
constructs by range analyzis for bitwise and/or expressions
type-casted results, like ((type) A) op ((type) B), or ((type) A) op CST.
So I've added to simplify_bit_ops_using_rnages the transformation of
((type) A) op ((type) B) -> (type
On Tue, Aug 9, 2011 at 10:21 AM, Richard Guenther wrote:
>> One notable omission from x87 rounding sequences is plain round(),
>> since x87 does not support round-to-nearest, away-from-zero directly.
>> However, this function can be synthesized as round(a) = sgn(a) *
>> floor(fabs(a) + 0.5). Fort
While testing the patches to finally fix
PR libstdc++-v3/1773__cplusplus defined to 1, should be 199711L
I came across two build failures when testing on i386-pc-solaris2.11:
/vol/gcc/src/hg/trunk/solaris/gcc/java/jcf-dump.c: In function 'void
print_constant(std::FILE*, JCF*, int, int)':
/v
Work is currently underway to finally fix
PR libstdc++-v3/1773__cplusplus defined to 1, should be 199711L
which hadn't been handled before because libstdc++ couldn't cope with
the (partial) C++ overloads in Solaris headers. I started with Marc's
patches from the PR (thanks!), cleaned them up
While checking how to fix
PR libstdc++-v3/1773__cplusplus defined to 1, should be 199711L
it was discovered that without countermeasures, changing __cplusplus
from 1 to 199711L breaks the Solaris ABI by moving tm from the global
namespace to std, among others, e.g.
-FUNC:std::__timepunct::_M
This patch is the last but one in the series to finally fix
PR libstdc++-v3/1773__cplusplus defined to 1, should be 199711L
Again, this is almost completely Marc's work. I've only added the
ChangeLog entry and fixed an issue found during Solaris 8 testing:
only declares double abs(double)
On Fri, Aug 5, 2011 at 7:25 PM, Aldy Hernandez wrote:
> Alright, I'm back and bearing patches. Firmly ready for the crucifixion you
> will likely submit me to. :)
>
> I've pretty much rewritten everything, taking into account all your
> suggestions, and adding a handful of tests for corner cases
This patch achieves what all the previous ones have prepared: finally
defining __cplusplus correctly instead of the current 1. I'm uncertain
if it's already appropriate to define the C++ 2011 value yet, but I've
kept it in the patch.
Of course this patch can only go in once all the prerequisite p
Hi Guys,
I am checking in the patch below to the mainline and 4.6 branch. It
disables the peephole optimizations in the rx.md file that combine a
load followed by a zero- or sign- extend operation. The disabling
only happens at -O3 (or higher) as although the peepholes reduce the
numbe
Other than Ramana's comment about my comment on 4/4, has anyone else got any
other input? Otherwise I'd like to fix that comment and then get it in.
Dave
On 26 July 2011 09:59, Dr. David Alan Gilbert wrote:
> Hi,
> This is V2 of a series of 4 patches relating to ARM atomic operations;
> they i
> I am checking in the patch below to the mainline and 4.6 branch. It
> disables the peephole optimizations in the rx.md file that combine a
> load followed by a zero- or sign- extend operation. The disabling
> only happens at -O3 (or higher) as although the peepholes reduce the
> number of
Ups missed to update patch before sending it. Inlined tested patch.
Kai
Index: gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
===
--- gcc.orig/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
+++ gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
@@ -4,8 +4
Hi,
here is patch for fixing FMA typo + bunch of traling spaces removed.
Changelog entry:
2011-08-09 Kirill Yukhin
* config/i386/i386.c: Remove traling spaces.
* config/i386/sse.md: Likewise.
(*fma_fmadd_): Update.
(*fma_fmsub_): Likewise.
(*fma_fnmadd
Hi Paul,
It disables the peephole optimizations in the rx.md file that combine a
load followed by a zero- or sign- extend operation. The disabling
only happens at -O3 (or higher) as although the peepholes reduce the
number of instructions they can introduce pipeline stalls that
actual
Hi,
On Mon, 8 Aug 2011, Ulrich Weigand wrote:
> > This patch exposes a problem in libada. But I'd still be interested
> > if it fixes the spu problem.
>
> It turns out that the patch not only fixes the pr49771 failure, but in
> fact *all* outstanding vectorizer test case failures on SPU in bo
On Tue, Aug 9, 2011 at 1:00 PM, Kirill Yukhin wrote:
> here is patch for fixing FMA typo + bunch of traling spaces removed.
>
> Changelog entry:
>
> 2011-08-09 Kirill Yukhin
>
> * config/i386/i386.c: Remove traling spaces.
> * config/i386/sse.md: Likewise.
>
> (*fma_fmadd_
>
> How was the patch tested? On the simulator?
Actually, the problem is not catched by testing. I found one when
runnning Spec 2006 under simulator.
With the patched Spec 2006 suite seems to work OK
>
>> Could anybody with `waa` commit it?
>
> Patch is OK and committed to mainline.
>
> Thanks,
>
Hi Andreas,
> the patch below survives bootstrap stage-1 on PowerPC FreeBSD successfully.
> W/o patch we try to fliter-out ibm-ldouble.c. So from my understanding the
> pattern ibm-ldouble.c does never match since there is a path prepended to
> the file name.
> With the patch we look for everythin
On Fri, 2011-08-05 at 19:33 +0200, Torvald Riegel wrote:
> patch8:
>
> The first patch merely keeps a list of all threads with transactions,
> registering and deregistering gtm_transaction objects during their
> construction and destruction. The aligment attribute for the start of
> the shared par
Hans-Peter Nilsson writes:
> On Mon, 8 Aug 2011, Rainer Orth wrote:
>> * SUPPORTS_WEAK is probably best detected with autoconf. We have
>> libgfortran/acinclude.m4 (LIBGFOR_GTHREAD_WEAK), but should probably
>> go for m4/ax_sys_weak_alias.m4 from the autoconf-archive instead. If
>> we're
Richard Sandiford writes:
>> So this patch only deals with the sync functions proper and should be
>> relatively straightforward. Richard, could you please try this one,
>> too?
>
> Sure. Tested on mips64-linux-gnu, where it works fine, thanks.
Fine, thanks for testing.
>> 2011-07-10 Rainer
On Mon, 8 Aug 2011, Richard Guenther wrote:
> On Mon, 8 Aug 2011, Richard Guenther wrote:
>
> > On Fri, 5 Aug 2011, Paolo Bonzini wrote:
> >
> > > On 08/05/2011 01:04 PM, Richard Guenther wrote:
> > > > (I believe that's the only bit we know sth about
> > > > when both vr.min and vr.max are nega
On 9 August 2011 13:23, Richard Guenther wrote:
> 2011-08-08 Richard Guenther
>
> * tree-vrp.c (zero_nonzero_bits_from_vr): Also return precise
> information for with only negative values.
"for *ranges* with" ?
Jay.
Paolo Bonzini writes:
> On 08/06/2011 05:07 PM, Mikael Morin wrote:
>> On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote:
>>> Can you try this instead?
>> It works. Thanks
>
> Committed, thanks.
Thanks for fixing this.
Rainer
--
--
Andreas Schwab writes:
> It's already fixed, 'twas the missing ldflags.
I see, so I wasn't the only victim :-)
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Richard Sandiford writes:
> Rainer Orth writes:
>> * config.host (unwind_header): New variable.
>> (*-*-freebsd*): Set tmake_file to t-eh-dw2-dip.
>> (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu, *-*-knetbsd*-gnu,
>> *-*-gnu*): Likewise, also for *-*-kopensolaris*-gnu.
>>
Rainer Orth writes:
> Andreas Schwab writes:
>
>> It's already fixed, 'twas the missing ldflags.
>
> I see, so I wasn't the only victim :-)
Unfortunately it didn't really fix it, the undefined symbol is still
present in libgcc_s.so. I'll experiment with the config file juggling.
Andreas.
--
Hi,
Here is second stage patch.
It introduces AVX2 option, define etc.
ChangeLog entry:
2011-08-09 Kirill Yukhin
* common/config/i386/i386-common.c (OPTION_MASK_ISA_AVX2_SET): New.
(OPTION_MASK_ISA_FMA_UNSET): Update.
(OPTION_MASK_ISA_AVX2_UNSET): New.
(ix86_ha
On Tue, Aug 9, 2011 at 2:35 AM, Rainer Orth
wrote:
> Ok for mainline (no point in backporting to release branches since this
> will never be used)?
Hi Rainer,
"never be used"? OK. Looks good to me. Cheers - Bruce
Hi Bruce,
> On Tue, Aug 9, 2011 at 2:35 AM, Rainer Orth
> wrote:
>> Ok for mainline (no point in backporting to release branches since this
>> will never be used)?
>
> Hi Rainer,
>
> "never be used"? OK. Looks good to me. Cheers - Bruce
I doubt anyone would consider backporting the change in
On Tue, 9 Aug 2011, Rainer Orth wrote:
This patch achieves what all the previous ones have prepared: finally
defining __cplusplus correctly instead of the current 1. I'm uncertain
if it's already appropriate to define the C++ 2011 value yet, but I've
kept it in the patch.
Hello,
I don't thin
Richard Guenther wrote:
> On Mon, 8 Aug 2011, Ulrich Weigand wrote:
> > OK, so what about the following version? This keeps not linking against
> > libm so it will fail if cabs is not folded. On the other hand, it will
> > provide a dummy implementation of sqrt to avoid failure simply because
> >
> "Dimitrios" == Dimitrios Apostolou writes:
Dimitrios> 2011-08-09 Dimitrios Apostolou
[...]
Dimitrios> * symtab.c (ht_dump_statistics): Beautified stats output.
Make sure the ChangeLog entries go in the correct directories.
Dimitrios> + obmem= obstack_memory_used (&table->stack);
Hello,
the gcc.dg/pr49948.c test uses -ftree-parallelize-loops, and therefore
can only run on targets supporting threads. All other similar tests
carry a "dg-require-effective-target pthread" marker, but it is missing
here. This causes failures on (e.g.) spu-elf.
The patch below adds the requir
On Tue, Aug 9, 2011 at 3:18 PM, Tom Tromey wrote:
>> "Dimitrios" == Dimitrios Apostolou writes:
>
> Dimitrios> 2011-08-09 Dimitrios Apostolou
> [...]
> Dimitrios> * symtab.c (ht_dump_statistics): Beautified stats output.
>
> Make sure the ChangeLog entries go in the correct directorie
Hello,
the gfortran.dg/scratch_1.f90 fails on SPU because the library allocates
data structures that exceed the available local store size of 256KB.
Like already done in similar cases, the patch below skips the test
on the spu-*-* platform.
Tested on spu-elf, committed to mainline.
Bye,
Ulrich
Hi,
On Tue, 9 Aug 2011, Richard Guenther wrote:
> > Actually we should adjust the ranges only if it's either all positive
> > or negative values from the start and the adjustment keeps us on the
> > same side of zero.
>
> So we kept discussing this to death somewhat. Which eventually resulted
PING.
On Sat, Aug 6, 2011 at 7:40 AM, H.J. Lu wrote:
> PING.
>
> On Fri, Jul 22, 2011 at 7:06 AM, H.J. Lu wrote:
>> On Fri, Jul 22, 2011 at 7:00 AM, H.J. Lu wrote:
>>> On Fri, Jul 22, 2011 at 6:03 AM, H.J. Lu wrote:
On Fri, Jul 22, 2011 at 5:30 AM, Jakub Jelinek wrote:
> On Fri, Jul
On Mon, 1 Aug 2011, Richard Guenther wrote:
>
> This fixes PR49907 - ok for trunk?
Ping.
Thanks,
Richard.
> Thanks,
> Richard.
>
> 2011-08-01 Richard Guenther
>
> PR bootstrap/49907
> lto-plugin/
> * configure.ac: Use ACX_PROG_CC_WARNING_OPTS to detect -Wall presence.
>
The definition of LIB2ADDEH from ia64/t-glibc is supposed to prevail.
I've verified that the resulting libgcc_s.so aggrees with the one
produced by the 4.6 branch. Checked in as obvious.
Andreas.
2011-08-09 Andreas Schwab
* config.host (ia64*-*-linux*): Move ia64/t-glibc after
Andreas,
> The definition of LIB2ADDEH from ia64/t-glibc is supposed to prevail.
> I've verified that the resulting libgcc_s.so aggrees with the one
> produced by the 4.6 branch. Checked in as obvious.
in that case, ia64/t-eh-ia64 should be removed since it's overridden
completely and only serve
On 08/08/2011 10:35 PM, H.J. Lu wrote:
On Mon, Aug 8, 2011 at 4:19 PM, Vladimir Makarov wrote:
The following patch fixes PR49990. The problem is described on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
Reg classes which can not change modes for some pseudo were excluded from
the consid
On Tue, Aug 9, 2011 at 7:37 AM, Vladimir Makarov wrote:
> On 08/08/2011 10:35 PM, H.J. Lu wrote:
>>
>> On Mon, Aug 8, 2011 at 4:19 PM, Vladimir Makarov
>> wrote:
>>>
>>> The following patch fixes PR49990. The problem is described on
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
>>>
>
This fixes PR49937 - callers of get_{pointer,object}_alignment
probably should not use BIGGEST_ALIGNMENT to limit what these
functions return (why do they do that? Maybe because formerly
the routines returned TYPE_ALIGN? But why wasn't that bound by
BIGGEST_ALIGNMENT?) - some targets define that
On 08/08/2011 03:22 PM, Steve Ellcey wrote:
> Oh, so after I declare md5, I call md5_finish_ctx like:
>
> md5_finish_ctx (&md5.ctx, md5.checksum);
>
> Is that what you are proposing? It seems a bit odd to put checksum in a
> a structure with ctx just to guarantee its alignment and not to
On 08/09/2011 04:22 PM, Richard Guenther wrote:
>
> This fixes PR49907 - ok for trunk?
Ping.
Thanks,
Richard.
Ok.
Paolo
On 08/09/2011 02:14 PM, Rainer Orth wrote:
> OK for the MIPS parts.
Paolo, are you ok with the build parts?
Yes.
Paolo
On Tue, Aug 9, 2011 at 12:40 AM, Uros Bizjak wrote:
> On Mon, Aug 8, 2011 at 7:11 PM, Uros Bizjak wrote:
>
>>> Moves are special as far as reload is concerned. If there is already
>>> a move instruction present *before* reload, it will get fixed up
>>> according to its constraints as any other i
Andrew's mail to gcc-patches keeps bouncing. Trying on his behalf.
Original Message
Subject:Re: [C++0x] contiguous bitfields race implementation
Date: Tue, 09 Aug 2011 09:49:51 -0400
From: Andrew MacLeod
To: Richard Guenther
CC: Aldy Hernandez , Jason Merr
On 08/09/2011 10:50 AM, H.J. Lu wrote:
On Tue, Aug 9, 2011 at 7:37 AM, Vladimir Makarov wrote:
On 08/08/2011 10:35 PM, H.J. Lu wrote:
On Mon, Aug 8, 2011 at 4:19 PM, Vladimir Makarov
wrote:
The following patch fixes PR49990. The problem is described on
http://gcc.gnu.org/bugzilla/show_bug
> "Richard" == Richard Guenther writes:
>> The libcpp part is ok with this change.
Richard> Note that sparsely populated hashes come at the cost of increased
Richard> cache footprint. Not sure what is more important here though, memory
Richard> access or hash computation.
I was only approv
Hi Tom,
RTEMS does not have virtual memory management, so there is no error
when access the 0 address on rtems.
So 'str->length()' donot throw NPE and just return an meaningless value.
Ps: There is a test:
http://code.google.com/p/rtemsgcj/source/browse/trunk/algorithm/20110810NPE/?r=127,
npe.c i
> "Rainer" == Rainer Orth writes:
Rainer> 2011-08-07 Rainer Orth
Rainer> gcc/java:
Rainer> * jcf-dump.c (print_constant): Cast first frexp arg.
Rainer> libjava:
Rainer> * exception.cc (std::abort): Remove static.
Ok.
Tom
> "Jie" == Jie Liu writes:
Jie> RTEMS does not have virtual memory management, so there is no error
Jie> when access the 0 address on rtems.
Jie> So 'str->length()' donot throw NPE and just return an meaningless value.
If you compile the Java parts of the library with -fcheck-references, it
Hello!
> One notable omission from x87 rounding sequences is plain round(),
> since x87 does not support round-to-nearest, away-from-zero directly.
> However, this function can be synthesized as round(a) = sgn(a) *
> floor(fabs(a) + 0.5). Fortunately, we have all building blocks ready
> in i386.md
This is an initial patch to work around the slow down of sphinx3 in power7 VSX
that first shows up in GCC 4.6 and is still present in the current GCC 4.7
trunk. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50031
The key part of the slowdown is in this inner loop in the
vector_gautbl_eval_logs3 fu
On Tue, Aug 9, 2011 at 2:07 PM, Michael Meissner
wrote:
> This is an initial patch to work around the slow down of sphinx3 in power7 VSX
> that first shows up in GCC 4.6 and is still present in the current GCC 4.7
> trunk. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50031
>
> The key part of the
ok, so now you do this only for the first field in a bitfield group. But you
do it for _all_ bitfield groups in a struct, not only for the interesting one.
May I suggest to split the loop into two, first searching the first field
in the bitfield group that contains fld and then in a separate l
On 08/09/2011 09:14 AM, Marc Glisse wrote:
I don't think we should define the C++ 2011 value yet. In my opinion, we
should wait until:
1) the standard is official
2) gcc implements most of it: people will want to use __cplusplus as a
test to know if they can use C++0X features, not if the compile
This is a patch that was approved a long time ago here:
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01833.html
but was never submitted.
2011-08-09 Artjoms Sinkarovs
/gcc
* c-typeck.c (scalar_to_vector): New function. Try scalar to
vector conversion.
(stv_conv): New enum for scalar_to_vector
Sorry, I didn't attach the patch itself.
Here we go, in the attachment.
Artem.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 177589)
+++ gcc/doc/extend.texi (working copy)
@@ -6526,18 +6526,25 @@ In C it is possibl
This patch is still pending review:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02376.html
Georg-Johann Lay a écrit:
[...]
So here is a cleaned up version that maps to QI shifts.
Tested without regressions.
Ok?
Johann
PR target/29560
* config/avr/avr.md (any_extend): New
On Tue, 2011-08-09 at 08:25 -0700, Richard Henderson wrote:
> On 08/08/2011 03:22 PM, Steve Ellcey wrote:
> > Oh, so after I declare md5, I call md5_finish_ctx like:
> >
> > md5_finish_ctx (&md5.ctx, md5.checksum);
> >
> > Is that what you are proposing? It seems a bit odd to put checksum i
On 08/09/2011 02:32 PM, Steve Ellcey wrote:
> On Tue, 2011-08-09 at 08:25 -0700, Richard Henderson wrote:
>> On 08/08/2011 03:22 PM, Steve Ellcey wrote:
>>> Oh, so after I declare md5, I call md5_finish_ctx like:
>>>
>>> md5_finish_ctx (&md5.ctx, md5.checksum);
>>>
>>> Is that what you are pro
On 08/09/2011 12:20 AM, Nick Clifton wrote:
> Hi Richard,
>
> DJ is on vacation at the moment, but he asked me to ping you about
> backporting this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02321.html
>
> to the 4.5 and 4.6 branches:
>
> http://gcc.gnu.org/ml/gcc-patches/20
On Tue, 9 Aug 2011, Tom Tromey wrote:
"Richard" == Richard Guenther writes:
The libcpp part is ok with this change.
Richard> Note that sparsely populated hashes come at the cost of increased
Richard> cache footprint. Not sure what is more important here though, memory
Richard> access or h
On Tue, 2011-08-09 at 16:50 -0700, Richard Henderson wrote:
> >
> > I think I like using a union to ensure the alignment of checksum better.
> > In dwarf2out.c we are always using one md5_ctx structure and one
> > checksum buffer but in fold-const.c there are routines where we use one
> > md5_ctx
On Tue, 9 Aug 2011, Richard Guenther wrote:
>
> This fixes PR49937 - callers of get_{pointer,object}_alignment
> probably should not use BIGGEST_ALIGNMENT to limit what these
> functions return (why do they do that? Maybe because formerly
> the routines returned TYPE_ALIGN? But why wasn't that bo
>>> Gah. I was going to commit this separately but forgot. Sorry about that.
>>>
>> K, why does this fix the test? seems weird that we had an infinite
>> loop before and changing the flags gets rid of it?
>
> It wasn't an infinite loop but an ICE in the tree caches. The
> different options were
Let me know if my recent push has not solved this problem.
On 8/5/11, Gabriel Charette wrote:
> I now get the following test failure output after pulling this patch
> (potentially from the almost concurrent checkin of my linetable
> patch?)
>
> I can send you my diff's if you need to compare.
>
>
2011/8/10 Georg-Johann Lay :
> This patch is still pending review:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02376.html
>
> Georg-Johann Lay a écrit:
>>
>> [...]
>>
>> So here is a cleaned up version that maps to QI shifts.
>>
>> Tested without regressions.
>>
>> Ok?
Ok.
Denis.
76 matches
Mail list logo
