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
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
This fixes 135 FAILs.
2015-01-16 Segher Boessenkool seg...@kernel.crashing.org
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
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.
[
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 seg...@kernel.crashing.org
gcc/testsuite/
* gcc.dg/20020919-1.c: Use _ARCH_PPC64 to test for -mpowerpc64.
---
This fixes 26 FAILs.
2015-01-16 Segher Boessenkool seg...@kernel.crashing.org
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
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 seg...@kernel.crashing.org
gcc/testsuite/
*
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 seg...@kernel.crashing.org
gcc/
*
Date: Fri, 16 Jan 2015 16:39:20 -0500
From: DJ Delorie d...@redhat.com
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.
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
../../../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
On 17 January 2015 at 06:45, Hans-Peter Nilsson h...@bitrange.com wrote:
On Fri, 16 Jan 2015, pins...@gmail.com wrote:
On Jan 16, 2015, at 9:57 PM, David Edelsohn dje@gmail.com wrote:
This patch has broken bootstrap on AIX
May I mention that this really should have been tested on
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
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 ve...@gmx.de wrote:
Hi all, hi Paul,
I started to implement the changes requested below, but I stumbled over an
oddity:
For
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
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,
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
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
On January 17, 2015 1:37:12 AM CET, Alan Modra amo...@gmail.com 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
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
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
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,
Oleg Endo oleg.e...@t-online.de 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
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 dje@gmail.com wrote:
This patch has broken bootstrap on AIX
May I mention that this really should have been tested on systems
other than x86
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
This fixes 135 FAILs.
2015-01-16 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* config/rs6000/rs6000.c (rs6000_parallel_return): New function.
(rs6000_function_value): Use it.
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
seg...@kernel.crashing.org 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
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
This fixes 26 FAILs.
2015-01-16 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Use TARGET_32BIT
to test for 32-bit ABIs, not
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
seg...@kernel.crashing.org 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.
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
seg...@kernel.crashing.org 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 seg...@kernel.crashing.org
gcc/testsuite/
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
seg...@kernel.crashing.org 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
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
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
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 ve...@gmx.de 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
On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth
r...@cebitec.uni-bielefeld.de 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
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 ve...@gmx.de wrote:
Hi all,
please find attached a fix for pr60357.
(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
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
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)
^
Richard Henderson r...@redhat.com 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 Sat, Jan 17, 2015 at 09:30:07AM -0500, David Edelsohn wrote:
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool
seg...@kernel.crashing.org 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
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 dje@gmail.com wrote:
This patch has broken bootstrap on AIX
May I mention that this really should have been tested on systems
other than
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 does
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
On 01/17/2015 11:07 AM, Andreas Schwab wrote:
Richard Henderson r...@redhat.com 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,
On 01/17/2015 02:07 PM, Andrew Pinski wrote:
On Sat, Jan 17, 2015 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Andrew Pinski pins...@gmail.com writes:
On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson r...@redhat.com wrote:
On 01/17/2015 11:07 AM, Andreas Schwab wrote:
Richard
On Sat, Jan 17, 2015 at 12:19 AM, Ian Lance Taylor i...@golang.org 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]
Uros Bizjak ubiz...@gmail.com writes:
On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth
r...@cebitec.uni-bielefeld.de 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
Andrew Pinski pins...@gmail.com writes:
On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson r...@redhat.com wrote:
On 01/17/2015 11:07 AM, Andreas Schwab wrote:
Richard Henderson r...@redhat.com writes:
On 01/17/2015 01:52 AM, Andreas Schwab wrote:
On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson r...@redhat.com wrote:
On 01/17/2015 11:07 AM, Andreas Schwab wrote:
Richard Henderson r...@redhat.com writes:
On 01/17/2015 01:52 AM, Andreas Schwab wrote:
../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name
On Sat, Jan 17, 2015 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Andrew Pinski pins...@gmail.com writes:
On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson r...@redhat.com wrote:
On 01/17/2015 11:07 AM, Andreas Schwab wrote:
Richard Henderson r...@redhat.com writes:
On
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 dje@gmail.com
wrote:
This patch has broken
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 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 dje@gmail.com wrote:
This patch has broken bootstrap on AIX
May I mention that this really
Applied as 'obvious' in revision 219802.
2015-01-17 Paul Thomas pa...@gcc.gnu.org
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
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
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:
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
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
On Fri, Jan 16, 2015 at 4:12 AM, Jonathan Wakely jwak...@redhat.com 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
On Sat, Jan 17, 2015 at 4:06 PM, Tim Shen tims...@google.com 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 17/01/15 16:08 -0800, Tim Shen wrote:
On Sat, Jan 17, 2015 at 4:06 PM, Tim Shen tims...@google.com 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
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
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 tims...@google.com
Date: Sat Jan 17 19:34:14 2015 -0800
On Sat, Jan 17, 2015 at 4:24 PM, Jonathan Wakely jwak...@redhat.com 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
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
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 bits/c++config.h
#include atomic
#include chrono
66 matches
Mail list logo
