On Tue, 9 Jun 2015, Pierre-Marie de Rodat wrote:
> Hello,
>
> With the recent work for PR debug/65549, we observed a regression in the
> generated debugging information. Take the attached reproducer, build it and
> look at the output DWARF:
>
> $ gcc -c -O1 -g foo.c
> $ objdump --dwarf
Carrot Wei writes:
> Index: simplify-got.c
> ===
> --- simplify-got.c (revision 224174)
> +++ simplify-got.c (working copy)
> @@ -169,7 +169,10 @@
>
>/* Since there is no usage of pic_reg now, we can remove it. */
>if (use)
>
Uros Bizjak writes:
> On Tue, Jun 9, 2015 at 9:30 PM, Jakub Jelinek wrote:
>> On Tue, Jun 09, 2015 at 08:09:28PM +0200, Uros Bizjak wrote:
>>> Please find attach a patch that takes your idea slightly further. We
>>> find perhaps zero-extended UNSPEC_TP, and copy it for further use. At
>>> its pl
On Tue, Jun 9, 2015 at 9:30 PM, Jakub Jelinek wrote:
> On Tue, Jun 09, 2015 at 08:09:28PM +0200, Uros Bizjak wrote:
>> Please find attach a patch that takes your idea slightly further. We
>> find perhaps zero-extended UNSPEC_TP, and copy it for further use. At
>> its place, we simply slap const0_
Hi, all.
I noticed that defaults.h file contains stub generator functions which
simply call gcc_unreachable. FWIW, Trevor added them to remove some
conditional compilation which depends on HAVE_ macros (I mean
something like r223624).
Because we still have ~80 more such conditions in GCC, and pro
Hi,
this patch makes warn_type_compatibility_p to use TYPE_CANONICAL rather than
types_compatible_p to decide about warnings on type mismatches.
types_compatible_p is way too precise. It insist on oprations among the types
to be compatible. This is not necessary here as accesses are wrapped in MEM_
Updated patches were attached. Rebased on the latest 4.9 branch.
Tested on aarch64-linux (big-endian and little-endian) with qemu.
OK for 4.9?
The first patch:
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 223867)
+++ g
On Sun, May 3, 2015 at 5:29 PM, Patrick Palka wrote:
> On Sun, Apr 26, 2015 at 8:56 PM, Patrick Palka wrote:
>> Here is an updated version of the patch with, hopefully, all your
>> suggestions made. I decided to add calls to STRIP_NOPS before emitting
>> the warning so that we properly warn for
On Tue, Jun 9, 2015 at 3:26 PM, Michael Meissner
wrote:
> On Tue, Jun 09, 2015 at 02:17:19PM -0500, Segher Boessenkool wrote:
>> On Tue, Jun 09, 2015 at 02:00:48PM -0400, Michael Meissner wrote:
>> > +asm ("xvadddp %x0,%x1,%x2" "=wa" (v1) : "wa" (v2), "wa" (v3));
>>
>> A colon went missing?
On Jun 5, 2015, Alexandre Oliva wrote:
> On Apr 27, 2015, Richard Biener wrote:
>>> +/* Return the promoted mode for name. If it is a named SSA_NAME, it
>>> + is the same as promote_decl_mode. Otherwise, it is the promoted
>>> + mode of a temp decl of same type as the SSA_NAME, if we had
ok.
David
On Tue, Jun 9, 2015 at 4:46 PM, Carrot Wei wrote:
> Hi
>
> I forgot to notify df framework when I removed an insn, it caused df
> verification failure described in google bug b/16155462.
>
> The following patch passed regression test on arm qemu in both thumb
> and arm modes.
> OK for
Hi
I forgot to notify df framework when I removed an insn, it caused df
verification failure described in google bug b/16155462.
The following patch passed regression test on arm qemu in both thumb
and arm modes.
OK for google 4.9 branch?
Index: simplify-got.c
==
Hi Tom!
On Tue, 9 Jun 2015 16:12:12 +0200, Tom de Vries wrote:
> On 09/06/15 13:07, Richard Biener wrote:
> > On Mon, 8 Jun 2015, Tom de Vries wrote:
> >
> >> On 17/04/15 12:08, Tom de Vries wrote:
> >>> On 20-03-15 12:38, Tom de Vries wrote:
> On 19-03-15 12:05, Tom de Vries wrote:
> >
gcc/
* config/xtensa/xtensa.h (TARGET_DEBUG): New definition.
* config/xtensa/xtensa.md (define_attr "type"): New type "trap".
(define_insn "trap"): New definition.
---
Changes v1->v2:
- drop break.n, replace break 0, 0 with break 1, 15, coded breakpoint
that transfers con
Hi,
I constructed this testcase as I anticipated a bogus warning. It does not happen
because C_FUNPTR is function pointer and useless_type_conversion does not look
into function signature, but it is still useful testcase to have.
Once we start to do TBAA for pointers, we will end up in need to glob
Hello,
With the recent work for PR debug/65549, we observed a regression in the
generated debugging information. Take the attached reproducer, build it
and look at the output DWARF:
$ gcc -c -O1 -g foo.c
$ objdump --dwarf=info foo.o
[...]
<2><4e>: Abbrev Number: 3 (DW_TAG
Alex, I sent you a pre-processed file off-list. You could try
bootstrapping on PPC64 on the GCC Compile Farm.
The SPARC failure reports a different error than PPC and ARM. The PPC
and ARM failures are the same message, but seem to be on different
files.
After the breakage from Aldy's patch all
> I'll look into cross-building some embedded targets and see if any
> further issues surface.
SPARC is also broken, see my message and the tescase under the PR.
--
Eric Botcazou
On Tue, 2015-06-09 at 18:19 +0200, Matthias Klose wrote:
> Install the gcc/jit header files without the x bit set. Ok for the trunk and
> the
> 5 branch?
OK.
On Tue, Jun 09, 2015 at 05:11:45PM -0300, Alexandre Oliva wrote:
> On Jun 9, 2015, Alexandre Oliva wrote:
>
> > On Jun 9, 2015, David Edelsohn wrote:
> >> This also broke bootstrap on PPC64 LE Linux with the same error.
>
> > Thanks for your reports. I'm looking into the problem.
>
> > I'd
On Tue, Jun 09, 2015 at 09:36:08PM +0300, Ilya Verbin wrote:
> On Wed, Apr 29, 2015 at 14:06:44 +0200, Jakub Jelinek wrote:
> > [...] The draft requires only alloc or to
> > (or always, variants) for enter data and only from or delete (or always,
> > variants) for exit data, so in theory it is poss
On Jun 9, 2015, Alexandre Oliva wrote:
> On Jun 9, 2015, David Edelsohn wrote:
>> This also broke bootstrap on PPC64 LE Linux with the same error.
> Thanks for your reports. I'm looking into the problem.
> I'd appreciate a preprocessed testcase from either of you to confirm the
> fix, if no
On Tue, Jun 9, 2015 at 3:46 PM, Richard Biener
wrote:
> On Fri, May 29, 2015 at 3:14 PM, Evgeniya Maenkova
> wrote:
>> Hi Richard,
>>
>> Here is some explanation. I hope you let me know if I need to clarify
>> something.
>>
>> Also, you asked me about concrete example, to make sure you don’t mis
On Tue, Jun 09, 2015 at 08:09:28PM +0200, Uros Bizjak wrote:
> Please find attach a patch that takes your idea slightly further. We
> find perhaps zero-extended UNSPEC_TP, and copy it for further use. At
> its place, we simply slap const0_rtx. We know that address to
Is that safe? I mean, the ad
On Tue, Jun 09, 2015 at 02:17:19PM -0500, Segher Boessenkool wrote:
> On Tue, Jun 09, 2015 at 02:00:48PM -0400, Michael Meissner wrote:
> > +asm ("xvadddp %x0,%x1,%x2" "=wa" (v1) : "wa" (v2), "wa" (v3));
>
> A colon went missing? ^^^
Yes, I will correct it when I check it in. Thanks.
--
On Tue, Jun 09, 2015 at 02:00:48PM -0400, Michael Meissner wrote:
> +asm ("xvadddp %x0,%x1,%x2" "=wa" (v1) : "wa" (v2), "wa" (v3));
A colon went missing? ^^^
Segher
On Tue, Jun 9, 2015 at 6:21 PM, Jakub Jelinek wrote:
> On Tue, Jun 09, 2015 at 06:16:32PM +0200, Uros Bizjak wrote:
>> > something? Would it be acceptable to just guard the changes in the patch
>> > with !TARGET_X32 and let H.J. deal with that target? I'm afraid I'm lost
>> > when to ZERO_EXTEND
On Wed, Apr 29, 2015 at 14:06:44 +0200, Jakub Jelinek wrote:
> [...] The draft requires only alloc or to
> (or always, variants) for enter data and only from or delete (or always,
> variants) for exit data, so in theory it is possible to figure that from
> the call without extra args, but not so fo
On Jun 9, 2015, David Edelsohn wrote:
> This also broke bootstrap on PPC64 LE Linux with the same error.
Thanks for your reports. I'm looking into the problem.
I'd appreciate a preprocessed testcase from either of you to confirm the
fix, if not to help debug it.
Thanks in advance,
--
Alexa
A user pointed out that we never documented the requirement to use %x in the
ouptut template when VSX registers are used. This patch adds the necessary
documentation. Is it ok to install in the trunk and the open release branches?
2015-06-09 Michael Meissner
PR target/66474
*
This patch removes the function is_first_nonwhitespace_on_line() in
favor of augmenting the function get_visual_column() to optionally
return the visual column corresponding to the first non-whitespace character
on the line. Existing usage of is_first_nonwhitespace_on_line() can
be trivially repla
This patch improves the heuristics of the warning in a number of ways.
The improvements are hopefully adequately documented in the code
comments.
The additions to the test case also highlight the improvements.
I tested an earlier version of this patch on more than a dozen C code
bases. I only fo
This patch refactors the entry point of -Wmisleading-indentation from:
void
warn_for_misleading_indentation (location_t guard_loc,
location_t body_loc,
location_t next_stmt_loc,
enum cpp_tt
The infrastructure for atomic operations in the rs6000 port has not
utilized the cleaner GCC internal APIs for manipulating memmodel. The
appended patch converts the direct casts and use of memmodel_from_int
to consistently use memmodel_base. This also allows the SYNC variants
to be removed from
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > >
> > > I think we should instead work towards eliminating the get_alias_set
> > > langhook first. The LTO langhook variant contains the same handling, btw,
> > > so just inline that into get_alias_set and see what remains?
> >
> > I see, i complet
On 05/07/2015 12:45 PM, Jason Merrill wrote:
We also need to adjust digest_init_r.
This was only needed because we weren't calling reshape_init. Now that
Paolo has fixed that, this can become an assert.
commit 8d2793c42fc3de4a0b665f4c2ff2a2946ae0beda
Author: Jason Merrill
Date: Tue Jun
On Tue, Jun 09, 2015 at 06:16:32PM +0200, Uros Bizjak wrote:
> > something? Would it be acceptable to just guard the changes in the patch
> > with !TARGET_X32 and let H.J. deal with that target? I'm afraid I'm lost
> > when to ZERO_EXTEND addr (if needed at all), etc.
>
> If you wish, I can take
This also broke bootstrap on PPC64 LE Linux with the same error.
- David
Install the gcc/jit header files without the x bit set. Ok for the trunk and the
5 branch?
Matthias
gcc/jit/
2015-06-09 Matthias Klose
* Make-lang.in (jit.install-common): Install headers using INSTALL_DATA.
Index: gcc/jit/Make-lang.in
===
On Tue, Jun 9, 2015 at 4:26 PM, Jakub Jelinek wrote:
>> >> I'm afraid that simple scan loop won't work correctly on x32. There
>> >> are some issues with UNSPEC_TP for this target, so we have to generate
>> >> zero_extend of SImode UNSPEC, e.g.:
>> >>
>> >> (plus:DI (zero_extend:DI (unspec:SI [..
gcc/
* config/xtensa/xtensa.h (TARGET_DEBUG): New definition.
* config/xtensa/xtensa.md (define_attr "type"): New type "trap".
(define_insn "trap"): New definition.
---
gcc/config/xtensa/xtensa.h | 1 +
gcc/config/xtensa/xtensa.md | 15 ++-
2 files changed, 15
On targets without alias support (Darwin) bootstrap was failing with a
warning about one of the constructor clones being unused. We shouldn't
warn about that, since clones are artificial; we should only warn if the
abstract constructor is unused.
Tested x86_64-pc-linux-gnu, applying to trunk.
Hi,
the big patch below brings HSA substantially closer to nice
co-existence with the existing accelerator framework in trunk. Above
all, it implements a libgomp plugin, and with this patch applied, the
branch uses it to run the target constructs of OpenMP 4. While there
may be mistakes, I hope
On Tue, Jun 09, 2015 at 04:12:33PM +0200, Uros Bizjak wrote:
> On Tue, Jun 9, 2015 at 3:39 PM, Jakub Jelinek wrote:
> > On Tue, Jun 09, 2015 at 03:21:55PM +0200, Uros Bizjak wrote:
> >> I'm afraid that simple scan loop won't work correctly on x32. There
> >> are some issues with UNSPEC_TP for this
Hi build machinery maintainers,
since we always build the C++ compiler now, I fail to see the need to still
use RAW_CXX_TARGET_EXPORTS for libvtv.
The situation to expose the problem is:
* Use a multilib-enabled x86_64-linux box.
* Use a 64-bit (multilib-disabled) bootstrap compiler (binary image
This removes the restriction in place on reductions. To not regress
gfortran.dg/vect/fast-math-pr37021.f90 the patch also implements
SLP permutations for strided group loads. With those two pieces
we can finally SLP vectorize the complex multiplication (which
in the gfortran.dg/vect/fast-math-pr
On Tue, Jun 9, 2015 at 3:39 PM, Jakub Jelinek wrote:
> On Tue, Jun 09, 2015 at 03:21:55PM +0200, Uros Bizjak wrote:
>> I'm afraid that simple scan loop won't work correctly on x32. There
>> are some issues with UNSPEC_TP for this target, so we have to generate
>> zero_extend of SImode UNSPEC, e.g.
In this testcase we end up with the initializer for the A subobject
referring to the address of the B PLACEHOLDER_EXPR, which wasn't getting
replaced properly because when we see the A TARGET_EXPR we stopped
looking for more PLACEHOLDER_EXPRs. Instead, we need to keep looking,
and learn how to
On 09/06/15 13:07, Richard Biener wrote:
On Mon, 8 Jun 2015, Tom de Vries wrote:
On 17/04/15 12:08, Tom de Vries wrote:
On 20-03-15 12:38, Tom de Vries wrote:
On 19-03-15 12:05, Tom de Vries wrote:
On 18-03-15 18:22, Tom de Vries wrote:
Hi,
this patch fixes PR65460.
The patch marks offloa
The following patch does $subject by fixing the bogus removal of
load-permutations. This means gaps are now handled by the
permutation support (well, if the required permutation is supported).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-06-09 Richard Biener
On Tue, 9 Jun 2015, Marek Polacek wrote:
> On Tue, Jun 09, 2015 at 09:53:21AM +0200, Richard Biener wrote:
> > >> +/* (CST1 << A) == CST2 -> A == ctz (CST2) - ctz (CST1)
> > >> + (CST1 << A) != CST2 -> A != ctz (CST2) - ctz (CST1)
> > >> + if CST2 != 0. */
> > >> +(for cmp (ne eq)
> > >> + (s
On Tue, Jun 9, 2015 at 3:39 PM, Jakub Jelinek wrote:
> On Tue, Jun 09, 2015 at 03:21:55PM +0200, Uros Bizjak wrote:
>> I'm afraid that simple scan loop won't work correctly on x32. There
>> are some issues with UNSPEC_TP for this target, so we have to generate
>> zero_extend of SImode UNSPEC, e.g.
OK, thanks.
Jason
On 06/08/15 13:47, Jason Merrill wrote:
How about using a DECL_LANG_FLAG instead of creating a garbage DEFAULT_ARG?
This patch uses DECL_LANG_FLAG_2 on the FIELD_DECL to mark that its NSDMI is
being instantiated. I also discovered I'd flubbed the markup on the testcase,
not sure why I didn't
On Tue, Jun 09, 2015 at 09:53:21AM +0200, Richard Biener wrote:
> >> +/* (CST1 << A) == CST2 -> A == ctz (CST2) - ctz (CST1)
> >> + (CST1 << A) != CST2 -> A != ctz (CST2) - ctz (CST1)
> >> + if CST2 != 0. */
> >> +(for cmp (ne eq)
> >> + (simplify
> >> + (cmp (lshift INTEGER_CST@0 @1) INTEGER
On Tue, Jun 09, 2015 at 03:21:55PM +0200, Uros Bizjak wrote:
> I'm afraid that simple scan loop won't work correctly on x32. There
> are some issues with UNSPEC_TP for this target, so we have to generate
> zero_extend of SImode UNSPEC, e.g.:
>
> (plus:DI (zero_extend:DI (unspec:SI [...] UNSPEC_TP)
On Tue, Jun 9, 2015 at 3:30 PM, İsmail Dönmez wrote:
> Hi,
>
> On Tue, Jun 9, 2015 at 4:28 PM, Richard Biener
> wrote:
>> On Tue, Jun 9, 2015 at 3:11 PM, Martin Liška wrote:
>>> Hello.
>>>
>>> Following patch renames an enum values so that they do not clash with a
>>> MinGW reserved keyword.
>>
Hi,
On Tue, Jun 9, 2015 at 4:28 PM, Richard Biener
wrote:
> On Tue, Jun 9, 2015 at 3:11 PM, Martin Liška wrote:
>> Hello.
>>
>> Following patch renames an enum values so that they do not clash with a
>> MinGW reserved keyword.
>
> Reserved keyword as in a #define? Thus simply #undef it in syst
Tom de Vries wrote:
On 09/06/15 13:03, Richard Biener wrote:
On Tue, 9 Jun 2015, Alan Lawrence wrote:
Hmmm. One side effect of this is that the line number information available in
the target hook gimplify_va_arg_expr, is now just the name of the containing
function, rather than the specific u
On Tue, Jun 9, 2015 at 3:11 PM, Martin Liška wrote:
> Hello.
>
> Following patch renames an enum values so that they do not clash with a MinGW
> reserved keyword.
Reserved keyword as in a #define? Thus simply #undef it in system.h?
> Patch can bootstrap on MinGW and there's no regression seen
On Mon, Jun 8, 2015 at 12:27 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> Here is a simple fix which allows duplication of outer loops to
> perform peeling for number of iterations if outer loop is marked with
> pragma omp simd.
>
> Bootstrap and regression testing did not show any new failures.
> Is
On Tue, Jun 9, 2015 at 2:57 PM, Jakub Jelinek wrote:
> On Tue, Jun 09, 2015 at 02:32:07PM +0200, Uros Bizjak wrote:
>> > - emit_insn (gen_rtx_SET (base, XEXP (part[1][0], 0)));
>> > + addr = XEXP (part[1][0], 0);
>> > + if (TARGET_TLS_DIRECT_SEG_REFS)
>> > + {
>>
Hello.
Following patch renames an enum values so that they do not clash with a MinGW
reserved keyword.
Patch can bootstrap on MinGW and there's no regression seen on
x86_64-linux-unknown-gnu.
Ready for trunk?
Thanks,
Martin
>From 740811e0af76af3e1e2f39f149c35bd49ef5fed3 Mon Sep 17 00:00:00 2001
Hi,
g++.dg/ext/pr57735.C is failing for test runs which explicitly pass
-mfloat-abi=hard. Looking at the test, it seems the best fix would be
to check before adding -mfloat-abi=soft that we are not testing some other
float-abi. We also fail to check that it is OK to add -march=armv5te
and -marm.
On Tue, 9 Jun 2015, Tom de Vries wrote:
> On 09/06/15 13:03, Richard Biener wrote:
> > On Tue, 9 Jun 2015, Alan Lawrence wrote:
> >
> > > Hmmm. One side effect of this is that the line number information
> > > available in
> > > the target hook gimplify_va_arg_expr, is now just the name of the
>
On 09/06/15 13:03, Richard Biener wrote:
On Tue, 9 Jun 2015, Alan Lawrence wrote:
Hmmm. One side effect of this is that the line number information available in
the target hook gimplify_va_arg_expr, is now just the name of the containing
function, rather than the specific use of va_arg. Is ther
On Tue, Jun 09, 2015 at 02:32:07PM +0200, Uros Bizjak wrote:
> > - emit_insn (gen_rtx_SET (base, XEXP (part[1][0], 0)));
> > + addr = XEXP (part[1][0], 0);
> > + if (TARGET_TLS_DIRECT_SEG_REFS)
> > + {
> > + struct ix86_address parts;
> > +
On Tue, Jun 9, 2015 at 2:32 PM, Andrew MacLeod wrote:
> On 06/09/2015 03:56 AM, Richard Biener wrote:
>>
>> On Mon, Jun 8, 2015 at 7:52 PM, Andrew MacLeod
>> wrote:
>>>
>>>
>>> the gcc source files need to see the internal bits in plugin.h, as well
>>> as
>>> the common decls in gcc-plugin.h. So
On 06/09/2015 03:56 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 7:52 PM, Andrew MacLeod wrote:
the gcc source files need to see the internal bits in plugin.h, as well as
the common decls in gcc-plugin.h. So we could change the includes as you
suggest, but we'd have to copy all the decls
On Tue, Jun 9, 2015 at 1:57 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, when trying to split:
> (insn 7 15 13 2 (set (reg:DI 0 ax [92])
> (mem:DI (plus:SI (plus:SI (mult:SI (reg/v:SI 1 dx [orig:89 b ] [89])
> (const_int 8 [0x8]))
>
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-06-09 Richard Biener
PR middle-end/66423
* match.pd: Handle A % (unsigned)(1 << B).
* gcc.dg/fold-modpow2.c: New testcase.
Index: gcc/match.pd
===
On Tue, 9 Jun 2015, Marc Glisse wrote:
> On Tue, 9 Jun 2015, Richard Biener wrote:
>
> > On Tue, 9 Jun 2015, Richard Biener wrote:
> >
> > > On Tue, 9 Jun 2015, Marc Glisse wrote:
> > >
> > > > On Tue, 9 Jun 2015, Richard Biener wrote:
> > > >
> > > > > > Tweaking it so that (6<=31 for TYPE_OV
On Wed, May 20, 2015 at 4:00 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> Here is updated patch to optimize mask stores. The main goal of it is
> to avoid execution of mask store if its mask is zero vector since
> loads that follow it can be blocked.
> The following changes were done:
> 1. A test o
On Tue, 9 Jun 2015, Richard Biener wrote:
On Tue, 9 Jun 2015, Richard Biener wrote:
On Tue, 9 Jun 2015, Marc Glisse wrote:
On Tue, 9 Jun 2015, Richard Biener wrote:
Tweaking it so that (6<=31 for TYPE_OVERFLOW_WRAPS and
false for TYPE_OVERFLOW_UNDEFINED is probably more controversial.
Hm
Hi!
As mentioned in the PR, when trying to split:
(insn 7 15 13 2 (set (reg:DI 0 ax [92])
(mem:DI (plus:SI (plus:SI (mult:SI (reg/v:SI 1 dx [orig:89 b ] [89])
(const_int 8 [0x8]))
(unspec:SI [
(const_int 0 [0])
On Tue, 9 Jun 2015, Richard Biener wrote:
> On Tue, 9 Jun 2015, Marc Glisse wrote:
>
> > On Tue, 9 Jun 2015, Richard Biener wrote:
> >
> > > > Tweaking it so that (6<=31 for TYPE_OVERFLOW_WRAPS and
> > > > false for TYPE_OVERFLOW_UNDEFINED is probably more controversial.
> > >
> > > Hm, yes. I
On Tue, 9 Jun 2015, Marc Glisse wrote:
> On Tue, 9 Jun 2015, Richard Biener wrote:
>
> > > Tweaking it so that (6<=31 for TYPE_OVERFLOW_WRAPS and
> > > false for TYPE_OVERFLOW_UNDEFINED is probably more controversial.
> >
> > Hm, yes. I think signed overflow != shift amount overflow, so testing
On Fri, May 29, 2015 at 3:14 PM, Evgeniya Maenkova
wrote:
> Hi Richard,
>
> Here is some explanation. I hope you let me know if I need to clarify
> something.
>
> Also, you asked me about concrete example, to make sure you don’t miss
> my answer here is the link:
> https://gcc.gnu.org/ml/gcc-patc
On Tue, 9 Jun 2015, Richard Biener wrote:
Tweaking it so that (6<=31 for TYPE_OVERFLOW_WRAPS and
false for TYPE_OVERFLOW_UNDEFINED is probably more controversial.
Hm, yes. I think signed overflow != shift amount overflow, so testing
the overflow macros for this isn't valid.
Would it be ok
On Mon, 8 Jun 2015, Tom de Vries wrote:
> On 17/04/15 12:08, Tom de Vries wrote:
> > On 20-03-15 12:38, Tom de Vries wrote:
> > > On 19-03-15 12:05, Tom de Vries wrote:
> > > > On 18-03-15 18:22, Tom de Vries wrote:
> > > > > Hi,
> > > > >
> > > > > this patch fixes PR65460.
> > > > >
> > > > >
On Tue, 9 Jun 2015, Alan Lawrence wrote:
> Hmmm. One side effect of this is that the line number information available in
> the target hook gimplify_va_arg_expr, is now just the name of the containing
> function, rather than the specific use of va_arg. Is there some way to get
> this more precise
Hmmm. One side effect of this is that the line number information available in
the target hook gimplify_va_arg_expr, is now just the name of the containing
function, rather than the specific use of va_arg. Is there some way to get this
more precise location (e.g. gimple_location(stmt) in expand_
On 06/05/2015 05:24 PM, Andrew MacLeod wrote:
> There is a horrible morass of include dependencies between hash-map.h,
> mem-stats.h and hash-table.h. There are even includes in both directions
> (mem-stats.h and hash-map.h include each other, as do hash-map.h and
> hash-table.h.. blech). Some
Hello,
I'm currently working on migrating debugging information for Ada from
GNAT encodings to standard DWARF. At the moment, I have worked on two
topics that I believe are not (completely) supported in standard DWARF:
- fixed point types with arbitrary scale factors;
- scalar types with
Hi Christian,
On 18/05/15 09:41, Christian Bruel wrote:
On 05/06/2015 04:29 PM, Christian Bruel wrote:
>Implement the -mflip-thump option. Undocumented for internal testing
>only. This option artificially inserts alternative attribute thumb/modes
>on functions.
>
>This close the patch set. Tha
On 22/05/15 17:56, Torvald Riegel wrote:
On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
Hi,
While writing atomic_word.h for the ARM backend to fix PR target/66200
I
thought it would make more sense to write it all up with atomic
primitives instead of providing various fragile
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> >
> > I think we should instead work towards eliminating the get_alias_set
> > langhook first. The LTO langhook variant contains the same handling, btw,
> > so just inline that into get_alias_set and see what remains?
>
> I see, i completely missed exist
On 06/09/2015 04:00 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 10:25 PM, Aldy Hernandez wrote:
On 06/08/2015 02:59 PM, Richard Biener wrote:
On June 8, 2015 7:14:19 PM GMT+02:00, Aldy Hernandez
wrote:
On 06/08/2015 09:30 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 2:05 PM, Ald
On 08/06/15 09:59 -0600, Martin Sebor wrote:
On 06/08/2015 09:12 AM, Jonathan Wakely wrote:
The linker script assumes that std::mbstate_t has the name __mbstate_t
for linkage purposes, but that's not necessarily true. For mingw32
it's just a typedef for int, so the patterns don't match.
This ad
On 8 June 2015 at 10:14, Richard Biener wrote:
> On Sat, Jun 6, 2015 at 3:14 AM, Alexandre Oliva wrote:
>> On Apr 27, 2015, Richard Biener wrote:
>>
>>> This should also mention that is_gimple_reg vars do not have their
>>> address taken.
>>
>> check
>>
+static tree
+leader_merge (tree
On 05/06/15 14:14, Kyrill Tkachov wrote:
On 05/06/15 14:11, Richard Earnshaw wrote:
On 05/06/15 14:08, Kyrill Tkachov wrote:
Hi Shiva,
On 05/06/15 10:42, Shiva Chen wrote:
Hi, Kyrill
I add the testcase as stl-cond.c.
Could you help to check the testcase ?
If it's OK, Could you help me to
Noticed when it crashed rather than asserted with broken
loop structure.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-06-09 Richard Biener
* cfgloop.c (get_loop_body_in_bfs_order): Fix assert.
Index: gcc/cfgloop.c
===
On Mon, Jun 8, 2015 at 10:25 PM, Aldy Hernandez wrote:
> On 06/08/2015 02:59 PM, Richard Biener wrote:
>>
>> On June 8, 2015 7:14:19 PM GMT+02:00, Aldy Hernandez
>> wrote:
>>>
>>> On 06/08/2015 09:30 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 2:05 PM, Aldy Hernandez
>>>
>>> wrote
On Mon, Jun 8, 2015 at 7:52 PM, Andrew MacLeod wrote:
> On 06/08/2015 09:32 AM, Richard Biener wrote:
>>
>> On Mon, Jun 8, 2015 at 2:07 PM, Andrew MacLeod
>> wrote:
>>>
>>> During the original flattening process I decided to use gcc-plugin.h as
>>> the
>>> kitchen sink for all includes that plugi
On Mon, Jun 8, 2015 at 7:03 PM, Marc Glisse wrote:
> On Mon, 8 Jun 2015, Marek Polacek wrote:
>
>> PR tree-optimization/66299
>> * match.pd ((CST1 << A) == CST2 -> A == ctz (CST2) - ctz (CST1)
>> ((CST1 << A) != CST2 -> A != ctz (CST2) - ctz (CST1)): New
>
>
> You are braver than
This is not my patch, but I'd like to ping it anyway as it also fixes
PR66467 (you might want to add a testcase from this PR as well).
On Sun, Apr 26, 2015 at 02:11:14PM +0300, Mikhail Maltsev wrote:
> The attached patch was bootstrapped and regtested on
> x86_64-unknown-linux-gnu.
>
> --
> Rega
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-06-09 Richard Biener
PR tree-optimization/66396
* graphite-isl-ast-to-gimple.c (graphite_regenerate_ast_isl):
Rename virtual operands.
Index: gcc/graphite-isl-ast-to-gimple.c
==
97 matches
Mail list logo
