We were crashing in lvalue_kind because we were trying to test whether a
NULL type was a METHOD_TYPE. The reason we would care whether the type
is a METHOD_TYPE is lost to history; the change was there in the first
version of that function that appeared in 1995.
Tested x86_64-pc-linux-gnu, ap
From: David Miller
Date: Tue, 05 Feb 2013 18:18:39 -0500 (EST)
> The only other alternative I can see would be to get everything in
> var-tracking.c and the other subsystems it uses to do leaf register
> remapping, but that seems completely like the wrong way to handle
> this.
Following up to my
When we start processing a function and find that it was declared
previously, we use the old declaration. In that case we should use the
old version of the return type, as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3589139ea249533cc5ebb5ef9c38d72fc159f6fd
Author: Jason Merrill
In this case, when we see the explicit template arguments for test and
go to substitute them into the type of sfinae_base::test, we were
recording that we wanted to check access to sfinae_base::make in the
context of is_printable, but then by the time we got around to checking
it we had pushed
I got confused about the code where the heap scavenger starts
forcegchelper in libgo. This patch corrects the argument passed in.
This should fix the segmentation violation reported in PR 56172.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu, where it
is less important because the c
This patch to the top level configure script avoids building libgo on
some systems where it is known to not work. Bootstrapped on
x86_64-unknown-linux-gnu, where it does work. Committed to mainline.
This is PR 55969.
Ian
2013-02-05 Ian Lance Taylor
PR go/55969
* configure.a
This patch to libgo uses DejaGNU when testing a cross-compiler. The
shell script is simpler but only works for a native configuration.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline. This should fix PR 56017.
Ian
diff -r 27e1a46c9cc2 libgo/Makefile.am
--- a
> Date: Mon, 7 Jan 2013 12:49:14 -1000 (TAHT)
> From: Gerald Pfeifer
>
> On Sun, 7 Oct 2012, Mark Kettenis wrote:
> > Adds the necessary support bits to libgcc. All other mainstream
> > i386/amd64 targets already have this.
> >
> > Tested on i386-unknown-openbsd5.2 and x86_64-unknown-openbsd5.2
On Thu, Jan 3, 2013 at 1:26 AM, Uros Bizjak wrote:
> Hello!
>
>> I've committed a patch to upgrade libgo to the current version of the
>> master Go library. As usual, this mail message only includes the
>> changes to files that are specific to gccgo. Bootstrapped and ran Go
>> testsuite on x86_6
On Wed, Jan 30, 2013 at 7:06 PM, Michael Meissner
wrote:
> This is the last of the merge insn patches. It merges the power6x movdi with
> the normal floating point movdi.
>
> 2013-01-30 Michael Meissner
>
> * config/rs6000/rs6000.md (movdi_mfpgpr): Delete, combine with
> movdi_
On Tue, Feb 05, 2013 at 09:30:48AM -0500, Jack Howarth wrote:
>Once the requested patch to extend qsorting of init priorities to
> destructors...
>
> http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00154.html
>
> is committed, the following patch enables SUPPORTS_INIT_PRIORITY on darwin.
> The
On Wed, Jan 30, 2013 at 5:50 PM, Michael Meissner
wrote:
> This patch like the previous 2 pages combines the decimal and binary floating
> point moves, this time for 128-bit floating point.
>
> In doing this patch, I discovered that I left out the code in the previous
> patch to enable the wg cons
On Wed, Jan 30, 2013 at 3:48 PM, Michael Meissner
wrote:
> This patch builds upon the patch in:
> http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01457.html
>
> It merges the DFmode and DDmode moves into one pattern. In addition, it
> merges
> the -mmfpgpr code with the normal floating point moves,
On Wed, Jan 30, 2013 at 1:36 PM, Michael Meissner
wrote:
> This is a series of patches taken from my power8 work meant for inclusion
> against GCC 4.9 when 4.8 is branched, and stage1 of 4.9 opens up again. They
> could be installed in 4.8 at the discretion of David.
>
> This patch merges togethe
cpplib-4.7.2.eo.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Esperanto team of translators. The file is available at:
http://translationproject.org/latest/cpplib/eo.po
(This file, 'cpplib-4.7.2.eo.po
Hi,
Following the discussion about "disable peeling" [1] a few weeks ago,
it turned out that the vectorizer cost model needed some
implementation for ARM.
The attached patch implements arm_builtin_vectorization_cost and
arm_add_stmt_cost, providing default costs when aligned and unaligned
loads/s
cpplib-4.7.2.eo.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Esperanto team of translators. The file is available at:
http://translationproject.org/latest/cpplib/eo.po
(This file, 'cpplib-4.7.2.eo.po
Hi Dodji,
On 02/04/2013 04:53 PM, Dodji Seketeli wrote:
Hello,
Since commit r195676[1], it looks like
libstdc++-v3/src/c++11/hashtable_c++0x.cc is missing an explicit
instantiation for std::lower_bound. This leads to libstdc++.so having
the symbol for that (missing) instantiation be undefined,
On Tue, Feb 05, 2013 at 04:27:15PM +0100, Jan Hubicka wrote:
> I managed to get an accidental commit on those two testcases without an
> ChangeLog entry.
> I just commit the missing ChangeLog and the following patch that should make
> them pass.
>
> just in a case you wonder what are the tests a
Jakub Jelinek writes:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2013-02-05 Jakub Jelinek
>
> PR sanitizer/55374
> * config/gnu-user.h (LIBTSAN_EARLY_SPEC): Define.
> (STATIC_LIBTSAN_LIBS): Likewise.
> * gcc.c (ADD_STATIC_LIBTSAN_LIBS, L
On Tue, 5 Feb 2013, Jakub Jelinek wrote:
> Hi!
>
> Got a bugreport that gcc plugins can't be compiled with -std=c++11,
> seems the reason why not is badly named bitfield that is never used
> anyway. From what I've seen in CVS history, thread_local_flag
> was first removed by
> 2005-06-30 Steven
Thanks for the confirmation that the -g issue is orthogonal. I did
start to try to address it but got pulled away by some other things
for awhile. I'll see if I can take another stab at it.
In the meantime, could one of the global maintainers take a look at
the patch? I don't want it to get too st
Hi!
Got a bugreport that gcc plugins can't be compiled with -std=c++11,
seems the reason why not is badly named bitfield that is never used
anyway. From what I've seen in CVS history, thread_local_flag
was first removed by
2005-06-30 Steven Bosscher
* tree.h (struct tree_decl): New fi
On Tue, 5 Feb 2013, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled on ppc64, because the stdarg pass
> didn't figure out that va_list was escaping.
> The problem was that we've processed the
> # z.2_31 = PHI
> stmt was processed before processing z.2_27 and z.2_24 assignmen
Hi!
This patch adjusts -fsanitize=thread linking behavior to match that
of -fsanitize=address, in that -ltsan is also linked early on the link
command line, -ldl -lpthread is added on Linux, etc.
Additionally, for -nostdlib or -nodefaultlibs this patch doesn't
add -lasan nor -ltsan nor its depende
Hi!
The following testcase is miscompiled on ppc64, because the stdarg pass
didn't figure out that va_list was escaping.
The problem was that we've processed the
# z.2_31 = PHI
stmt was processed before processing z.2_27 and z.2_24 assignments,
so neither of them was in va_list_escape_vars at tha
Hi,
I managed to get an accidental commit on those two testcases without an
ChangeLog entry.
I just commit the missing ChangeLog and the following patch that should make
them pass.
just in a case you wonder what are the tests about. I disabled iteration on
early inliner
that makes it to mis som
This re-does the fix for PR53185 in a less intrusive way, allowing
both strided load vectorization and peeling for alignment. Testing
on my local machine tells me that this fix results in a 3% speedup
of rnflow.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-02-05
Once the requested patch to extend qsorting of init priorities to
destructors...
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00154.html
is committed, the following patch enables SUPPORTS_INIT_PRIORITY on darwin. The
testsuite regression results are...
http://gcc.gnu.org/ml/gcc-testresults/2
Ping?
Thanks,
Kyrill
> -Original Message-
> From: Kyrylo Tkachov [mailto:kyrylo.tkac...@arm.com]
> Sent: 07 January 2013 10:35
> To: gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakrishnan; Richard Earnshaw
> Subject: RE: [PATCH][ARM][1/3] Add vectorization support for rounding
> functions
>
Ping?
Thanks,
Kyrill
> -Original Message-
> From: Kyrylo Tkachov [mailto:kyrylo.tkac...@arm.com]
> Sent: 07 January 2013 10:35
> To: Kyrylo Tkachov; gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakrishnan; Richard Earnshaw
> Subject: RE: [PATCH][ARM][2/3] Add vectorization support for rounding
On 02/05/13 07:43, Ye Joey wrote:
Ramana,
This issue also impacts ldrexh/ldrexb, as assembler doesn't accept
ldrexh r1, [r0, #0]. May it be backported to 4.7 by now?
Thanks - Joey
Ok by me unless RM's object. It's been on trunk long enough and hasn't
caused any issues that I'm aware of.
Th
On 02/04/2013 10:33 PM, David Edelsohn wrote:
> 2013-02-04 Michael Haubenwallner
>
> Accept all flags that enable aix runtime linking to change the
> library search order. Also there is a disabling flag.
> This patch is okay, and I agree that it should use strncmp.
Updated to use
On 05/02/13 11:12, Jakub Jelinek wrote:
> On Tue, Feb 05, 2013 at 11:01:22AM +0100, Tom de Vries wrote:
>> I'm not sure I understand your comment.
>>
>> The BLOCK_FOR_INSN of the note was NULL. The NOTE_BASIC_BLOCK of the note was
>> correct. Are you saying that the BLOCK_FOR_INSN should not have b
On Tue, Feb 05, 2013 at 11:01:22AM +0100, Tom de Vries wrote:
> I'm not sure I understand your comment.
>
> The BLOCK_FOR_INSN of the note was NULL. The NOTE_BASIC_BLOCK of the note was
> correct. Are you saying that the BLOCK_FOR_INSN should not have been NULL?
Yeah, I mean the following invaria
* ping *
http://gcc.gnu.org/ml/fortran/2013-01/msg00223.html
Tobias Burnus:
As promised: A patch for the "regression" PR54339. I am sure there is
room for improvement :-)
Everyone: Please feel free to comment on the current documentation,
http://gcc.gnu.org/onlinedocs/gfortran/ , and on the a
On 05/02/13 10:50, Jakub Jelinek wrote:
> On Tue, Feb 05, 2013 at 10:41:51AM +0100, Tom de Vries wrote:
>> On 05/02/13 10:02, Eric Botcazou wrote:
The problem is that in delete_insn, while deleting an undeletable label (in
other words, transforming a label into a INSN_NOTE_DELETED_LABEL):
On Tue, Feb 05, 2013 at 10:41:51AM +0100, Tom de Vries wrote:
> On 05/02/13 10:02, Eric Botcazou wrote:
> >> The problem is that in delete_insn, while deleting an undeletable label (in
> >> other words, transforming a label into a INSN_NOTE_DELETED_LABEL):
> >> - we try to find the bb of a NOTE_INS
Eric,
thanks for the review.
On 05/02/13 10:02, Eric Botcazou wrote:
>> The problem is that in delete_insn, while deleting an undeletable label (in
>> other words, transforming a label into a INSN_NOTE_DELETED_LABEL):
>> - we try to find the bb of a NOTE_INSN_BASIC_BLOCK following the label using
On Mon, Feb 4, 2013 at 9:43 PM, Zhiming Wang wrote:
> Hi there,
>
> When reading through http://gcc.gnu.org/install/configure.html configuration
> options, I spotted an inconsistency regarding Graphite loop optimization:
>
> "
> --with-ppl=pathname
> --with-ppl-include=pathname
> --with-ppl-lib=p
> The problem is that in delete_insn, while deleting an undeletable label (in
> other words, transforming a label into a INSN_NOTE_DELETED_LABEL):
> - we try to find the bb of a NOTE_INSN_BASIC_BLOCK following the label using
> BLOCK_FOR_INSN (which is NULL) instead of NOTE_BASIC_BLOCK (which is no
On Tue, Feb 05, 2013 at 09:37:29AM +0100, Eric Botcazou wrote:
> Tested on x86_64-suse-linux, OK for the mainline?
>
>
> 2013-02-05 Eric Botcazou
>
> PR sanitizer/55374
> * config/gnu-user.h (LIBASAN_EARLY_SPEC): Add missing guard.
Yes, thanks.
> Index: config/gnu-user.h
> =
> 2013-01-22 Jakub Jelinek
>
> PR sanitizer/55374
> * gcc.c (LIBASAN_SPEC): Define just to ADD_STATIC_LIBASAN_LIBS if
> LIBASAN_EARLY_SPEC is defined.
> (LIBASAN_EARLY_SPEC): Define to empty string if not already defined.
> (LINK_COMMAND_SPEC): Add LIBASAN_EARLY_SP
45 matches
Mail list logo
