Hi all,
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrumentation. This feature is needed because
- reports during early bootstrap won't even be printed
- needed to run all tests w/o rebooting machine for
On Fri, Sep 5, 2014 at 10:54 AM, Yury Gribov y.gri...@samsung.com wrote:
Hi all,
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline instrumentation.
This feature is needed because
- reports during early bootstrap
On 25/08/14 11:32, Tony Wang wrote:
Hi all,
The bug is reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846,
and it’s about the problem that
when exception handler is involved in the function, then _Unwind_Backtrace
function will run into deadloop on
arm target.
Cmd line:
On 04/09/14 18:12, Richard Henderson wrote:
On 09/04/2014 07:04 AM, Ramana Radhakrishnan wrote:
gcc/Changelog
2014-09-04 Marcus Shawcroft marcus.shawcr...@arm.com
Ramana Radhakrishnan ramana.radhakrish...@arm.com
* config/aarch64/aarch64-elf-raw.h (ENDFILE_SPEC):
On 09/05/2014 11:32 AM, Dmitry Vyukov wrote:
Can we do it w/o doubling number of runtime entry points?
I didn't find a good way to achieve this. See, normal asan reporting
functions
have a noreturn attribute (defined in sanitizer.def) which can't be changed
depending on cmdline flag.
Looks
On Thu, 4 Sep 2014, Jeff Law wrote:
On 09/04/14 06:11, Richard Biener wrote:
The following two patches each fix PR63148, a wrong-code issue
caused by bogus array indices a-la
global_data.b[(sizetype) i + 536870911] which have a correct
address when lowered but bogus index.
The
Hi,
AArch64 builds have recently been spitting out:
.../gcc/config/aarch64/aarch64.md:629: warning: operand 1 missing mode?
I've committed the attached patch as obvious, giving operand 1 DImode.
The patch was tested on AArch64 cross with no problems.
Thanks,
James
---
2014-09-05 James
On Fri, Sep 5, 2014 at 12:12 PM, Yury Gribov y.gri...@samsung.com wrote:
On 09/05/2014 11:32 AM, Dmitry Vyukov wrote:
Can we do it w/o doubling number of runtime entry points?
I didn't find a good way to achieve this. See, normal asan reporting
functions
have a noreturn attribute (defined
On 05/09/14 09:20, James Greenhalgh wrote:
Hi,
AArch64 builds have recently been spitting out:
.../gcc/config/aarch64/aarch64.md:629: warning: operand 1 missing mode?
I've committed the attached patch as obvious, giving operand 1 DImode.
I remember noticing that some time ago, thanks
On 09/05/2014 12:23 PM, Dmitry Vyukov wrote:
I didn't find a good way to achieve this. See, normal asan reporting
functions
have a noreturn attribute (defined in sanitizer.def) which can't be changed
depending on cmdline flag.
I have not looked at the code in detail. But it looks weird to me
On Fri, Sep 5, 2014 at 4:38 AM, Aldy Hernandez al...@redhat.com wrote:
On 09/04/14 03:42, Richard Biener wrote:
On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez al...@redhat.com wrote:
Flow-wise I still want to move hand-off to the cgraph code to toplev.c,
out from the FEs
Hi all,
We didn't schedule alu_ext and alus_ext anywhere for Cortex-A53 so this
patch handles it.
Tested arm-none-eabi and aarch64-none-elf.
Ok for trunk?
Thanks,
Kyrill
2014-09-05 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/cortex-a53.md (cortex_a53_alu_shift): Add alu_ext,
On 09/05/2014 10:54 AM, Yury Gribov wrote:
Hi all,
This patch enables -fsanitize-recover for KASan by default. This causes KASan
to continue execution after error in case of inline instrumentation. This
feature is needed because
- reports during early bootstrap won't even be printed
-
Hi all,
As the PR says we currently ICE in aarch64_simd_lane_bounds when processing
#include arm_neon.h
int32x4_t foo (int32x4_t a, int16x4_t b, int16x4_t c, int d)
{
return vqdmlal_lane_s16 (a, b, c, d);
}
This code is invalid since the lane argument (d) should be a
compile-time constant.
On 09/05/2014 12:59 PM, Andrey Ryabinin wrote:
And how does it work if someone wants to try -fsanitize=address
-fsanitize-recover.
Seems you didn't touch libsanitzer in this patch,
so I guess this will cause link time error, right ?
Exactly, Asan team does not want recovery mode for
This patch does just $subject, leaving the sanity checking
under ENABLE_CHECKING for 2/2.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-09-05 Richard Biener rguent...@suse.de
* cfgloop.c (mark_loop_for_removal): New function.
* cfgloop.h
On Fri, Sep 05, 2014 at 12:33:54PM +0400, Yury Gribov wrote:
On 09/05/2014 12:23 PM, Dmitry Vyukov wrote:
I didn't find a good way to achieve this. See, normal asan reporting
functions
have a noreturn attribute (defined in sanitizer.def) which can't be changed
depending on cmdline flag.
I
On 09/05/2014 01:28 PM, Jakub Jelinek wrote:
Though, for that option the default is yes for ubsan purposes, while asan
wants a default to no, so it is unclear how to solve that. Either different
option for asan recovery, or tristate option etc.
Currently I force set it on encountering
Hi!
On Fri, 29 Aug 2014 14:36:17 +, Zamyatin, Igor igor.zamya...@intel.com
wrote:
The patch is another attempt to enable Cilk_for (see eg
https://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm)
in the GCC compiler.
Bootstrapped and
On Fri, Sep 05, 2014 at 11:41:07AM +0200, Thomas Schwinge wrote:
Shouldn't CILK_FOR also be added to gcc/gimplify.c:is_gimple_stmt, next
to all the other OMP_FOR variants?
diff --git gcc/gimplify.c gcc/gimplify.c
index 2319fc3..a621824 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@
On Fri, Sep 5, 2014 at 3:33 AM, Kugan kugan.vivekanandara...@linaro.org wrote:
Here is an attempt to do the value range computation in promoted_mode's
type when it is overflowing. Bootstrapped on x86-84.
Err - I think you misunderstood this as a suggestion to do this ;)
value-ranges should be
The following patch adds sanity checking for loops removed
via mark_loop_for_removal or fix_loop_structure to check
whether they reappear in the same place.
The simplest case is where the loop header stays the same
and we definitely should avoid all these cases.
The other case is where the old
On 05/09/14 10:01, Kyrill Tkachov wrote:
Hi all,
We didn't schedule alu_ext and alus_ext anywhere for Cortex-A53 so this
patch handles it.
Tested arm-none-eabi and aarch64-none-elf.
Ok for trunk?
Ok - thanks.
Ramana
Thanks,
Kyrill
2014-09-05 Kyrylo Tkachov kyrylo.tkac...@arm.com
Hi!
On Fri, 22 Aug 2014 14:18:32 +0200, Bernd Schmidt ber...@codesourcery.com
wrote:
On 07/29/2014 12:36 AM, Joseph S. Myers wrote:
On Thu, 24 Jul 2014, Jakub Jelinek wrote:
Yeah. I believe gcc.c-torture/compile/ has been converted already,
so it is just about gcc.c-torture/execute/.
Pushed r214946. (In the meantime the erroneous alu_reg had been changed to
alu_sreg by r212750 https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00679.html .)
Marcus Shawcroft wrote:
On 20 August 2014 10:25, Alan Lawrence alan.lawre...@arm.com wrote:
The SIMD-register variant is miscategorized as
On 14/08/14 21:22 +0200, François Dumont wrote:
Then here is the patch to introduce default constructor with
compiler computed noexcept qualification. Note that I also made
allocator aware default constructor allocation free however noexcept
qualification has to be manually written which I
The last sentence above is not needed.
So, revised patch without the last sentence.
2014-09-05 Joost VandeVondele vond...@gcc.gnu.org
PR fortran/62245
* intrinsic.texi (INT): clarify result.
Index: fortran/intrinsic.texi
Mike Stump mikest...@comcast.net wrote:
BTW, Jeff's comment on pr39228.c makes me think that this test
can be moved into execute/ieee. Thought?
I don’t see a down side, specially if we know that the test case is picky
about ieee.
Thanks for suggestion. The patch below simply moves it
On Wed, 3 Sep 2014, Richard Biener wrote:
Ok, so with recent activity in that mgrid bug (PR55334) I tried
to remember what solution we thought of after determining that
ADD_RESTRICT is a no-go.
The following very prototypish patch implements the idea of
computing known non-dependences
David Malcolm dmalc...@redhat.com writes:
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 7cddab7..57eb83b 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -2849,8 +2849,8 @@ arc_print_operand (FILE *file, rtx x, int code)
/* Is this insn in a delay slot
On 09/04/2014 09:23 PM, Mike Stump wrote:
On Sep 4, 2014, at 4:14 AM, Ramana Radhakrishnan ramana@googlemail.com
wrote:
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2293,8 +2293,8 @@ proc check_effective_target_arm_little_endian { } {
proc
On Fri, Sep 05, 2014 at 11:16:02AM +, VandeVondele Joost wrote:
The last sentence above is not needed.
So, revised patch without the last sentence.
2014-09-05 Joost VandeVondele vond...@gcc.gnu.org
PR fortran/62245
* intrinsic.texi (INT): clarify result.
OK.
--
OK.
Committed revision 214958.
On Fri, Aug 22, 2014 at 11:36 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The Cortex-A53 scheduler description is missing rules for insn types used by
instructions such as vrint*, vmaxnm, vminnm causing them to be assigned to
the nothing unit.
This patch causes such
Apologies, resent with correct patch not containing ChangeLog changes.
Hi,
I have a simple patch for the vdup_lane_2.c test that fixes up the
force_simd macro so that it does
something sensible for execute type test cases. Is this ok to install?
Tested on aarch64 little and big endian.
Ping.
-Maxim
On 08/28/2014 11:31 AM, Maxim Ostapenko wrote:
Ping. Add Joseph S. Myers as driver maintainer.
-Maxim
Original Message
Subject: Fwd: [PATCH] Add patch for debugging compiler ICEs.
Date: Tue, 19 Aug 2014 17:57:51 +0400
From: Maxim Ostapenko
Some manual editing of patch required due to e.g. int64x1 changes present on
trunk but not on the 4.9 branch; new patch attached.
I've done a quick smoke test of aarch64.exp+simd.exp (check-gcc) and the g++
neon ABI test, as these ought to catch any changes to Neon intrinsics; full
testsuite
This patch to libgo fixes the size for the GC instructions for
unsafe.Pointer, which are hand coded. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 6b61234c2552 libgo/runtime/go-unsafe-pointer.c
--- a/libgo/runtime/go-unsafe-pointer.c Wed Sep
Hi,
The attached patch enables the address and undefined behavior sanitizers.
I have tested it on AArch64 hardware, and asan.exp tests pass, but a
few ubsan.exp tests fail as follows:
FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O3 -g execution test
FAIL:
Hi,
I have a potential fix for a gcc testsuite failure for aarch64 in big
endian, i.e.
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o compile, (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_y_tst.o compile, (internal
compiler error)
It is caused by the
Latest results for 4.9.x
-tgc
Testresults for 4.9.1:
aarch64-linux-gnu (cross)
arm-unknown-linux-gnu
hppa-unknown-linux-gnu
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
powerpc-unknown-linux-gnu
sparc-unknown-linux-gnu
x86_64-unknown-linux-gnu
Index:
On 5 September 2014 14:46, David Sherwood david.sherw...@arm.com wrote:
Apologies, resent with correct patch not containing ChangeLog changes.
Hi,
I have a simple patch for the vdup_lane_2.c test that fixes up the
force_simd macro so that it does
something sensible for execute type
On 09/04/2014 05:22 PM, Richard Biener wrote:
For some reason I use
set shiftwidth=4
set tabstop=8
set autoindent
set cinoptions={.5s,g0,p5,t0,(0,^-0.5s,n-0.5s
I note some differences to your
+ setlocal cinoptions=4,n-2,{2,^-2,:2,=2,g0,h2,p5,t0,+2,(0,u0,w1,m1
Ah, the vimfu.
So the
Hi,
On 04 Sep 15:54, Thomas Schwinge wrote:
Aha, it's gcc/gcc.c:LINK_PLUGIN_SPEC that is unconditionally adding the
-fresolution option. Here is a hack that seems to make it work, but that
most certainly should be done differently:
Here is updated patch, which solves the problem with linker
On 09/05/2014 12:22 AM, Bernhard Reutner-Fischer wrote:
Not sure from whom i borrowed this, perhaps even from you richi, but the
gcc_style.vim pasted in the mail below seems to be floating around ;)
https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01228.html
Nice! Interestingly enough this gives
On Fri, 2014-09-05 at 14:03 +0100, Richard Sandiford wrote:
David Malcolm dmalc...@redhat.com writes:
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 7cddab7..57eb83b 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -2849,8 +2849,8 @@ arc_print_operand
No new testresults just a small fixup for the update from Raghunath
Lolur.
His aarch64 build was cross built though the testsuite seems to have
been run using qemu (host=target).
I'm uncertain if this qualifies for mentioning the build host in the
second column, but for now the just posted 4.9
On Thu, Sep 4, 2014 at 6:15 PM, Joseph S. Myers jos...@codesourcery.com wrote:
gcc/c-family:
2014-09-05 Joseph Myers jos...@codesourcery.com
* c-cppbuiltin.c (c_cpp_builtins): Also define
__LIBGCC_EH_TABLES_CAN_BE_READ_ONLY__,
__LIBGCC_EH_FRAME_SECTION_NAME__,
On Mon, Sep 1, 2014 at 4:18 AM, Michael Hudson-Doyle
michael.hud...@linaro.org wrote:
It's late for me and I don't have a proper test case but it seems to me
that while gccgo's syscall lets you set Cloneflags on its SysProcAttr,
but doesn't actually *do* anything with the flags. Am I missing
From: Trevor Saunders tsaund...@mozilla.com
Hi,
Doing this means we get to remove a fair chunk of runtime checking.
bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions.
config-list.mk with this and the next patch is ongoing. ok?
Trev
gcc/
* config/i386/i386.c,
From: Trevor Saunders tsaund...@mozilla.com
Hi,
Same idea as the last patch.
also bootstrapped and regtested on x86_64-unknown-linux-gnu with config-list.mk
ongoing ok?
Trev
gcc/
* cfgrtl.c, combine.c, config/arc/arc.c, config/mcore/mcore.c,
config/rs6000/rs6000.c,
On 4 September 2014 19:19, Venkataramanan Kumar
venkataramanan.ku...@linaro.org wrote:
Hi James,
Yes we can just mark operand 3 as r.
PFB, the updated patch. Ok for trunk?
regards,
Venkat.
gcc/ChangeLog
2014-09-04 Venkataramanan Kumar venkataramanan.ku...@linaro.org
*
Hi!
On Tue, 06 Jan 2009 00:10:02 +0200, Janne Blomqvist blomqvist.ja...@gmail.com
wrote:
attached is a substantially reworked low level I/O library for gfortran.
[...]
Due to a recent improvement in GCC, it is now pointing out an issue in
the following code:
2009-01-05 Janne Blomqvist
Please sort the letters (LC_ALL=C sort) and where consecutive, use ranges.
Thus \[0-9A-Zhjqvx-z\]*
OK, works fine with the attached patch, and looks cleaner in Make-lang.in.
Now, with the proper email address for gcc-patches... I wonder how many time
I'll be punished for typos.
unmodified
Richard Biener rguent...@suse.de writes:
2014-09-05 Richard Biener rguent...@suse.de
* cfgloop.c (mark_loop_for_removal): Record former header
when ENABLE_CHECKING.
* cfgloop.h (strut loop): Add former_header member when
ENABLE_CHECKING.
* loop-init.c
This removes some remnants from the accel-gcc support that turned out
not to be viable for ptx. Ilya Verbin has confirmed the patch doesn't
break their setup either, so I've committed it on the branch.
Bernd
Index: ChangeLog.gomp
On 09/05/14 09:32, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
Hi,
Doing this means we get to remove a fair chunk of runtime checking.
bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions.
config-list.mk with this and the next patch is
On 09/05/14 09:32, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
Hi,
Same idea as the last patch.
also bootstrapped and regtested on x86_64-unknown-linux-gnu with config-list.mk
ongoing ok?
Trev
gcc/
* cfgrtl.c, combine.c, config/arc/arc.c,
On 5 September 2014 17:10, Yury Gribov y.gri...@samsung.com wrote:
Now I don't quite like the idea of plugin:
* .local.vimrc setting is more compatible with what we already have for
Emacs
* gcc_style.vim won't work for new files (it requires GCC license agreement)
true
* gcc_style.vim
On 09/05/14 04:00, Richard Biener wrote:
The following patch adds sanity checking for loops removed
via mark_loop_for_removal or fix_loop_structure to check
whether they reappear in the same place.
The simplest case is where the loop header stays the same
and we definitely should avoid all
On Sep 5, 2014, at 3:10 AM, Thomas Schwinge tho...@codesourcery.com wrote:
Should PR20567 now be updated?
Updated.
On Fri, Sep 05, 2014 at 10:43:45AM -0600, Jeff Law wrote:
On 09/05/14 09:32, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
Hi,
Doing this means we get to remove a fair chunk of runtime checking.
bootstrapped + regtested on x86_64-unknown-linux-gnu with no
This patch removes some fp-bit target macros that are no longer
needed:
* __make_dp was not really designed as a target macro, but CRIS
defined it in cris.h anyway for optimization purposes (so making it
show up on lists of target macros). Since CRIS no longer uses
fp-bit, that definition
On Fri, Sep 05, 2014 at 07:10:02PM +0400, Yury Gribov wrote:
Now I don't quite like the idea of plugin:
Anything that will make this enabled automatically will meet a lot of
resistance. Make something nice for contrib/ instead?
Segher
This patch moves handling of Wnormalized= to c.opt.
There were two quirks when doing this:
1) I cannot use the cpplib.h type 'enum cpp_normalize_level' as Type()
because this will require including cpplib.h into options.h, which in
turn causes a lot of problems, thus I needed to use Type(int).
This adds a new option property CppReason which maps to a warning
reason code in cpplib.h. This allows us to auto-generate
cpp_reason_option_codes[], which maps from CPP warning codes to GCC
ones, thus making a bit harder to forget to update this table (which
evidently has happened a lot in the
This patch from Chris Manghane adds support for precise type information
to the gccgo garbage collector. This is only the first step, as the
compiler does not pass the type information to the allocator in most
cases. I think that right now the precise type information will only be
available for
I made a thinko in r214080. That patch makes the andi. pattern not match
for insns that can match rlwinm, and also makes rlwinm. not match insns
that can match andi. (and similar for andis. and rldicl etc.) This
ensures we always choose the cheapest instruction.
However, the splitter for andi.
On Fri, Sep 5, 2014 at 1:48 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
I made a thinko in r214080. That patch makes the andi. pattern not match
for insns that can match rlwinm, and also makes rlwinm. not match insns
that can match andi. (and similar for andis. and rldicl etc.)
potential_constant_expression was getting confused by the (non-constant)
object argument of the OFFSET_REF, but it isn't really involved in
calculating the value of the PMF.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.9.
commit cbf61fb5d2ae5db8ff4986e2124105cb899c0037
Author: Jason
On Fri, Sep 5, 2014 at 3:00 AM, Richard Biener rguent...@suse.de wrote:
The following patch adds sanity checking for loops removed
via mark_loop_for_removal or fix_loop_structure to check
whether they reappear in the same place.
The simplest case is where the loop header stays the same
and
On 07/17/14 10:56, Alan Lawrence wrote:
Ok, the attached tests are passing on x86_64-none-linux-gnu,
aarch64-none-elf, arm-none-eabi, and a bunch of smaller platforms for
which I've only built a stage 1 compiler (i.e. as far as necessary to
assemble). That's with either change to
On 09/04/14 14:22, Jakub Jelinek wrote:
On Thu, Sep 04, 2014 at 04:04:17PM -0400, David Malcolm wrote:
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -195,6 +195,7 @@ union rtunion
unsigned int rt_uint;
const char *rt_str;
rtx rt_rtx;
+ rtx_insn *rt_insn;
rtvec rt_rtvec;
enum
On 09/04/14 15:19, David Malcolm wrote:
I suppose so, but I don't see an easy way of locating such XEXP users
beyond building with ENABLE_RTL_CHECKING, and checking on every
configuration, and trying to exercise all code paths. Can we consider
that a *long-term* followup?
Well, XEXP isn't
On 09/04/14 14:04, David Malcolm wrote:
On Tue, 2014-09-02 at 19:50 +0200, Andi Kleen wrote:
I suspect the bulk of them currently are coming from the safe_as_a
rtx_insn * calls within NEXT_INSN and PREV_INSN; do you happen to have
information handy on that?
Yes that's right:
- 1.03% lto1
On Fri, 2014-09-05 at 12:45 -0600, Jeff Law wrote:
On 09/04/14 14:04, David Malcolm wrote:
On Tue, 2014-09-02 at 19:50 +0200, Andi Kleen wrote:
I suspect the bulk of them currently are coming from the safe_as_a
rtx_insn * calls within NEXT_INSN and PREV_INSN; do you happen to have
On 09/04/14 08:05, Wilco Dijkstra wrote:
Hi,
While changing register costs for AArch64 (patches to follow), the test
gcc.target/aarch64/vect-mult.c fails. This is caused by ree inserting a TI mode
copy of a DI
register. Since TI mode requires 2 registers, this results in silent corruption
of
Bin,
This is perhaps a plus for Aarch64 as well. Is there any plan to add a
64-bit version of this patch or should a bug be open for this?
Thank you,
--
Evandro Menezes Austin, TX
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org
On 09/04/14 08:15, Jiong Wang wrote:
currently, the instruction sink in prepare_shrink_wrap is a bit
conservative
that some further optimization opportunities have been missed.
given the prologue use register A by:
(store A, [sp + offset])
then given the entry_basic_block contains a simply
From: Joseph S. Myers jos...@codesourcery.com
Date: Fri, 5 Sep 2014 19:21:04 +0200
This patch removes some fp-bit target macros that are no longer
needed:
* __make_dp was not really designed as a target macro, but CRIS
defined it in cris.h anyway for optimization purposes
Minor
On Fri, 2014-09-05 at 01:15 +, Joseph S. Myers wrote:
It is desirable for various reasons to stop target libraries from
using host-side tm.h: making the headers work on both host and target
(and on build as well) is fragile (especially when dealing with macros
depending on command-line
Minor bit of docs for an msp430 option. OK for trunk and 4.9 branch?
* doc/invoke.texi (MSP430 Options): Add -minrt.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 214976)
+++ doc/invoke.texi (working
On Fri, 2014-09-05 at 10:43 -0600, Jeff Law wrote:
On 09/05/14 09:32, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
Hi,
Doing this means we get to remove a fair chunk of runtime checking.
bootstrapped + regtested on x86_64-unknown-linux-gnu with no
This patch replaces the target macros SF_SIZE, DF_SIZE, XF_SIZE and
TF_SIZE, used to tell libgcc the number of bits in the mantissas of
floating-point modes, with __LIBGCC_SF_MANT_DIG__ etc. macros defined
if -fbuilding-libgcc for all floating-point modes. Various libgcc
logic to determine
On Fri, Sep 05, 2014 at 05:57:13PM -0400, David Malcolm wrote:
On Fri, 2014-09-05 at 10:43 -0600, Jeff Law wrote:
On 09/05/14 09:32, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
Hi,
Doing this means we get to remove a fair chunk of runtime checking.
...
I believe the above hunk in r214954 ...
... broke the build for the
following configurations in contrib/config-list.mk: ...
See pr63188 for darwin. The same patch should probably
fix the problem for hppa64-hpux* too.
Dominique
On Sep 5, 2014, at 3:59 PM, Dominique Dhumieres domi...@lps.ens.fr wrote:
See pr63188 for darwin. The same patch should probably
fix the problem for hppa64-hpux* too.
Thanks.
Committed revision 214983.
Index: ChangeLog
===
---
87 matches
Mail list logo
