> 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-cpu=niagara3.
>
> Eric, any objections to committing this?
Only a minor one:
> @@ -1088,7 +1093,12 @@ sparc_option
Hi,
2012/11/14 Jason Merrill :
> 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.
I'm a bit puzzled by your suggestion, altough I have not tried it yet,
how can it work gi
On 2012.11.14 at 08:21 -0800, H.J. Lu wrote:
> 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
The attached patch includes t-glibc instead of t-linux in config.gcc.
Alexander
On Wed, Nov 14, 2012 at 07:51:05PM -0800, H.J. Lu wrote:
> 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-
On Wed, Nov 14, 2012 at 06:24:22PM +0400, Yuri Rumyantsev wrote:
> 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
Hi,
as observed on PR54717 we give up on some partial insertions because of
Skipping partial partial redundancy for expression
{array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165) not
partially anticipated on any to be optimized for speed edges
The logic here is wrong, the edges are tested by o
Maybe Konstantin could Help with the review, as this touches libsanitizer?
Cheers.
Mike Stump writes:
> 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
David Miller wrote
> 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.
So, her
Am 15.11.2012 09:51, schrieb Alexander Monakov:
> The attached patch includes t-glibc instead of t-linux in config.gcc.
thanks for the pointer. updated patch attached below.
Matthias
2012-11-14 Matthias Klose
* config/ia64/t-linux: New file; define MULTIARCH_DIRNAME.
* config.gcc (tmak
> re-attaching the updated patch with the fixed comment in genmultilib.
This has introduced:
make[3]: Leaving directory `/red.a/gnatmail/gcc-x/build-red/x86_64-
linux/gnat/obj/libdecnumber'
make[3]: Entering directory `/red.a/gnatmail/gcc-x/build-red/x86_64-
linux/gnat/obj/gcc'
Makefile:538: Extr
Am 15.11.2012 12:41, schrieb Eric Botcazou:
>> re-attaching the updated patch with the fixed comment in genmultilib.
>
> This has introduced:
>
> make[3]: Leaving directory `/red.a/gnatmail/gcc-x/build-red/x86_64-
> linux/gnat/obj/libdecnumber'
> make[3]: Entering directory `/red.a/gnatmail/gcc-x
Eric Botcazou writes:
>> Now that we're in C++, I think we should be using iterators that are much
>> more in the style of libstdc++. I agree that the .next interface used here
>> is a bit confusing.
>>
>> I'd expect to see something like
>>
>> for (bit_field_mode_iterator i(x,y,z); i ; ++i)
Thanks for the reviews.
Eric Botcazou writes:
>> This patch makes bit_field_mode_iterator take -fstrict-volatile-bitfields
>> into account, in cases where the size of the underlying object is known.
>> This is used in the next patch.
>
> Do we really need to add that to the iterator? The -fstric
Diego Novillo writes:
> (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
> Hi,
> as observed on PR54717 we give up on some partial insertions because of
> Skipping partial partial redundancy for expression
> {array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165) not
> partially anticipated on any to be optimized for speed edges
>
> The logic here is wrong, the edges a
Jakub Jelinek writes:
> 2012-11-12 Jakub Jelinek
>
> * asan.c (report_error_func): Set DECL_IGNORED_P, don't touch
> DECL_ASSEMBLER_NAME.
> (asan_init_func): Likewise.
> (asan_finish_file): Use void * instead of __asan_global * as
> type of __asan_{,un}register_gl
On 2012-11-05 06:54 , Eric Botcazou wrote:
Those compiler generated statements do not have source origins, but
they need to have debug location information attached so that
information collected for them can be correlated with program
constructs (such as CFG). One of the natural way is to use the
On Thu, Nov 15, 2012 at 12:34:07AM +0100, Jan Hubicka wrote:
> * params.def (max-peeled-insns, max-completely-peeled-insns): Reduce to
> 100.
Ok, thanks.
> --- params.def(revision 193505)
> +++ params.def(working copy)
> @@ -290,7 +290,7 @@ DEFPARAM(PARAM_MAX_UNROLL_TIMES,
Hi,
Here's an updated version of the patch which warns the user if the
removing of redundant exits results in an infinite loop. I have added
an additional flag in struct loop called external_exits to record if
an exit edge is moved outside the loop body. This currently happens in
the loop-unswit
Hi,
> >> 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 patch has fallen off the bottom o
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 implementation etc.).
> We don't wrap the syscalls in
On Thu, Nov 15, 2012 at 12:47 AM, Markus Trippelsdorf
wrote:
> On 2012.11.14 at 08:21 -0800, H.J. Lu wrote:
>> 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
On Thu, Nov 15, 2012 at 1:26 AM, Jakub Jelinek wrote:
> On Wed, Nov 14, 2012 at 07:51:05PM -0800, H.J. Lu wrote:
>> 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
On 2012.11.15 at 06:01 -0800, H.J. Lu wrote:
> On Thu, Nov 15, 2012 at 12:47 AM, Markus Trippelsdorf
> wrote:
> > On 2012.11.14 at 08:21 -0800, H.J. Lu wrote:
> >> 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.
> >> >
> >>
Hi,
Current HEAD fails build when --enable-languages=c, i.e. C++ is not
being built. Attached patch fixes this.
Regards,
Siddhesh
ChangeLog:
2012-11-15 Siddhesh Poyarekar
* configure.ac: Disable libsanitizer if we're not building C++.
* configure: Regenerate.
diff --git a/
David Miller writes:
> I started working on this patch again, in order to incorporate
> Richard Henderson's feedback, and I am now getting a comparison
> failure. Is this what you're seeing?
>
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1plus-checksum.o diff
Dmitry Vyukov writes:
> Does it look good to you (not yet committed)?
> (Dodji, I've replaced spaces with tabs in your record)
[...]
> Index: MAINTAINERS
> ===
> --- MAINTAINERS (revision 193530)
> +++ MAINTAINERS (working copy)
> @@
On 15/11/12 12:38, Dodji Seketeli wrote:
diff --git a/MAINTAINERS b/MAINTAINERS
index adec7a4..825c602 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -294,6 +294,7 @@ register allocation Peter Bergner
berg...@vnet.ibm.com
register allocation Kenneth Zadeck zad...@naturalbri
Dmitry Vyukov writes:
> To what section do I need to add myself? There are "Reviewers" and
> "Various Maintainers".
"Reviewers" since that's what the Steering Committee's message mentioned.
Rainer
--
-
Rainer
On Thu, Nov 15, 2012 at 6:19 AM, Markus Trippelsdorf
wrote:
> On 2012.11.15 at 06:01 -0800, H.J. Lu wrote:
>> On Thu, Nov 15, 2012 at 12:47 AM, Markus Trippelsdorf
>> wrote:
>> > On 2012.11.14 at 08:21 -0800, H.J. Lu wrote:
>> >> On Tue, Nov 13, 2012 at 3:48 PM, Paolo Bonzini wrote:
>> >> > Il 1
On 11/15/2012 03:33 AM, Fabien Chêne wrote:
2012/11/14 Jason Merrill :
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.
I'm a bit puzzled by your suggestion, altough I have
On 2012-11-15 09:43 , Dmitry Vyukov wrote:
Does it look better? (still in Reviewers section)
Looks fine. Thanks.
Incidentally, Dodji, now that I look at your entry. I think making
yours state "libsanitizer, asan.c" would be better.
Diego.
> Current HEAD fails build when --enable-languages=c, i.e. C++ is not
> being built. Attached patch fixes this.
Eh???
Isn't C++ always built, because gcc itself requires it?
Ciao!
Steven
The attached patch assumes that the current 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 confi
On Thu, Nov 15, 2012 at 06:54:43PM +0400, Dmitry Vyukov wrote:
> Yes, I think people will search by "libsanitizer" (or "asan").
>
> Do I need to add Jakub Jelinek as reviewer as well?
I can add myself after you commit it, or you can add me.
Jakub
Hi,
On Thu, 15 Nov 2012, Steven Bosscher wrote:
> > Current HEAD fails build when --enable-languages=c, i.e. C++ is not
> > being built. Attached patch fixes this.
>
> Eh???
Uhh???
> Isn't C++ always built, because gcc itself requires it?
Without bootstrapping it doesn't, no.
Ciao,
Michael
On Thu, Nov 15, 2012 at 9:37 AM, Richard Earnshaw wrote:
> [1] Am I the only one who finds the name somewhat cryptic?
It's just a name :) No more cryptic than "mudflap". Took me a while
to get used to that one!
Kostya et al have a family of sanitizers now and they are all
abbreviated similar
On Thu, Nov 15, 2012 at 07:07:46PM +0400, Dmitry Vyukov wrote:
> On Thu, Nov 15, 2012 at 6:56 PM, Jakub Jelinek wrote:
>
> > On Thu, Nov 15, 2012 at 06:54:43PM +0400, Dmitry Vyukov wrote:
> > > Yes, I think people will search by "libsanitizer" (or "asan").
> > >
> > > Do I need to add Jakub Jelin
On Thu, Nov 15, 2012 at 6:44 AM, H.J. Lu wrote:
> On Thu, Nov 15, 2012 at 6:19 AM, Markus Trippelsdorf
> wrote:
>> On 2012.11.15 at 06:01 -0800, H.J. Lu wrote:
>>> On Thu, Nov 15, 2012 at 12:47 AM, Markus Trippelsdorf
>>> wrote:
>>> > On 2012.11.14 at 08:21 -0800, H.J. Lu wrote:
>>> >> On Tue, N
On Thu, Nov 15, 2012 at 5:56 AM, Dodji Seketeli wrote:
> David Miller wrote
>
>> 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 h
On Thu, Nov 15, 2012 at 11:25:55AM +0100, Jan Hubicka wrote:
> PR tree-optimization/54717
> * tree-ssa-pre.c (do_partial_partial_insertion): Consider also edges
> with ANTIC_IN.
As Richard is still away, Steven, could you please comment on this?
> Index: tree-ssa-pre.c
> ===
This patch reorganizes the AArch64 sfp-machine.h file, splitting out
FP_HANDLE_EXCEPTIONS into a new file sfp-exceptions.c following the same
idiom used in ia64 and i386.
OK ?
Cheers
/Marcus
2012-11-15 Marcus Shawcroft
* config/aarch64/sfp-machine.h (FP_RND_MASK): Define.
(
On Thu, Nov 15, 2012 at 7:14 AM, H.J. Lu wrote:
> On Thu, Nov 15, 2012 at 6:44 AM, H.J. Lu wrote:
>> On Thu, Nov 15, 2012 at 6:19 AM, Markus Trippelsdorf
>> wrote:
>>> On 2012.11.15 at 06:01 -0800, H.J. Lu wrote:
On Thu, Nov 15, 2012 at 12:47 AM, Markus Trippelsdorf
wrote:
> On 2
Il 15/11/2012 17:02, H.J. Lu ha scritto:
>>> >> I can reproduce it with --enable-version-specific-runtime-libs. I am
>>> >> taking a look.
>>> >>
>> >
>> > I am checking in this patch.
>> >
> This is what I checked in.
libssp et al. do not need any of this stuff.
What's special about libsanitize
It's OK for a static data member of a dependent class instantiation to
still have 'auto' type, because we can't instantiate its initializer
yet. So let's not bother complaining about auto decls in templates.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 10c430cf47ad234b240b06d4efdecdab
On Thu, Nov 15, 2012 at 1:35 AM, Uros Bizjak wrote:
> 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 fl
On Thu, Nov 15, 2012 at 08:17:34PM +0400, Dmitry Vyukov wrote:
> +2012-11-15 Dmitry Vyukov
> +
> + * MAINTAINERS: (libsanitizer, asan.c): Add myself,
> + Kostya Serebryany (k...@google.com) and
> + Jakub Jelinek (ja...@redhat.com).
> + Rename area for Dodji Seketeli (do...@redhat.com).
If there
On Thu, Nov 15, 2012 at 05:20:48PM +0100, Uros Bizjak wrote:
> This revision auto-detect support for Q and W suffixes.
>
> 2012-11-15 Uros Bizjak
>
> * lib/target_suports.exp
> (check_effective_target_has_w_floating_suffix): New procedure.
> (check_effective_target_has_q_floa
On Thu, Nov 15, 2012 at 8:08 AM, Paolo Bonzini wrote:
> Il 15/11/2012 17:02, H.J. Lu ha scritto:
>> I can reproduce it with --enable-version-specific-runtime-libs. I am
>> taking a look.
>>
>>> >
>>> > I am checking in this patch.
>>> >
>> This is what I checked in.
>
> libssp et a
Il 15/11/2012 17:28, H.J. Lu ha scritto:
> On Thu, Nov 15, 2012 at 8:08 AM, Paolo Bonzini wrote:
>> Il 15/11/2012 17:02, H.J. Lu ha scritto:
>>> I can reproduce it with --enable-version-specific-runtime-libs. I am
>>> taking a look.
>>>
>
> I am checking in this patch.
>
>
On Thu, Nov 15, 2012 at 5:25 PM, Jakub Jelinek wrote:
> On Thu, Nov 15, 2012 at 05:20:48PM +0100, Uros Bizjak wrote:
>> This revision auto-detect support for Q and W suffixes.
>>
>> 2012-11-15 Uros Bizjak
>>
>> * lib/target_suports.exp
>> (check_effective_target_has_w_floating_suffi
> ahh, this is with GNU make 3.80. Checked in the following patch as obvious.
Thanks!
--
Eric Botcazou
On Thu, Nov 15, 2012 at 05:31:42PM +0100, Uros Bizjak wrote:
> No, the intention of this test is to check if target can handle these
> suffixes through TARGET_C_MODE_FOR_SUFFIX. Please note that in
> particular tests, -std=x compile switches are added to compile flags.
But -std=c++11 (well, perhap
On Thu, Nov 15, 2012 at 8:22 PM, Jakub Jelinek wrote:
>
> On Thu, Nov 15, 2012 at 08:17:34PM +0400, Dmitry Vyukov wrote:
> > +2012-11-15 Dmitry Vyukov
> > +
> > + * MAINTAINERS: (libsanitizer, asan.c): Add myself,
> > + Kostya Serebryany (k...@google.com) and
> > + Jakub Jelinek (ja...@redhat.c
On Thu, Nov 15, 2012 at 5:34 PM, Jakub Jelinek wrote:
> On Thu, Nov 15, 2012 at 05:31:42PM +0100, Uros Bizjak wrote:
>> No, the intention of this test is to check if target can handle these
>> suffixes through TARGET_C_MODE_FOR_SUFFIX. Please note that in
>> particular tests, -std=x compile switch
> But UNKNOWN_LOCATION is effectively wrong as well. If other
> optimizations move the statements above the inserted instruction, then
> the new instruction ends up inheriting whatever location happens to be
> in the previous statement.
That's correct, UNKNOWN_LOCATION isn't a panacea either, alt
> On Thu, Nov 15, 2012 at 11:25:55AM +0100, Jan Hubicka wrote:
> > PR tree-optimization/54717
> > * tree-ssa-pre.c (do_partial_partial_insertion): Consider also edges
> > with ANTIC_IN.
>
> As Richard is still away, Steven, could you please comment on this?
>
> > Index: tree-ssa-pre.c
On Thu, Nov 15, 2012 at 8:46 AM, Eric Botcazou wrote:
>
> > But UNKNOWN_LOCATION is effectively wrong as well. If other
> > optimizations move the statements above the inserted instruction, then
> > the new instruction ends up inheriting whatever location happens to be
> > in the previous stateme
+dvyukov, +glider, +samsonov
Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
Alexey may submit the patch upstream.
Please make sure to comment the reason for using a separate typedef.
We need our custom unwinder based on frame pointers to remain the
default choice on x86[_64]
> The idea was to centralise the knowledge about what modes are valid
> rather than requiring every client to know the rules. From that point
> of view it seems inconsistent for the new interface to handle the
> bitregion_{start,end} restrictions (a correctness issue) but not the
> volatility rest
On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
> +dvyukov, +glider, +samsonov
>
> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
> Alexey may submit the patch upstream.
> Please make sure to comment the reason for using a separate typedef.
Here is the
On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
> +dvyukov, +glider, +samsonov
>
> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
> Alexey may submit the patch upstream.
> Please make sure to comment the reason for using a separate typedef.
>
> We need
On Thu, Nov 15, 2012 at 9:19 PM, Jakub Jelinek wrote:
> On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
>> +dvyukov, +glider, +samsonov
>>
>> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
>> Alexey may submit the patch upstream.
>> Please make sure to
Dear all,
I have committed (Rev. 193538) attached patch, which does an other
update from GLIBC.
Tobias
PS: I still want to update libquadmath's strtod and printf.
Index: libquadmath/ChangeLog
===
--- libquadmath/ChangeLog (Revisi
On Thu, Nov 15, 2012 at 05:42:32PM +0100, Uros Bizjak wrote:
> On Thu, Nov 15, 2012 at 5:34 PM, Jakub Jelinek wrote:
> > On Thu, Nov 15, 2012 at 05:31:42PM +0100, Uros Bizjak wrote:
> >> No, the intention of this test is to check if target can handle these
> >> suffixes through TARGET_C_MODE_FOR_S
> The randomness here means that if we set UNKNOWN_LOCATION to insn, it
> can get source location anywhere. Even with some small code layout
> changes, the location for that insn could change. I would hope that in
> the future, we add an assertion when emitting instruction to enforce
> that INSN_LO
On Thu, Nov 15, 2012 at 9:25 AM, Dmitry Vyukov wrote:
> On Thu, Nov 15, 2012 at 9:19 PM, Jakub Jelinek wrote:
>> On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
>>> +dvyukov, +glider, +samsonov
>>>
>>> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
>>>
The attached patch assumes that the current mach_override/mach_override.h and
mach_override/mach_override.c files have been imported by the libsanitizer
maintainers
from llvm compiler-rt svn for use by darwin. The patch adds darwin to the
supported
target list in configure.tgt and defines USIN
Eric Botcazou writes:
>> The idea was to centralise the knowledge about what modes are valid
>> rather than requiring every client to know the rules. From that point
>> of view it seems inconsistent for the new interface to handle the
>> bitregion_{start,end} restrictions (a correctness issue) bu
I am sensing some optimization here :) Is it really important to
collect the full stack trace for the allocation context? You care
about actual site where the allocation happens -- which might usually
be the calls to the malloc like wrappers. The distance from there to
the leaf should not he too fa
On Thu, Nov 15, 2012 at 9:49 AM, Xinliang David Li wrote:
> I am sensing some optimization here :) Is it really important to
> collect the full stack trace for the allocation context?
Not important if you want to *find* a bug.
Deadly important if you want to *analyze* the bug.
The free() traces
I probably made too general statement in this topic. However for the
PRE case, I believe the choice of not using UNKNOWN location is still
better.
thanks,
David
On Thu, Nov 15, 2012 at 9:23 AM, Eric Botcazou wrote:
>> The randomness here means that if we set UNKNOWN_LOCATION to insn, it
>> can
Yeah, at least for the unittest I provided, the coverage info will be
wrong without the patch.
Thanks,
Dehao
On Thu, Nov 15, 2012 at 10:30 AM, Xinliang David Li wrote:
> I probably made too general statement in this topic. However for the
> PRE case, I believe the choice of not using UNKNOWN loc
On Thu, Nov 15, 2012 at 5:44 PM, Jakub Jelinek wrote:
>> >> No, the intention of this test is to check if target can handle these
>> >> suffixes through TARGET_C_MODE_FOR_SUFFIX. Please note that in
>> >> particular tests, -std=x compile switches are added to compile flags.
>> >
>> > But -std=c++
2012-11-15 Roland McGrath
* MAINTAINERS (Write After Approval): Add myself.
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -457,6 +457,7 @@ Simon Martin
simar...@users.sourceforge.net
Ranjit Mathew rmat...@hotmail.com
M
From: Eric Botcazou
Date: Thu, 15 Nov 2012 09:16:26 +0100
>> 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-cpu=niagara3.
>>
>> Eric, any objections to committin
> OK. The current recursive force-mem-to-reg cases in store_bit_field_1
> and extract_bit_field_1 don't handle -fstrict-volatile-bitfields at all,
> so this patch was trying to fix what seemed like an oversight. Is it OK
> to leave the code as-is (not handling -fstrict-volatile-bitfields),
> or d
Hi,
this is the build failure of the Ada runtime on the ARM:
+===GNAT BUG DETECTED==+
| 4.8.0 2012 (experimental) (armv5tel-unknown-linux-gnueabi) GCC error:|
| in merge_latch_edges, at cfgloop.c:678 |
| Err
On Thu, Nov 01, 2012 at 08:52:33PM +0100, do...@redhat.com wrote:
> From: Dodji Seketeli
>
> Hello,
>
> The set of patches following this message represents the work that
> happened on the asan branch to build up the Address Sanitizer work
> started in the Google branch.
>
> Address Sanitizer (
Eric Botcazou writes:
>> expand_assignment calls:
>>
>>if (MEM_P (to_rtx))
>> {
>>/* If the field is at offset zero, we could have been given
>> the DECL_RTX of the parent struct. Don't munge it. */ to_rtx =
>> shallow_copy_rtx (to_rtx);
>>
>>
On 11/15/2012 11:34 AM, Eric Botcazou wrote:
> The problem is that get_loop_latch_edges finds no latch edges for a loop
> because the header of the loop doesn't dominate any of its predecessors.
> The reason is that a new edge is added during RTL expansion, which changes
> the
> dominance info.
r~
PS: ARM still uses sjlj exceptions for Ada? I thought with the obsolescence
of pre-eabi targets that we'd always use unwind tables now.
I believe this is by choice because no one has yet written an unwinder
for the ARM exception tables for Ada :( .
regards,
Ramana
On 11/15/2012 12:01 PM, Ramana Radhakrishnan wrote:
> I believe this is by choice because no one has yet written an unwinder for
> the ARM exception tables for Ada :( .
Ada is supposed to be using the same libgcc unwinder as the rest of
the compiler. So this cannot be it, exactly.
Perhaps some
Hi!
case SIZEOF_EXPR: shares the code with case ALIGNOF_EXPR, but only on the
former one can use SIZEOF_EXPR_TYPE_P. Fixed thusly,
bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-11-15 Jakub Jelinek
PR c++/55337
* tree.c (cp_tree_equal) : Use SIZEOF_
Hi!
On the following testcase substitute_and_fold ICEs because memmove
of length 1 on an empty class is optimized away, and this function wasn't
prepared to handle that.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/4.7?
2012-11-15 Jakub Jelinek
PR
Revised patch that fixes failures encountered when enabling
-freorder-blocks-and-partition, including the failure reported in PR 53743.
This includes new verification code to ensure no cold blocks dominate hot
blocks contributed by Steven Bosscher.
I attempted to make the handling of partition up
Hi!
On the following testcase we ICE, because tree_ssa_dominator_optimize
modifies the bitmap while iterating it. In particular, it contained just
a single bit in it, bitmap_clear_bit turned the bitmap into empty bitmap and
bitmap_set_bit on a lower bit reused the same bitmap_element with lower
i
OK.
Jason
On 11/15/12 20:05, Richard Henderson wrote:
On 11/15/2012 12:01 PM, Ramana Radhakrishnan wrote:
I believe this is by choice because no one has yet written an unwinder for the
ARM exception tables for Ada :( .
Ada is supposed to be using the same libgcc unwinder as the rest of
the compiler. S
On 11/15/2012 04:10 AM, Richard Sandiford wrote:
> "next" was supposed to be "find and return another mode" rather than "++".
> Did you think it was confusing because "next" sounded too much like the
> latter?
I wasn't keen on "next" being find-and-return, though I didn't
actually find it confusi
On Fri, 9 Nov 2012, Andrew Pinski wrote:
> Committed the testcase as obvious after a quick test to make sure it
> works. Note someone might need to mark the testcase as only
> executable on targets which have 32bit ints.
Someone like you? There are plenty of greppable
effective-target attributes
Andrew Pinski writes:
> 2012-07-26 Andrew Pinski
>
> Bug #3261
> * config/mips/mips.md (*mov_on_):
> Remove mode check from comparisons.
> (*mov_on_): Likewise.
> (*mov_on__ne): New pattern to match
> when (ne A 0) can be just A.
>
> * tes
Jia Liu writes:
> 2012-11-15 Jia Liu
>
>* gcc/doc/invoke.texi: Add microMIPS option.
I'd rather leave this until the GCC support is added. Mentor have some
patches for this, but I'm afraid I keep finding things to complain about...
FWIW, the last on-list discussion about it was:
On Thu, Nov 15, 2012 at 12:58 PM, Richard Sandiford
wrote:
> Andrew Pinski writes:
>> 2012-07-26 Andrew Pinski
>>
>> Bug #3261
>> * config/mips/mips.md (*mov_on_):
>> Remove mode check from comparisons.
>> (*mov_on_): Likewise.
>> (*mov_on__ne): New pattern to
On Thu, Nov 15, 2012 at 1:24 PM, Andrew Pinski
wrote:
> On Thu, Nov 15, 2012 at 12:58 PM, Richard Sandiford
> wrote:
>> Andrew Pinski writes:
>>> 2012-07-26 Andrew Pinski
>>>
>>> Bug #3261
>>> * config/mips/mips.md (*mov_on_):
>>> Remove mode check from comparisons.
>>>
I have split the VEC rewrite into 25 patches. The only patches that
make actual changes are #1 (vec.c and vec.h) and #2 (gengtype). All
the others are mechanical side-effects from the first patch.
I will still appreciate if maintainers can take a look at the other
patches to make sure I have not
This patch removes the special handling for VEC() that used to exist in
gengtype.
Additionally, it allows gengtype to recognize templates of more than
one argument and introduces the concept of an undefined type (useful
for template arguments that may or may not be types).
When a TYPE_UNDEFINED
On Thu, Nov 15, 2012 at 12:02 AM, Jakub Jelinek wrote:
> 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
[ The patch is too big for e-mail. It's available at
http://www.airs.com/~dnovillo/pub/vec-rewrite/06vec.diff ]
2012-11-15 Diego Novillo
Adjust for new vec API (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec)
* coretypes.h (uchar): Define.
* alias.c: Use new vec API
1 - 100 of 140 matches
Mail list logo
