Hi,
I back ported r193425 from TRUNK to GCC ARM-Embedded-4_7 branch as r193495.
Thanks
Backport from mainline r193425
2012-11-12 Bin Cheng
* gcse.c (struct bb_data): Add new fields, old_pressure, live_in
and backup.
(get_regno_pressure_class): Add proto
Hi all,
this commit: 193486 broke bootstrap on targets which do not have
HAVE_GNU_INDIRECT_FUNCTION.
Ok to commit?
TIA,
Andreas
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 193495)
+++ config/i386/i386.c (workin
On Tue, Nov 13, 2012 at 11:13:03AM -0800, Wei Mi wrote:
> I migrate a test in the third category. Please help to check whether
> it is ok. Then I will migrate the left. The files added are as follows
> and attached. (Please forgive I use -fasan in asan.exp because I use
> an old repository to try t
On 2012.11.14 at 00:48 +0100, Paolo Bonzini wrote:
> Il 14/11/2012 00:43, H.J. Lu ha scritto:
> > This works.
>
> Ok, then please test remove install-sh and friends and do
> autoconf/automake again. If it works, commit the result (I don't care
> if you make it one or two commits).
>
> Then, wait
On 2012.11.14 at 10:57 +0100, Markus Trippelsdorf wrote:
> On 2012.11.14 at 00:48 +0100, Paolo Bonzini wrote:
> > Il 14/11/2012 00:43, H.J. Lu ha scritto:
> > > This works.
> >
> > Ok, then please test remove install-sh and friends and do
> > autoconf/automake again. If it works, commit the resul
On Wed, Nov 14, 2012 at 10:22 AM, Gopalasubramanian, Ganesh
wrote:
>> sseshuf replaces sselog in some insn patterns, but should be handled in the
>> same way in *existing* .md files.
>
> Modifications done as per the comments.
> 1. Sseshuf is added along with sselog in existing md files.
> 2. ss
Hello!
> this commit: 193486 broke bootstrap on targets which do not have
> HAVE_GNU_INDIRECT_FUNCTION.
> Ok to commit?
OK, with appropriate ChangeLog entry and if bootstrapped correctly on
both, IFUNC and non-IFUNC capable target.
Thanks,
Uros.
Hi,
On 11/13/2012 10:40 PM, François Dumont wrote:
2012-11-13 François Dumont
* include/bits/hashtable_policy.h (_Prime_rehash_policy): Remove
automatic shrink.
(_Prime_rehash_policy::_M_bkt_for_elements): Do not call
_M_next_bkt anymore.
(_Prime_rehash_policy::_M_next_bkt
Hi!
And here is an updated patch with start of the symbolizer (just showing
where it can be hooked, the symbolizer returns the output text unmodified right
now). Writing an initial native only version shouldn't be that hard,
I guess one will need something like:
set addr2line_name [find_binutil
On Mon, Nov 12, 2012 at 10:59 AM, H.J. Lu wrote:
> On Mon, Nov 12, 2012 at 3:47 AM, Dodji Seketeli wrote:
>> Diego Novillo writes:
>>
>>> On 2012-11-02 16:10 , Dodji Seketeli wrote:
>>>
* configure.ac: Add libsanitizer to target_libraries.
* Makefile.def: Ditto.
Some changes had been added to gcc/ChangeLog and gcc/testsuite/Changelog
when they should have been recorded in the gcc/Changelog.aarch64 and
gcc/testsuite/Changelog.aarch64 files instead.
Committed as obvious.
Cheers,
Ian
On Wed, Nov 14, 2012 at 3:11 AM, H.J. Lu wrote:
> On Mon, Nov 12, 2012 at 10:59 AM, H.J. Lu wrote:
>> On Mon, Nov 12, 2012 at 3:47 AM, Dodji Seketeli wrote:
>>> Diego Novillo writes:
>>>
On 2012-11-02 16:10 , Dodji Seketeli wrote:
> * configure.ac: Add libsanitizer to tar
Diego Novillo writes:
> On Tue, Nov 13, 2012 at 12:07 AM, David Miller wrote:
>>
>> This has broken the build on every Linux target that hasn't added
>> the necessary cpu specific code to asan_linux.cc
>
> This should be fixed by Dodji's recent patch. ASAN is not currently
> ported to any targe
On Tue, Nov 13, 2012 at 3:48 PM, Paolo Bonzini wrote:
> Il 14/11/2012 00:43, H.J. Lu ha scritto:
>> This works.
>
> Ok, then please test remove install-sh and friends and do
> autoconf/automake again. If it works, commit the result (I don't care
> if you make it one or two commits).
>
> Then, wai
"H.J. Lu" writes:
> diff --git a/libsanitizer/asan/asan_linux.cc b/libsanitizer/asan/asan_linux.cc
> index ea7ee9e..5c52ddc 100644
> --- a/libsanitizer/asan/asan_linux.cc
> +++ b/libsanitizer/asan/asan_linux.cc
> @@ -1,5 +1,7 @@
> //===-- asan_linux.cc
>
On Wed, Nov 14, 2012 at 4:36 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>> diff --git a/libsanitizer/asan/asan_linux.cc
>> b/libsanitizer/asan/asan_linux.cc
>> index ea7ee9e..5c52ddc 100644
>> --- a/libsanitizer/asan/asan_linux.cc
>> +++ b/libsanitizer/asan/asan_linux.cc
>> @@ -1,5 +1,7 @@
>>
"H.J. Lu" writes:
>> I don't think removing this code is desirable. As discussed, there
>> needs to be one of the libsanitizer maintainers who takes care of
>> porting changes from the GCC side to upstream and importing upstream, as
>> Ian does for libgo.
>
> I think all changes should go upstre
On Wed, Nov 14, 2012 at 4:44 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>>> I don't think removing this code is desirable. As discussed, there
>>> needs to be one of the libsanitizer maintainers who takes care of
>>> porting changes from the GCC side to upstream and importing upstream, as
>>>
"H.J. Lu" writes:
>>> I think all changes should go upstream first. It was a mistake
>>> to check sparc changes into GCC tree.
>>
>> I disagree, as do others: it is undesirable for gcc maintainers to have
>> to interact with many different upstream communities to get their
>> changes in. This i
On Wed, Nov 14, 2012 at 5:01 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
I think all changes should go upstream first. It was a mistake
to check sparc changes into GCC tree.
>>>
>>> I disagree, as do others: it is undesirable for gcc maintainers to have
>>> to interact with many diffe
"H.J. Lu" writes:
> We don't have a maintainer is a problem, not go upstream first.
Agreed. I've no idea if the SC appointed one when it accepted
libsanitizer etc. into GCC.
> I have a patch pending to enable mulltib. But libsanitizer doesn't
> work on x32 and it doesn't cause bootstrap probl
Hi,
On Tue, Nov 13, 2012 at 01:08:56PM -0800, Ian Lance Taylor wrote:
> On Tue, Nov 13, 2012 at 9:03 AM, Martin Jambor wrote:
>
> > Index: src/gcc/ipa-cp.c
> > ===
> > --- src.orig/gcc/ipa-cp.c
> > +++ src/gcc/ipa-cp.c
> > @@ -1276,
On Wed, Nov 14, 2012 at 04:26:09AM -0800, H.J. Lu wrote:
> 2012-11-14 H.J. Lu
>
> * Copied from llvm at revision 167890.
>
> diff --git a/libsanitizer/asan/asan_allocator.cc
> b/libsanitizer/asan/asan_allocator.cc
> index 3a92802..de37137 100644
> --- a/libsanitizer/asan/asan_allocator.
David Miller writes:
> From: Diego Novillo
> Date: Tue, 13 Nov 2012 11:21:59 -0500
>
>> On Tue, Nov 13, 2012 at 12:07 AM, David Miller wrote:
>>>
>>> This has broken the build on every Linux target that hasn't added
>>> the necessary cpu specific code to asan_linux.cc
>>
>> This should be fixe
On Wed, Nov 14, 2012 at 5:25 AM, Jakub Jelinek wrote:
> On Wed, Nov 14, 2012 at 04:26:09AM -0800, H.J. Lu wrote:
>> 2012-11-14 H.J. Lu
>>
>> * Copied from llvm at revision 167890.
>>
>> diff --git a/libsanitizer/asan/asan_allocator.cc
>> b/libsanitizer/asan/asan_allocator.cc
>> index 3a9
On 13/11/12 22:41, Andrew Pinski wrote:
On Tue, Nov 13, 2012 at 2:31 PM, Ramana Radhakrishnan
wrote:
On 13 Nov 2012, at 21:18, Konstantin Serebryany
wrote:
On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo wrote:
On Tue, Nov 13, 2012 at 12:07 AM, David Miller wrote:
This has broken the
Hi all,
This patch adds support for the vrint family of instructions in aarch32 (the
32-bit execution state in ARMv8).
These are rounding instructions that can be used to implement round to
integral functions from the math library such as:
trunc, ceil, round, floor, nearbyint, rint. This patch imp
Hi all,
This patch adds the new tests for the vrint instructions in aarch32.
It also adds an effective target check to see if we support an ARMv8 VFP and
an add_options
procedure for adding the required options to a testcase if we do.
Ok for trunk?
Thanks,
Kyrill
gcc/testsuite/ChangeLog
2012-1
Sorry, the ChangeLog entry for vfp.md in the end should say:
(2): New pattern.
Instead of
(2): New pattern.
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Kyrylo Tkachov
Sent: 14 November 2012 13:52
To: gcc-patches@gcc.gnu.org
The attached patch assumes that mach_override/mach_override.h
and mach_override/mach_override.c has been imported by the libsanitizer
maintainers for use by darwin. The patch adds darwin to the supported
target list in configure.tgt and defines USING_MACH_OVERRIDE for darwin
in configure.ac. The
Hi Jakub,
I looked through your patch that looks good enough although it likely
must be improved to get better vectorization for AVX-2. One general
issue is that you introduced a new pass to undo if-conversion leading
to one restriction on if-conversion that prohibited to chain the
conditions:
/*
Jack Howarth writes:
> Index: libsanitizer/configure.tgt
> ===
> --- libsanitizer/configure.tgt(revision 193500)
> +++ libsanitizer/configure.tgt(working copy)
> @@ -20,7 +20,7 @@
>
> # Filter out unsupported syste
The attached patch assumes that mach_override/mach_override.h
and mach_override/mach_override.c has been imported by the libsanitizer
maintainers for use by darwin. The patch adds darwin to the supported
target list in configure.tgt and defines USING_MACH_OVERRIDE for darwin
in configure.ac. The
Rainer Orth writes:
> "H.J. Lu" writes:
>> We don't have a maintainer is a problem, not go upstream first.
> Agreed. I've no idea if the SC appointed one when it accepted
> libsanitizer etc. into GCC.
Instead of guessing and complaining about the GCC SC, have you two
thought of actually looki
On 14.11.12 11:51, Uros Bizjak wrote:
> Hello!
>
>> this commit: 193486 broke bootstrap on targets which do not have
>> HAVE_GNU_INDIRECT_FUNCTION.
>> Ok to commit?
>
> OK, with appropriate ChangeLog entry and if bootstrapped correctly on
> both, IFUNC and non-IFUNC capable target.
Ok, below the
Hi Jack,
most certainly the functionality of asan is not intact.
The error messages denote that mach_override couldn't parse some of
the function prologues, which means some of ASan interceptors just
won't work.
In order to fix this you need to change the DEBUG definition in
mach_override.c, look
Hi Alex,
> most certainly the functionality of asan is not intact.
> The error messages denote that mach_override couldn't parse some of
> the function prologues, which means some of ASan interceptors just
> won't work.
> In order to fix this you need to change the DEBUG definition in
> mach_overr
On Wed, Nov 14, 2012 at 07:00:14PM +0400, Alexander Potapenko wrote:
> Hi Jack,
>
> most certainly the functionality of asan is not intact.
> The error messages denote that mach_override couldn't parse some of
> the function prologues, which means some of ASan interceptors just
> won't work.
> In
Folks,
libgcc's soft-fp is based on GLIBC's soft-fp. In the patch [1/2] I've
brought across the latest bug fixes from GLIBC. These changes include a
dependence on relevant targets (aarch64, ia64, i386) providing a
definition of FP_TRAPPING_EXCEPTIONS. The patch [2/2] provides an
aarch64 de
This patch updates libgcc/soft-fp from GLIBC/soft-fp.
/Marcus
2012-11-14 Marcus Shawcroft
* soft-fp: Updated from glibc upstream.diff --git a/libgcc/soft-fp/op-common.h b/libgcc/soft-fp/op-common.h
index b70026f..12fb16e 100644
--- a/libgcc/soft-fp/op-common.h
+++ b/libgcc/soft-fp/op-
This patch provides a definition of FP_TRAPPING_EXCEPTION for aarch64.
/Marcus
2012-11-14 Marcus Shawcroft
* config/aarch64/sfp-machine.h (FP_EX_ALL): Define.
(FP_EX_SHIFT): Define.
(FP_TRAPPING_EXCEPTIONS): Define.diff --git a/libgcc/config/aarch64/sfp-machine.h b
On Wed, Nov 14, 2012 at 04:08:06PM +0100, Rainer Orth wrote:
> Hi Alex,
>
> > most certainly the functionality of asan is not intact.
> > The error messages denote that mach_override couldn't parse some of
> > the function prologues, which means some of ASan interceptors just
> > won't work.
> > I
Jack Howarth writes:
>I am confused on the strategy here. Will the FSF gcc developers be
> prohibiting
> the addition of darwin support for libsanitizer until all issues in its
> operation
> are resolved? It seems like a chicken and egg situation. I think this should
> be
> considered an e
Hi Rainer,
The quick answer is no, although the expansion into GCC world may
require such a guideline.
We've initially implemented ASan on Linux and then ported it to
Android (which is very similar to Linux) and Mac (which is very
different), so we have little experience with porting yet.
I've sum
Hi Alex,
> The quick answer is no, although the expansion into GCC world may
> require such a guideline.
> We've initially implemented ASan on Linux and then ported it to
> Android (which is very similar to Linux) and Mac (which is very
> different), so we have little experience with porting yet.
On Wed, Nov 14, 2012 at 07:56:18PM +0400, Alexander Potapenko wrote:
> Hi Rainer,
>
> The quick answer is no, although the expansion into GCC world may
> require such a guideline.
> We've initially implemented ASan on Linux and then ported it to
> Android (which is very similar to Linux) and Mac (
> From: Ed Smith-Rowland <3dw...@verizon.net>
> Date: Fri, 9 Nov 2012 05:55:16 +0100
> libcpp
>
> 2012-11-09 Ed Smith-Rowland <3dw...@verizon.net>
>
> PR c++/54413
> * include/cpplib.h (cpp_interpret_float_suffix): Add cpp_reader* arg.
> (cpp_interpret_int_suffix): Add
On Tue, Nov 13, 2012 at 3:48 PM, Paolo Bonzini wrote:
> Il 14/11/2012 00:43, H.J. Lu ha scritto:
>> This works.
>
> Ok, then please test remove install-sh and friends and do
> autoconf/automake again. If it works, commit the result (I don't care
> if you make it one or two commits).
>
> Then, wai
On Wed, Nov 14, 2012 at 12:11:13PM +0100, Jakub Jelinek wrote:
> Anyway, once asan_symbolize actually symbolizes the output, we could use
> something like:
> /* { dg-output "ERROR: AddressSanitizer stack-buffer-overflow.*" } */
> /* { dg-output "#0 0x\[0-9a-f\]+ (in _*(interceptor_|)memcmp
> |
Hi,
in this ICE on illegal what happens is the following:
finish_mem_initializers calls check_for_bare_parameter_packs which
errors out with "parameter packs not expanded with ‘...’" and returns
true, thus the former does TREE_VALUE (mem) = error_mark_node.
Eventually, emit_mem_initializers c
On Wed, Nov 14, 2012 at 8:09 PM, Rainer Orth
wrote:
> Hi Alex,
>
> thanks, that's certainly helpful. I'm primarily interested in porting
> to Solaris, both SPARC and x86. Several things should be similar to
> Linux (both being ELF systems), while other areas are certainly
> different (syscalls
I've responded to the bug.
Sorry for offtopics unrelated to your original patch.
On Wed, Nov 14, 2012 at 8:11 PM, Jack Howarth wrote:
> On Wed, Nov 14, 2012 at 07:56:18PM +0400, Alexander Potapenko wrote:
>> Hi Rainer,
>>
>> The quick answer is no, although the expansion into GCC world may
>> req
On Wed, Nov 14, 2012 at 05:39:12PM +0100, Paolo Carlini wrote:
> + /* We will already have issued an error message. */
The wording looks unclear. Either we have issued already an error message,
or we will issue it.
Jakub
On 11/14/2012 05:49 PM, Jakub Jelinek wrote:
On Wed, Nov 14, 2012 at 05:39:12PM +0100, Paolo Carlini wrote:
+ /* We will already have issued an error message. */
The wording looks unclear. Either we have issued already an error message,
or we will issue it.
You are right ;) Consider it a
On Sun, Nov 11, 2012 at 9:45 PM, Uros Bizjak wrote:
>
>> Regarding vzeroupper insertion pass - we will use gcc pass manager to
>> insert a target-dependant pass directly after reload ...
>
> ... like attached patch. The patch inserts vzeroupper pass directly
> after reload, so spills from 256bit r
On Tue, Nov 13, 2012 at 01:03:14PM -0800, Richard Henderson wrote:
> Note that your indentation is off in places.
>
> > + while ((start = strchr (end, '<')) && (end = strchr (end, '>')))
Above too when you mention it.
> Looking at all this, I'm wondering if we shouldn't split out all of thi
From: Dodji Seketeli
Date: Wed, 14 Nov 2012 14:26:40 +0100
> I guess we could do that. That would build libsanitizer, but asan will
> still not be available on sparc if the asan_shadow_offset() target hook
> is not provided. Is that OK to you?
Yes.
On Wed, 14 Nov 2012, Marcus Shawcroft wrote:
> libgcc's soft-fp is based on GLIBC's soft-fp. In the patch [1/2] I've brought
> across the latest bug fixes from GLIBC. These changes include a dependence on
> relevant targets (aarch64, ia64, i386) providing a definition of
> FP_TRAPPING_EXCEPTIONS
> There are two parts to it: the actual print_operand thing, that I say
> should be target-specific, since some targets already use those characters
> to mean different things; and of course the assembler dialects code needs
> to be fixed to not choke on escaped versions of the characters it is
> l
On Nov 14, 2012, at 6:43 AM, Jack Howarth wrote:
> The attached patch assumes that mach_override/mach_override.h
> and mach_override/mach_override.c has been imported by the libsanitizer
> maintainers for use by darwin.
So, the patches are a nice start. Since we are in stage3, they need to go
On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor wrote:
> On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam wrote:
>>
>>Currently, using -ffunction-sections and -p together results in a
>> warning. I ran into this problem when compiling the kernel. This is
>> discussed in this thread:
>>
>> htt
Back in August of 2011, Richard Biener made a change affecting COND_EXPRs
(r178408). As a result of that change the GCC MIPS compiler that used
to promote HImode variables to SImode and then put out SImode variables
and assignments for the conditional move (MIPS doesn't support HImode
conditional
On Nov 14, 2012, at 8:22 AM, Jakub Jelinek wrote:
> On Wed, Nov 14, 2012 at 12:11:13PM +0100, Jakub Jelinek wrote:
>> Anyway, once asan_symbolize actually symbolizes the output, we could use
>> something like:
>> /* { dg-output "ERROR: AddressSanitizer stack-buffer-overflow.*" } */
>> /* { dg-outp
On Wed, Nov 14, 2012 at 11:02 AM, Steve Ellcey wrote:
>
> Back in August of 2011, Richard Biener made a change affecting COND_EXPRs
> (r178408). As a result of that change the GCC MIPS compiler that used
> to promote HImode variables to SImode and then put out SImode variables
> and assignments f
On Wed, 2012-11-14 at 11:15 -0800, Andrew Pinski wrote:
> Do you have a testcase? As I added expand_cond_expr_using_cmove, I
> think this is the correct fix.
>
> Thanks,
> Andrew Pinski
Here is a cutdown test case that I have been compiling with -O3, if you
compare with and without my patch you
On Wed, Nov 14, 2012 at 10:54:18AM -0800, Mike Stump wrote:
> On Nov 14, 2012, at 6:43 AM, Jack Howarth wrote:
> > The attached patch assumes that mach_override/mach_override.h
> > and mach_override/mach_override.c has been imported by the libsanitizer
> > maintainers for use by darwin.
>
> So,
On Wed, Nov 14, 2012 at 11:12:05AM -0800, Mike Stump wrote:
> On Nov 14, 2012, at 8:22 AM, Jakub Jelinek wrote:
> > On Wed, Nov 14, 2012 at 12:11:13PM +0100, Jakub Jelinek wrote:
> >> Anyway, once asan_symbolize actually symbolizes the output, we could use
> >> something like:
> >> /* { dg-output
On Wed, Nov 14, 2012 at 11:27 AM, Steve Ellcey wrote:
> On Wed, 2012-11-14 at 11:15 -0800, Andrew Pinski wrote:
>
>> Do you have a testcase? As I added expand_cond_expr_using_cmove, I
>> think this is the correct fix.
>>
>> Thanks,
>> Andrew Pinski
>
> Here is a cutdown test case that I have been
On Wed, Nov 14, 2012 at 10:58 AM, Sriraman Tallam wrote:
> On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor wrote:
>> On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam wrote:
>>>
>>>Currently, using -ffunction-sections and -p together results in a
>>> warning. I ran into this problem when comp
On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
Given that nobody has stepped forward to test it, let's just remove
the code and see if anybody complains. I'll approve the patch unless
somebody objects in the next 24 hours.
I think the target to check would be 32 bit HPUX.
-ffunction-sections
OK.
Jason
This patch fixes the bug in a cross-compiler. I don't remember why I
put in that #ifdef in the first place, but it seems incorrect. The
other uses of NO_IMPLICIT_EXTERN_C are about allowing () in outdated C
headers, which is unrelated.
commit b34937b905aa25542da7d6ee3d71db2a1413ddbf
Author: Ja
On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law wrote:
> On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
>>
>> Given that nobody has stepped forward to test it, let's just remove
>> the code and see if anybody complains. I'll approve the patch unless
>> somebody objects in the next 24 hours.
>
> I thi
On Sun, Nov 4, 2012 at 7:45 AM, Matthias Klose wrote:
>
> now testing the attached patch.
> + when 1 is passed,
> +- the multiarch path specified with
> + -imultiarch, when 2 is passed. */
s/when 1
(Adding ASAN maintainers to the CC)
On Wed, Nov 14, 2012 at 7:55 AM, H.J. Lu wrote:
> On Wed, Nov 14, 2012 at 4:44 AM, Rainer Orth
>>
>> Btw., currently there's no libsanitizer maintainer listed in
>> MAINTAINERS. This needs to change.
>>
>
> That is the real problem. We need a GCC libsanitize
hi,
2012/9/19 Paolo Carlini :
> Hi Fabien,
>
>
> On 09/19/2012 07:29 PM, Fabien Chêne wrote:
But I'm afraid this is still not completely correct, because if the user
code has a using std::pow in the global namespace and then and include
the latter drags again in namespace std:
Hi,
On 11/14/2012 10:04 PM, Fabien Chêne wrote:
My apologize to come back after such a delay. The patch is almost
ready, I was just wondering if we could add the specialization
template<> inline double pow(double __x, double __y) { return
std::pow(__x, __y); } (in tr1/math.h) instead of relyin
I'll just note that another solution would be to change non-template
forwarding pows to be extern "C" declarations. But it sounds like you
folks have this issue in hand.
Jason
On 11/13/2012 11:53 PM, Paolo Carlini wrote:
Regarding performance, I have done a small evolution of the 54075.cc
test proposed last time. It is now checking performance with and
without cache of hash code. Result is:
54075.cc std::unordered_set 30 Foo insertions
witho
2012/11/14 Paolo Carlini :
[...]
> Since we came to the conclusion that removing the overload for (double,
> double) worked, let's just do that and be done with it. Then we have a few
> months before the release to make sure that we aren't regressing, safe
> enough for this legacy TR1 stuff, IMO.
On Wed, 2012-11-14 at 12:00 -0800, Andrew Pinski wrote:
> I know exactly where this code comes from; I have looked at the
> benchmark as one of the reason why I add expand_cond_expr_using_cmove
> in the first place. Anyways you should look into removing
> TARGET_PROMOTE_PROTOTYPES because I found
Hello!
Attached patch adjusts expected demangling strings of
testsuite/26_numerics/complex/abi_tag.cc for 128bit long-double
targets.
2012-11-14 Uros Bizjak
* testsuite/26_numerics/complex/abi_tag.cc: Adjust expected
demangling for 128bit long-double targets.
Tested on alphae
On Wed, Nov 14, 2012 at 1:45 PM, Steve Ellcey wrote:
> On Wed, 2012-11-14 at 12:00 -0800, Andrew Pinski wrote:
>
>> I know exactly where this code comes from; I have looked at the
>> benchmark as one of the reason why I add expand_cond_expr_using_cmove
>> in the first place. Anyways you should lo
On 11/14/2012 10:45 PM, Uros Bizjak wrote:
Hello!
Attached patch adjusts expected demangling strings of
testsuite/26_numerics/complex/abi_tag.cc for 128bit long-double
targets.
2012-11-14 Uros Bizjak
* testsuite/26_numerics/complex/abi_tag.cc: Adjust expected
demangling for
On Wed, Nov 14, 2012 at 1:51 PM, Andrew Pinski
wrote:
> On Wed, Nov 14, 2012 at 1:45 PM, Steve Ellcey wrote:
>> On Wed, 2012-11-14 at 12:00 -0800, Andrew Pinski wrote:
>>
>>> I know exactly where this code comes from; I have looked at the
>>> benchmark as one of the reason why I add expand_cond_e
The following patch adds the multiarch definitions for alpha-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose
* config/alpha/t-linux: New file; define MULTIARCH_DIRNAME.
* config.gcc (tmake_file): Include alpha/t-linux.
Index: c
On 21/09/12 03:40, Sandra Loosemore wrote:
> Re:
>
>> I think tree-ssa-loop-ivopts is simply
>> asking for the wrong thing, and needs to be changed. As I say,
>> Sandra had some fixes in this area.
>
> This patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
>
> Sadly, that patc
The following patch adds the multiarch definitions for arm-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose
* config/arm/t-linux-eabi: Define MULTIARCH_DIRNAME for linux target.
Index: config/arm/t-linux-eabi
=
The following patch adds the multiarch definitions for ia64-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose
* config/ia64/t-linux: New file; define MULTIARCH_DIRNAME.
* config.gcc (tmake_file): Include ia64/t-linux.
Index: conf
The following patch adds the multiarch definitions for m68k-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Here, I'm unsure if the definition needs to be further constrained.
Matthias
2012-11-14 Matthias Klose
* config/m68k/t-linux: Define MULTIARCH_DIRNAME.
Ind
The following patch adds the multiarch definitions for mips-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose
* config/mips/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
Index: config/mips/t-linux64
==
The following patch adds the multiarch definitions for hppa-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose
* config/pa/t-linux: New file; define MULTIARCH_DIRNAME.
* config.gcc (tmake_file):
Include pa/t-linux.
Index: config/
The following patch adds the multiarch definitions for -linux-gnu. Tested using
a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose
* config/rs6000/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/rs6000/t-linux: New file; define MULTIARCH_DI
The following patch adds the multiarch definitions for s390-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose
* config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
Index: config/s390/t-linux64
===
The following patch adds the multiarch definitions for sparc-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose
* config/sparc/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/sparc/t-linux: New file; define MULTIARCH
From: Matthias Klose
Date: Wed, 14 Nov 2012 23:36:17 +0100
> The following patch adds the multiarch definitions for sparc-linux-gnu. Tested
> using a Debian/Ubuntu package build. Ok for the trunk?
I'm fine with this.
On Wed, 14 Nov 2012, Matthias Klose wrote:
> The following patch adds the multiarch definitions for m68k-linux-gnu. Tested
> using a Debian/Ubuntu package build. Ok for the trunk?
>
> Here, I'm unsure if the definition needs to be further constrained.
Classix m68k and ColdFire need different mul
On 11/14/2012 01:32 PM, Ian Lance Taylor wrote:
On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law wrote:
On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
Given that nobody has stepped forward to test it, let's just remove
the code and see if anybody complains. I'll approve the patch unless
somebody
Your t-linux setting fails to allow for the possibility of the compiler
being configured to default to soft-float (whether --with-float=soft, or
--with-cpu etc. for a CPU that implies soft-float). soft-float (only
supported for 32-bit) is ABI-incompatible with hard-float and needs its
own mult
Hi,
On 11/14/2012 10:27 PM, François Dumont wrote:
We do not cache if the following conditions are all met:
- key type is an integral
- hash functor is empty and not final
- hash functor doesn't throw
Can somebody remind me why *exactly* we have a condition having to do
with the empty-ness of t
1 - 100 of 129 matches
Mail list logo
