This integrates the Solaris2 work from Eric Botcazou, and has
some changes based upon feedback from Richard Henderson.
The bootstrap comparison failure no longer happens, and this is fully
regstrapped on sparc-linux-gnu w/--with-cpu=niagara4, and I also did a
quick bootstrap check using --with-cp
On Wed, Nov 14, 2012 at 7:51 PM, H.J. Lu wrote:
> Hi,
>
> X32 uses 32-bit pointer in software. But its hardware pointer is
> 64-bit. We must use hardware pointer to unwind frames. This patch
> adds uhwptr for hardware pointer and uses it to unwind stack frames.
> Tested on Linux/x32, Linux/x86-
Hi,
X32 uses 32-bit pointer in software. But its hardware pointer is
64-bit. We must use hardware pointer to unwind frames. This patch
adds uhwptr for hardware pointer and uses it to unwind stack frames.
Tested on Linux/x32, Linux/x86-64 and Linux/ia32. Please review it
for upstream.
Thanks.
Hi all,
Little change, add microMIPS option.
Please checkin if it is OK.
Regards,
Jia
2012-11-15 Jia Liu
* gcc/doc/invoke.texi: Add microMIPS option.
Signed-off-by: Jia Liu
---
gcc/doc/invoke.texi |7 +++
1 file changed, 7 insertions(+)
diff --git a/gcc/doc/invoke.texi
On 15 November 2012 01:51, Jason Merrill wrote:
> This bug arose because I was using DECL_SOURCE_LOCATION to determine whether
> this is the first declaration of the class. Which may be fragile, but I
> don't see another way to do it. But for an explicit specialization we were
> treating the temp
> Hi!
>
> Before Richard Sandiford's 4.7 optab cleanups emit_conditional_move
> wasn't testing the predicate on the comparison, and apparently
> movcc patterns in i386.md can handle some comparisons that the
> current predicates on the expanders reject. This PR on MonteCarlo
> kernel shows a hard
On 11/11/2012 11:58 PM, Jason Merrill wrote:
On 11/11/2012 08:01 AM, Florian Weimer wrote:
I'm not sure if this sufficiently far-reaching. It seems that this
doesn't allow me to implement a virtual function which takes a
std::string parameter in new-ABI-mode when the base class is also used
in
On 2012-11-14 11:02, Steve Ellcey wrote:
> 2012-11-14 Steve Ellcey
>
> * expr.c (expand_cond_expr_using_cmove): Use promoted mode for temp.
Ok.
r~
This bug arose because I was using DECL_SOURCE_LOCATION to determine
whether this is the first declaration of the class. Which may be
fragile, but I don't see another way to do it. But for an explicit
specialization we were treating the template declaration as the initial
declaration, so the
This patch allows the user to specify a vector number in an interrupt
attribute, allowing for more generic creation of vector tables. Ok?
* doc/extend.texi (Function Attributes): Document RX extensions to
"interrupt" attribute.
* config/rx/rx.c (has_interrupt_vector): New
PR libstdc++/53841
* include/std/condition_variable (condition_variable::wait_until):
Handle clocks with higher resolution than __clock_t.
(condition_variable::__wait_until_impl): Remove unnecessary _Clock
parameter.
* testsuite/30_threads/condition_v
Hi!
Before Richard Sandiford's 4.7 optab cleanups emit_conditional_move
wasn't testing the predicate on the comparison, and apparently
movcc patterns in i386.md can handle some comparisons that the
current predicates on the expanders reject. This PR on MonteCarlo
kernel shows a hardly predictable
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
- Original Message -
> The regular comparison with Kaffe is gone after the restructuring/
> move to github, and I could not find any replacement URL.
>
> I applied this patch. If any of you has a new URL, we can resurrect.
>
> Gerald
>
> 2012-11-01 Gerald Pfeifer
>
> * status
Hi!
Steven has been complaining for some years that var-tracking inserts
NOTE_INSN_VAR_LOCATION (and NOTE_INSN_CALL_ARG_LOCATION) notes sometimes
in between basic blocks, but with BLOCK_FOR_INSN set (or sometimes extends
a bb ending originally with a noreturn or throwing call by a note or more
aft
Hi,
gcov-io.c contains bogus array bounds check that makes us to unroll one time
too many and trigger bogus -Warray-bounds warning.
I made testcase for PR55079 and fixed the bounds check.
Bootstrapped/regtested/comitted x86_64.
Honza
PR bootstrap/55051
* gcov-io.c (gcov_read_summar
Am 15.11.2012 00:55, schrieb Joseph S. Myers:
> On Thu, 15 Nov 2012, Matthias Klose wrote:
>
>> Am 14.11.2012 23:41, schrieb Joseph S. Myers:
>>> 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
>
Hello!
Attached patch fixes following testsuite failure
FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C (test for excess errors)
FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C (test for excess errors)
on targets that don't support Q and W floating suffixes.
2012-11-15 Uros Bizjak
* g
I am checking this into GCC tree for Roland.
On Wed, Nov 14, 2012 at 4:13 PM, Roland McGrath wrote:
> I've just noticed that this change (git mirror view):
>
> commit 7228bb7b806e7f0513557e3002a6dca104a768a1
> Author: H.J. Lu
> Date: Sun Aug 26 14:34:38 2012 +
>
>
On Thu, 15 Nov 2012, Matthias Klose wrote:
> Am 14.11.2012 23:41, schrieb Joseph S. Myers:
> > 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-floa
Am 14.11.2012 23:41, schrieb Joseph S. Myers:
> 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 AB
On Wed, Nov 14, 2012 at 3:19 PM, Cary Coutant wrote:
>> Enclosed is a simple fix for this ICE--address_table_entries that have
>> zero refcounts shouldn't be assigned an index.
>>
>> OK for trunk?
>>
>> Sterling
>>
>> 2012-11-14 Sterling Augustine
>>
>> * dwarf2out.c (index_address_tabl
Hi,
this patch reduces max-peeled-insns and max-completely-peeled-insns from 400 to
100. The reason why I am doing this is that I want to reduce code bloat caused
by my cunroll work that enabled a lot more unrolling then previously causing
considerable code size regression at -O3.
I do not think
Am 14.11.2012 23:39, schrieb Joseph S. Myers:
> 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 const
PR libstdc++/55320
* include/std/functional (function::function(F)): Set _M_manager after
operations that could throw.
(_Function_base::_Ref_manager::_M_init_functor): Use addressof.
* include/tr1/functional
(_Function_base::_Ref_manager::_M_init_func
> Enclosed is a simple fix for this ICE--address_table_entries that have
> zero refcounts shouldn't be assigned an index.
>
> OK for trunk?
>
> Sterling
>
> 2012-11-14 Sterling Augustine
>
> * dwarf2out.c (index_address_table_entry): Check a node's refcount.
Add PR debug/55328 to the Ch
Thanks for testing this.
Enclosed is a simple fix for this ICE--address_table_entries that have
zero refcounts shouldn't be assigned an index.
OK for trunk?
Sterling
2012-11-14 Sterling Augustine
* dwarf2out.c (index_address_table_entry): Check a node's refcount.
patch.diff
Descri
Hi,
profiledbootstrap shows bug in edge_badness. With inline hints the growth is
no longer
limited by small constant and thus multiplying it with overall growth may
overlfow.
Bootstrapped/regtested & comitted.
Honza
PR bootstrap/55051
* ipa-inline.c (edge_badness): Improve dump
Hi,
this patch fixes missed cmov conversion I noticed while looking into PR53346.
It effectively
reverts patch http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02326.html
I believe it is mistaken - it chnaged comparison_operator to
unordered_comparison_operator
on the basis that those patterns are i
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
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
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
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
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.
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
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 -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 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 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 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 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 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
=
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 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 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
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: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
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, 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
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 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
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
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
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:
(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
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
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
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
OK.
Jason
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
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 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 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 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, 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 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 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
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 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
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
> 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 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
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 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
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 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 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
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 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
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 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
> |
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
> 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 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 (
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.
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
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
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
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
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-
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
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
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
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
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
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
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
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
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:
/*
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
1 - 100 of 129 matches
Mail list logo
