Bootstrapped and tested in trunk, but I guess it'll fit 4.9 branch
well. I'll do another test for 4.9 if it's appropriate to commit.
Thanks!
--
Regards,
Tim Shen
commit e433cdbe4a1b8660fcd452c1a5e08972c495d08f
Author: timshen
Date: Sat Jan 17 19:34:14 2015 -0800
PR libstdc++/64649
While continuing to work on a proposal for splitting up the optimization
options section of the GCC manual into subsections (just posted to
gcc@), I found that -funroll-loops and -funroll-all-loops also had
duplicate entries. As with the previous patch to remove the duplicate
for -ftracer, I k
On 01/17/2015 03:58 PM, Jonathan Wakely wrote:
My fault, this additional chunk is needed alongside the patch I sent
earlier:
--- a/libstdc++-v3/include/bits/atomic_futex.h
+++ b/libstdc++-v3/include/bits/atomic_futex.h
@@ -35,7 +35,7 @@
#include
#include
#include
-#if !defined(_GLIBCXX_HAVE_
Supporting this turned out to be more involved. --with-cpu implicitly
adds -mcpu to all specs, which invokes the assembler with the correct
option. Directly setting TARGET_DEFAULT does not adjust the assembler
invocation.
This patch adds support to rs6000_file_start to emit the .machine
assemble
On 17/01/15 16:53 -0800, Tim Shen wrote:
Then "std::move on a pointer definitely doesn't pessimize" is true.
Here I read pessimize as "less efficient".
Well without optimization it certainly is less efficient, because you
get calls to std::move (just compare the code for foo and bar at
http://g
On Sat, Jan 17, 2015 at 4:24 PM, Jonathan Wakely wrote:
> Initializing a pointer from another pointer just copies the value and
> has no way of doing anything different whether the source is an rvalue
> or an lvalue.
Then "std::move on a pointer definitely doesn't pessimize" is true.
Here I read
On 17/01/15 16:08 -0800, Tim Shen wrote:
On Sat, Jan 17, 2015 at 4:06 PM, Tim Shen wrote:
I'm not 100% sure of that, but isn't moving a pointer the same as copying?
You can't move a pointer, you can only copy it.
Rmember all std::move does is cast something to an rvalue reference,
whether th
On Sat, Jan 17, 2015 at 4:06 PM, Tim Shen wrote:
> I'm not 100% sure of that, but isn't moving a pointer the same as copying?
I mean time cost here. By the way, is the rhs pointer still valid or
in an unspecified state?
--
Regards,
Tim Shen
On Fri, Jan 16, 2015 at 4:12 AM, Jonathan Wakely wrote:
> In that case, why bother using a unique_ptr initially, if it will just
> have to allocate a shared_ptr control block later anyway? It's better
> to use make_shared to reduce the number of allocations, isn't it?
Yes you are right, I didn't
On 17/01/15 15:54 -0700, Sandra Loosemore wrote:
On 01/17/2015 03:36 PM, Jonathan Wakely wrote:
On 17/01/15 15:22 -0700, Sandra Loosemore wrote:
[snip snip]
I'm getting a different series of build errors with this patch --
starting with
In file included from
/scratch/sandra/arm-fsf2/src/gcc-ma
On 01/17/2015 03:36 PM, Jonathan Wakely wrote:
On 17/01/15 15:22 -0700, Sandra Loosemore wrote:
[snip snip]
I'm getting a different series of build errors with this patch --
starting with
In file included from
/scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:27:0:
/scr
On 01/17/2015 02:07 PM, Andrew Pinski wrote:
> On Sat, Jan 17, 2015 at 2:02 PM, Andreas Schwab wrote:
>> Andrew Pinski writes:
>>
>>> On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson wrote:
On 01/17/2015 11:07 AM, Andreas Schwab wrote:
> Richard Henderson writes:
>
>> On 01/1
On 17/01/15 15:22 -0700, Sandra Loosemore wrote:
On 01/17/2015 01:23 PM, Jonathan Wakely wrote:
On 17/01/15 12:59 -0700, Sandra Loosemore wrote:
Re:
On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote:
On Fri, 16 Jan 2015, pins...@gmail.com wrote:
On Jan 16, 2015, at 9:57 PM, David Edelsohn
On 01/17/2015 01:23 PM, Jonathan Wakely wrote:
On 17/01/15 12:59 -0700, Sandra Loosemore wrote:
Re:
On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote:
On Fri, 16 Jan 2015, pins...@gmail.com wrote:
On Jan 16, 2015, at 9:57 PM, David Edelsohn
wrote:
This patch has broken bootstrap on AIX
Ma
On Sat, Jan 17, 2015 at 2:02 PM, Andreas Schwab wrote:
> Andrew Pinski writes:
>
>> On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson wrote:
>>> On 01/17/2015 11:07 AM, Andreas Schwab wrote:
Richard Henderson writes:
> On 01/17/2015 01:52 AM, Andreas Schwab wrote:
>> ../../..
Andrew Pinski writes:
> On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson wrote:
>> On 01/17/2015 11:07 AM, Andreas Schwab wrote:
>>> Richard Henderson writes:
>>>
On 01/17/2015 01:52 AM, Andreas Schwab wrote:
> ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type
>>
On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson wrote:
> On 01/17/2015 11:07 AM, Andreas Schwab wrote:
>> Richard Henderson writes:
>>
>>> On 01/17/2015 01:52 AM, Andreas Schwab wrote:
../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name
'ffi_go_closure'
On 01/17/2015 11:07 AM, Andreas Schwab wrote:
> Richard Henderson writes:
>
>> On 01/17/2015 01:52 AM, Andreas Schwab wrote:
>>> ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name
>>> 'ffi_go_closure'
>>> void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure
> Hi,
>
> I updated the patch adding one ChangeLog entry.
> OK for the trunk? Thanks.
OK thanks.
(for my taste the else before return is OK, but I do not mind either way.
Comment updates are definitly welcome)
Honza
>
>
> Index: gcc/ChangeLog
>
I noticed that there two separate documentation entries for -ftracer in
the GCC manual, one of which had an extra sentence but was otherwise
identical to the other. This patch removes the copy without the extra
sentence; I've checked it in as an obvious fix.
-Sandra
2015-01-17 Sandra Loosem
Applied as 'obvious' in revision 219802.
2015-01-17 Paul Thomas
PR fortran/64578
* trans-expr.c (gfc_trans_pointer_assignment): Make sure that
before reinitializing rse, to add the rse.pre to block before
creating 'ptrtemp'.
* trans-intrinsic.c (gfc_conv_associated): Deal w
On 17/01/15 12:59 -0700, Sandra Loosemore wrote:
Re:
On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote:
On Fri, 16 Jan 2015, pins...@gmail.com wrote:
On Jan 16, 2015, at 9:57 PM, David Edelsohn wrote:
This patch has broken bootstrap on AIX
May I mention that this really should have been te
Re:
On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote:
On Fri, 16 Jan 2015, pins...@gmail.com wrote:
> On Jan 16, 2015, at 9:57 PM, David Edelsohn wrote:
>
> This patch has broken bootstrap on AIX
>
> May I mention that this really should have been tested on systems
> other than x86 Linux.
I
On Sat, Jan 17, 2015 at 09:30:07AM -0500, David Edelsohn wrote:
> On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
> wrote:
> > This fixes 29 FAILs.
> >
> > The ld, lwa etc. insns do not encode the low two bits of the offset in
> > the opcode; those have to be zero. For -m64 this seemed to nev
On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> (Waking up an old thread with my 2 cents due to being a little
> behind on reading...)
>
> On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> > On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > > > That's already what it
Richard Henderson writes:
> On 01/17/2015 01:52 AM, Andreas Schwab wrote:
>> ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name
>> 'ffi_go_closure'
>> void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl)
>>
On 01/17/2015 01:52 AM, Andreas Schwab wrote:
> ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name
> 'ffi_go_closure'
> void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl)
> ^
> ../../../libgo/go/re
Uros Bizjak writes:
> On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth
> wrote:
>
>>> The patch removes EBX usage from asm code used in libgcc/crtstuff.c
>>> It is safe now, but potentially buggy when glibc is rebuild with GCC
>>> 5.0 as EBX is not GOT register any more.
>>>
>>> x86 bootstrap, make
On Sat, Jan 17, 2015 at 12:19 AM, Ian Lance Taylor wrote:
>> You should also revert alpha specific change to
>> libgo/go/testing/quick/quick_test.go, please see [1] and [2].
>>
>> [1] https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00038.html
>> [2] https://gcc.gnu.org/ml/gcc-patches/2013-03/msg000
Dear All,
Steve Kargl has pointed out to me that the attachment was a null
attachment. As is well known, these are the Swiss Army knife of
patches and will fix anything. In fact, this patch was already posted
long while since with the PR. However, since I am now in a slightly
more pedestrian mood
(Waking up an old thread with my 2 cents due to being a little
behind on reading...)
On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > > That's already what it does though, did you mean the opposite? Or did you
> > > mean to write "combine
Committed with the patch for PR61275 as revision 219801. Also fixes
PR55932 for which a testcase has been added.
Will follow with a commit to 4.9 during the week.
Cheers
Paul
On 16 January 2015 at 12:30, Andre Vehreschild wrote:
> Hi all,
>
> please find attached a fix for pr60357. This patch
On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth
wrote:
>> The patch removes EBX usage from asm code used in libgcc/crtstuff.c
>> It is safe now, but potentially buggy when glibc is rebuild with GCC
>> 5.0 as EBX is not GOT register any more.
>>
>> x86 bootstrap, make check passed.
>>
>> Is it ok?
>>
Dear Andre,
Don't worry about the lack of a laptop. I am on to it :-)
Paul
On 17 January 2015 at 16:14, Andre Vehreschild wrote:
> Dear Paul,
>
> Setting _Len to one by default should be quite simple. When I remember
> correctly, then there is only one place where the current code sets it to
Hi Evgeny,
> The patch removes EBX usage from asm code used in libgcc/crtstuff.c
> It is safe now, but potentially buggy when glibc is rebuild with GCC
> 5.0 as EBX is not GOT register any more.
>
> x86 bootstrap, make check passed.
>
> Is it ok?
>
> Evgeny
>
> 2014-12-28 Evgeny Stupachenko
>
>
On Friday 2015-01-09 15:24, Andreas Tobler wrote:
> Committed. (r219388) Thanks.
Can this also go into the GCC 4.9 branch? That is (and will be
for a while) the latest release stream and the patch is pretty
much isolated to FreeBSD.
Gerald
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
wrote:
> These tests test that no 64-bit etc. insns are used when the compiler
> options say they should not be used. But -mpowerpc64 says that they
> _should_ be used. So skip the tests in that case.
>
>
> 2015-01-16 Segher Boessenkool
>
>
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
wrote:
> "long long" takes one register exactly when TARGET_POWERPC64, which
> is _ARCH_PPC64 in preprocessor macros; not just for 64-bit ABIs.
>
>
> 2015-01-16 Segher Boessenkool
>
> gcc/testsuite/
> * gcc.dg/20020919-1.c: Use _ARCH_P
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
wrote:
> This fixes 3 FAILs.
>
> The generic emit_stack_probe (that is used for probe_stack patterns) uses
> word_mode, which won't fly for -m32 -mpowerpc64. Use probe_stack_address
> instead, and create the MEM by hand.
>
>
> 2015-01-16 Segher
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
wrote:
> This fixes 26 FAILs.
>
>
> 2015-01-16 Segher Boessenkool
>
> gcc/
> * config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Use TARGET_32BIT
> to test for 32-bit ABIs, not !TARGET_POWERPC64.
Okay.
Thanks, David
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
wrote:
> This fixes 29 FAILs.
>
> The ld, lwa etc. insns do not encode the low two bits of the offset in
> the opcode; those have to be zero. For -m64 this seemed to never matter,
> datums are always aligned; but for -m32 -mpowerpc64 you can get
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
wrote:
> This fixes 135 FAILs.
>
>
> 2015-01-16 Segher Boessenkool
>
> gcc/
> * config/rs6000/rs6000.c (rs6000_parallel_return): New function.
> (rs6000_function_value): Use it. Handle SCmode and TCmode as well,
> for
On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote:
On Fri, 16 Jan 2015, pins...@gmail.com wrote:
> On Jan 16, 2015, at 9:57 PM, David Edelsohn wrote:
>
> This patch has broken bootstrap on AIX
>
> May I mention that this really should have been tested on systems
> other than x86 Linux.
It also
Oleg Endo wrote:
> Kaz, could you please test the patch on your sh4-linux setup and report
> your findings? Even though it's a bit late, I'd like to get this in for
> GCC 5, if it doesn't break too many things.
Looks wrong code problem for tls and atomic constructs.
Here is the result of compare
Cancel that - It should be multiplies by kind, shouldn't it ? :-) OK,
string length it is. We will probably have to set _len = 1 for other
dynamic types, though, so that the pointer arising from an array
reference is base_address + _len*vptr->size*index
Cheers
Paul
On 17 January 2015 at 13:44, P
Dear Andre,
I am open to either - what do the others think?
The reason why I am for differentiating between unlimited_polymorphic
objects and the deferred length character arrays is because of the
difference in the way in which arrays are accessed. The former uses
pointer arithmetic and the latte
On Sat, Jan 17, 2015 at 12:16:17PM +0100, Gerald Pfeifer wrote:
> Also, can you use the actual link only once, for the first reference?
> Otherwise if this changes, we'd have to edit lots of links, and that
> is rather common practice that way.
>
> -Bugs in the GNU OpenMP implementation should be
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 rs6000 backend, but it occurs to
>me
>> > that cprop also has a bug here.
I must have made this weeks ago, committed now.
Gerald
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.57
diff -u -r1.57 changes.html
--- changes.html8 Jan 2015 16:50:23 -0
Hi Yury,
On Friday 2015-01-16 12:18, Yury Gribov wrote:
> This is a wwwdocs patch to changes.html to announce -freport-bug flag.
how about the following variation (which I have not committed yet)?
Index: changes.html
===
@@ -514,6 +
On Saturday 2014-11-15 00:52, Julian Brown wrote:
> Thanks -- here's a new version of the patch, which incorporates David
> Malcolm's new backronym for libgomp, and edits the above files also.
+@uref{http://www.openacc.org/, OpenACC specification v2.0}, section
By the way, here and in other cases
On Monday 2015-01-12 21:04, Jakub Jelinek wrote:
> This patch changes the libgcj*.pc installed filename to match the new GCC
> versioning scheme.
Cool, as I said in August
https://gcc.gnu.org/ml/gcc/2014-08/msg00250.html
and Jeff confirmed in November
https://gcc.gnu.org/ml/gcc/2014-11/msg0032
Dear Andre,
Perhaps, rather than calling the new component _len, we should call it
_mem_size or some such?
Cheers
Paul
On 9 January 2015 at 11:52, Andre Vehreschild wrote:
> Hi all, hi Paul,
>
> I started to implement the changes requested below, but I stumbled over an
> oddity:
>
> For a defe
Dear All,
The attached patch fixes the confusion between substrings of character
associate-names and scalars being misused as arrays.
It is sufficiently obvious and has been tested by Dominique that I
will commit it later today if there are no opinions to the contrary.
I will now turn my attenti
On 17 January 2015 at 06:45, Hans-Peter Nilsson wrote:
> On Fri, 16 Jan 2015, pins...@gmail.com wrote:
>> > On Jan 16, 2015, at 9:57 PM, David Edelsohn wrote:
>> >
>> > This patch has broken bootstrap on AIX
>> >
>> > May I mention that this really should have been tested on systems
>> > other th
../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name
'ffi_go_closure'
void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl)
^
../../../libgo/go/reflect/makefunc_ffi_c.c:86:48: error: unknown type name
Hi,
I updated the patch adding one ChangeLog entry.
OK for the trunk? Thanks.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 219297)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2015-01-17 Felix Yan
> Date: Fri, 16 Jan 2015 16:39:20 -0500
> From: DJ Delorie
> CC: ktiet...@googlemail.com, gcc-patches@gcc.gnu.org,
> gdb-patc...@sourceware.org
>
>
> > Thanks. Do I need to hear from someone else approving this, or can I
> > go ahead and commit?
>
> Go ahead and commit.
Thanks.
Last-
These tests test that no 64-bit etc. insns are used when the compiler
options say they should not be used. But -mpowerpc64 says that they
_should_ be used. So skip the tests in that case.
2015-01-16 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/ppc-fpconv-4.c: Skip for -mpo
This fixes 3 FAILs.
The generic emit_stack_probe (that is used for probe_stack patterns) uses
word_mode, which won't fly for -m32 -mpowerpc64. Use probe_stack_address
instead, and create the MEM by hand.
2015-01-16 Segher Boessenkool
gcc/
* config/rs6000/rs6000.md (probe_stack): Del
This fixes 26 FAILs.
2015-01-16 Segher Boessenkool
gcc/
* config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Use TARGET_32BIT
to test for 32-bit ABIs, not !TARGET_POWERPC64.
---
gcc/config/rs6000/rs6000.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/
"long long" takes one register exactly when TARGET_POWERPC64, which
is _ARCH_PPC64 in preprocessor macros; not just for 64-bit ABIs.
2015-01-16 Segher Boessenkool
gcc/testsuite/
* gcc.dg/20020919-1.c: Use _ARCH_PPC64 to test for -mpowerpc64.
---
gcc/testsuite/gcc.dg/20020919-1.c | 2
This fixes 29 FAILs.
The ld, lwa etc. insns do not encode the low two bits of the offset in
the opcode; those have to be zero. For -m64 this seemed to never matter,
datums are always aligned; but for -m32 -mpowerpc64 you can get symbols
that are not sufficiently aligned. So check for that.
[ Hr
This fixes 135 FAILs.
2015-01-16 Segher Boessenkool
gcc/
* config/rs6000/rs6000.c (rs6000_parallel_return): New function.
(rs6000_function_value): Use it. Handle SCmode and TCmode as well,
for TARGET_32BIT && TARGET_POWERPC64. Fix another BITS_PER_WORD
snafu.
With this, almost all of the testsuite passes for -m32 -mpowerpc64
as for -m32; of the remaining failures, most are testsuite problems.
There also are a few(?) problems remaining that the testsuite does
not test for, alas.
Tested on powerpc64-linux, -m32,-m32/-mpowerpc64,-m64,-m64/-mlra.
Are the
On Sat, 17 Jan 2015 07:41:51 +0100, Jakub Jelinek wrote:
> > gcc/ChangeLog
> > * dwarf2out.c (gen_producer_string): Ignore also OPT_fpreprocessed.
>
> Ok for trunk, thanks.
Checked in: 219797
Jan
66 matches
Mail list logo