On Sep 5, 2014, at 3:59 PM, Dominique Dhumieres wrote:
> See pr63188 for darwin. The same patch should probably
> fix the problem for hppa64-hpux* too.
Thanks.
Committed revision 214983.
Index: ChangeLog
===
--- ChangeLog (revisi
...
> 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 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
> > >
> > > Hi,
> > >
> > > Doing this means we get to remove a fair chunk of runtime checking.
> >
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 default
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
> >
> > 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.
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 copy
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
> From: "Joseph S. Myers"
> 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 correction here: it wa
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 simpl
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 [mailto:gcc-patches-
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 t
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
> >>> calls within NEXT_INSN and PREV_INSN; do you happen to have
> >>> inf
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
calls within NEXT_INSN and PREV_INSN; do you happen to have
information handy on that?
Yes that's right:
- 1.03% lto1
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 suppo
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 machine_mo
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 simplify_shift_c
On Fri, Sep 5, 2014 at 3:00 AM, 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 definite
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 Merr
On Fri, Sep 5, 2014 at 1:48 PM, Segher Boessenkool
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.) This
> ensure
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
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 s
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 pas
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).
Si
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 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 i
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
> >
> >Hi,
> >
> > Doing this means we get to remove a fair chunk of runtime checking.
> >
> >bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressio
On Sep 5, 2014, at 3:10 AM, Thomas Schwinge wrote:
> Should PR20567 now be updated?
Updated.
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 thes
On 5 September 2014 17:10, Yury Gribov 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 enables GNU style gl
On 09/05/14 09:32, tsaund...@mozilla.com wrote:
From: Trevor Saunders
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
On 09/05/14 09:32, tsaund...@mozilla.com wrote:
From: Trevor Saunders
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/
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
Richard Biener writes:
> 2014-09-05 Richard Biener
>
> * 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 (fix_loop_structure): Sanity check
>> > 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.
unmodi
Hi!
On Tue, 06 Jan 2009 00:10:02 +0200, Janne Blomqvist
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
>
> PR libfortra
On 4 September 2014 19:19, Venkataramanan Kumar
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
>
> * config/aarch64/aarch64.md (stack_protect_test_) Add r
From: Trevor Saunders
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, config/sh/sh.c, cprop.c, dwarf2o
From: Trevor Saunders
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, config/i386/i386.md, co
On Mon, Sep 1, 2014 at 4:18 AM, Michael Hudson-Doyle
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
> something?
You aren
On Thu, Sep 4, 2014 at 6:15 PM, Joseph S. Myers wrote:
>
> gcc/c-family:
> 2014-09-05 Joseph Myers
>
> * c-cppbuiltin.c (c_cpp_builtins): Also define
> __LIBGCC_EH_TABLES_CAN_BE_READ_ONLY__,
> __LIBGCC_EH_FRAME_SECTION_NAME__, __LIBGCC_JCR_SECTION_NAME__,
> __LIB
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 upda
On Fri, 2014-09-05 at 14:03 +0100, Richard Sandiford wrote:
> David Malcolm 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,
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
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 linke
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 differe
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: b
On 5 September 2014 14:46, David Sherwood 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 test cases. Is th
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 ina
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: c-c++-common/ubsan/float-cast-ove
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 0
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 r
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
To: Jef
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.
Reg
On Fri, Aug 22, 2014 at 11:36 AM, Kyrill Tkachov 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 instructions to be treate
> OK.
Committed revision 214958.
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
>
> PR fortran/62245
> * intrinsic.texi (INT): clarify result.
>
OK.
--
Steve
On 09/04/2014 09:23 PM, Mike Stump wrote:
On Sep 4, 2014, at 4:14 AM, Ramana Radhakrishnan
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 check_effective_target_arm_ve
David Malcolm 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 sequence? */
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-dependen
Mike Stump 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 into
execute/ieee.
> >The last sentence above is not needed.
So, revised patch without the last sentence.
2014-09-05 Joost VandeVondele
PR fortran/62245
* intrinsic.texi (INT): clarify result.
Index: fortran/intrinsic.texi
===
---
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 f
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 wrote:
The SIMD-register variant is miscategorized as "alu_reg" despite not
Hi!
On Fri, 22 Aug 2014 14:18:32 +0200, Bernd Schmidt
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/.
> >> So, please j
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
* config/arm/cortex-a
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 h
On Fri, Sep 5, 2014 at 3:33 AM, Kugan 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 computed according to
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
> @
Hi!
On Fri, 29 Aug 2014 14:36:17 +, "Zamyatin, Igor"
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 regtested on x86_64.
> Is
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 -fsaniti
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
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
* cfgloop.c (mark_loop_for_removal): New function.
* cfgloop.h (mark_loop_for_removal):
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 userspace
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 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,
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
* config/arm/cortex-a53.md (cortex_a53_alu_shift): Add alu_ext,
alus_ext.commit bcf28
On Fri, Sep 5, 2014 at 4:38 AM, Aldy Hernandez wrote:
> On 09/04/14 03:42, Richard Biener wrote:
>>
>> On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez wrote:
>
>
>> Flow-wise I still want to move hand-off to the cgraph code to toplev.c,
>> out from the FEs final_write_gloabals hook:
>>
>>/* Th
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 tha
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 for
On Fri, Sep 5, 2014 at 12:12 PM, Yury Gribov 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 in sanitize
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 Gree
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.
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 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
Ramana Radhakrishnan
* config/aarch64/aarch64-elf-raw.h (ENDFILE_SPEC): Add
crtfastmath.o.
* config/aarch64/aar
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
On Fri, Sep 5, 2014 at 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 p
86 matches
Mail list logo
