On Thu, Aug 22, 2013 at 8:51 PM, Mike Stump wrote:
> On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis
> wrote:
>> I think we must distinguish what is "wrong" according to the standards
>> we are implementing from what is "wrong" from a QoI point of view.
>
> Not if they match, we don't.
In abstrac
On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis
wrote:
> I think we must distinguish what is "wrong" according to the standards
> we are implementing from what is "wrong" from a QoI point of view.
Not if they match, we don't.
> My reasoning (for C++98, but the same is true for C++11) is based
> o
cleaned up version of convert_modes that handles all constants in a
uniform manner.
This is clean on x86-64. Will test on other platforms tomorrow.
kenny
Index: gcc/expr.c
===
--- gcc/expr.c(revision 201884)
+++ gcc/expr.c
On Thu, Aug 22, 2013 at 6:16 PM, Mike Stump wrote:
> On Aug 22, 2013, at 2:28 PM, Gabriel Dos Reis
> wrote:
>> On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump wrote:
>>> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
>>> wrote:
> I.e. can I have something like
>
> int a;
> test()
>
On Thu, Aug 22, 2013 at 5:35 PM, Alan Modra wrote:
> On Fri, Aug 16, 2013 at 06:18:05PM +0930, Alan Modra wrote:
>> I'd like to apply the following patch to the gcc repository (well,
>> excluding the libgo part which I'm hoping someone will apply for me to
>> the master go repository). I know the
Ping.
On 28-Jul-13, at 12:17 PM, John David Anglin wrote:
This patch fixes PR middle-end/56382 on hppa64-hp-hpux11.11. The
patch prevents moving a complex float by parts if we can't
create pseudos. On a big endian 64-bit target, we need a psuedo to
move a complex float and this fails durin
On Fri, Aug 16, 2013 at 06:18:05PM +0930, Alan Modra wrote:
> I'd like to apply the following patch to the gcc repository (well,
> excluding the libgo part which I'm hoping someone will apply for me to
> the master go repository). I know the normal procedure for autotools
> is to submit upstream t
Steve Ellcey wrote:
> On Mon, 2013-08-19 at 22:21 -0700, Teresa Johnson wrote:
>
>> 2013-08-19 Teresa Johnson
>>
>> PR rtl-optimizations/57451
>> * final.c (reemit_insn_block_notes): Prevent lexical blocks
>> from crossing split section boundaries.
>>
>> * tes
On Mon, 2013-08-19 at 22:21 -0700, Teresa Johnson wrote:
> 2013-08-19 Teresa Johnson
>
> PR rtl-optimizations/57451
> * final.c (reemit_insn_block_notes): Prevent lexical blocks
> from crossing split section boundaries.
>
> * testsuite/g++.dg/tree-prof/pr57451.
Hi, In this patch, loop alignment peeling and loop versioning
transformation will be reported via -fopt-info by default. This will
help vectorizer size tuning.
It also enhances the opt-info dump to include current function name as
context. Otherwise, we may see duplicate messeages from inline/clon
On Aug 22, 2013, at 2:28 PM, Gabriel Dos Reis
wrote:
> On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump wrote:
>> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
>> wrote:
I.e. can I have something like
int a;
test()
{
int *b=new (int);
}
with custom imp
On Fri, Aug 23, 2013 at 01:45:14AM +0930, Alan Modra wrote:
> On Thu, Aug 22, 2013 at 10:06:48AM -0400, David Edelsohn wrote:
> > What is the purpose of the change to MULTILIB_OSDIRNAMES? Why the
> > addition of m64= and m32=? A secondary tmake file is not always set to
> > post-process those macro
This patch has 2 changes:
1. Now that we have discriminator for inlined callsite, we don't need
special handling for callsite location any more.
2. If a source line is mapped to multiple BBs, only the first BB will
be annotated.
3. Before actual annotation, mark everythin BB/edge as not annotated.
Hi,
I went through some statistics on firefox build (it is a source combining many
coding styles).
I was basically curious where we do devirtualization. The result is:
Before inline (i.e. important devirtualization)
624 ssa-pre devirt 0
this is interaprocedural devirutalization happe
On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
> On 08/22/2013 11:39 AM, Torvald Riegel wrote:
> > + /* Store edi for future HTM fast path retries. We use a stack slot
> > + lower than the jmpbuf so that the jmpbuf's rip field will overlap
> > + with the proper return addr
Hello,
Le 22/08/2013 15:20, Janus Weil a écrit :
> Hi all,
>
> the SIZEOF intrinsic currently returns the size according to the
> *declared* type for polymorphic variables. I think this doesn't really
> make much sense and it also causes ICEs when SIZEOF is called on
> CLASS(*) variables (which d
I believe I have figured this out and fixed the problem. If you are
still seeing the issue, please let me know.
-- Caroline Tice
cmt...@google.com
On Thu, Aug 22, 2013 at 10:07 AM, Caroline Tice wrote:
> I was not aware that the links required Javascript. Can anybody tell
> me how to fix them
Le 22/08/2013 17:41, Janus Weil a écrit :
> Hi all,
>
> here is a wrong-code fix for type-bound assignments, which makes sure
> that these are resolved to polymorphic procedure calls. This was not
> always the case, because we used the wrong ordering when checking for
> defined-assignment procedur
Le 14/08/2013 23:46, Thomas Koenig a écrit :
> Hello world,
>
> the attached patch enables more sophisticated bounds-checking on
> array slices by using gfc_dep_difference to calculate extents.
> The information may also be useful in other places of the
> front end, I don't really know.
>
> There
On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump wrote:
> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
> wrote:
>>> I.e. can I have something like
>>>
>>> int a;
>>> test()
>>> {
>>> int *b=new (int);
>>> }
>>>
>>> with custom implementation of new that returns &a?
>>
>> If the user-supplied operat
On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis
wrote:
>> I.e. can I have something like
>>
>> int a;
>> test()
>> {
>> int *b=new (int);
>> }
>>
>> with custom implementation of new that returns &a?
>
> If the user-supplied operator new returns &a, then it must
> also ensure that 'a' is not us
Ping?
On 08/08/2013 02:10 PM, Brooks Moses wrote:
As discussed in PR/42955, when GCC is built as a cross-compiler, it
will install "gcc", "g++", "c++", and "gfortran" binaries in
$(target)/bin, as well as installing the $target-gcc and so forth in
bin. However, these binaries in $(target)/bin d
Hi,
This line of code causes gcc for the AVR target to loop
for a while and eventually crash after exhausting virtual memory.
char x[] = { [0xFF] = 2 };
output_pending_init_elements in gcc/c/c-typeck.c ends up in an
infinite loop if elt->purpose is a tree representing an integer
const
On Thu, Aug 22, 2013 at 12:06 PM, Richard Henderson wrote:
> On 08/22/2013 11:56 AM, Kirill Yukhin wrote:
>> ChangeLog:
>> 2013-08-22 Kirill Yukhin
>>
>> * gcc/config/i386/i386.md (*movti_internal): Use
>> predicate to determine if EVEX is needed.
>> (*movsi_internal): Ditto.
On 08/22/2013 11:56 AM, Kirill Yukhin wrote:
> ChangeLog:
> 2013-08-22 Kirill Yukhin
>
> * gcc/config/i386/i386.md (*movti_internal): Use
> predicate to determine if EVEX is needed.
> (*movsi_internal): Ditto.
> (*movdf_internal): Ditto.
> (*movsf_internal): Ditto.
On 08/22/2013 11:39 AM, Torvald Riegel wrote:
> + /* Store edi for future HTM fast path retries. We use a stack slot
> +lower than the jmpbuf so that the jmpbuf's rip field will overlap
> +with the proper return address on the stack. */
> + movl%edi, -64(%rsp)
You hav
On Thu, Aug 22, 2013 at 07:51:07PM +0200, Marek Polacek wrote:
> Ping.
I'm withdrawing the ping for now. I'll have to deal with some bootstrap
comparison failures first (ugh!).
Marek
Hello,
On 21 Aug 13:02, Richard Henderson wrote:
> On 08/21/2013 11:28 AM, Kirill Yukhin wrote:
> > (eq_attr "alternative" "12,13")
> > - (cond [(ior (not (match_test "TARGET_SSE2"))
> > + (cond [(ior (match_test "EXT_REX_SSE_REGNO_P (REGNO
> > (operands[0]))")
> > +
Attached is an updated patch. Changes explained below.
On Wed, 2013-08-21 at 10:50 -0700, Richard Henderson wrote:
> > -#if defined(USE_HTM_FASTPATH) && !defined(HTM_CUSTOM_FASTPATH)
> > +#ifdef USE_HTM_FASTPATH
> >// HTM fastpath. Only chosen in the absence of transaction_cancel to
> > all
On Thu, 2013-08-22 at 19:47 +0200, Jakub Jelinek wrote:
> On Thu, Aug 22, 2013 at 09:39:48AM -0500, Bill Schmidt wrote:
> > Hi Christian and Jakub,
> >
> > I'm curious whether there was ever any resolution for:
> > http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.
>
> The last mail I remem
In doing make check, I noticed that I'm now getting warnings from one of the
tests that I wrote for power8 support (pr57744). I applied this patch as
obvious:
2013-08-22 Michael Meissner
* gcc.target/powerpc/pr57744.c: Declare abort.
Index: gcc/testsuite/gcc.target/powerpc/pr57744.c
Ping.
On Thu, Aug 15, 2013 at 05:08:48PM +0200, Marek Polacek wrote:
> I've fixed a few unpleasant bugs; mainly the bug that introduced
> various uninitialized variable warnings was bothersome.
> Now it is possible to do bootstrap with -fsanitize=undefined,
> even though there are some comparison
On Thu, Aug 22, 2013 at 09:39:48AM -0500, Bill Schmidt wrote:
> Hi Christian and Jakub,
>
> I'm curious whether there was ever any resolution for:
> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.
The last mail I remember didn't make any sense:
#include "tconfig.h"
that includes it:
#i
On Tue, 13 Aug 2013, Ilya Enkovich wrote:
> Any comments on the used approach?
You don't have any documentation (fragments.texi) in your patch. Apart
from that, this patch doesn't appear to do anything to engage with all the
problems of having multiple multilibs in use at once, such as the
in
I was not aware that the links required Javascript. Can anybody tell
me how to fix them so that they don't?
-- Caroline Tice
cmt...@google.com
On Thu, Aug 22, 2013 at 9:58 AM, Joseph S. Myers
wrote:
> On Mon, 12 Aug 2013, Caroline Tice wrote:
>
>> I have finished my first pass at the porting do
On Thu, Aug 22, 2013 at 11:08 AM, Jan Hubicka wrote:
>>
>> This should be a C++ front-end bug. The specific operator new
>> from used in this placement-new should be folded,
>> even if -fno-inline. Jason, is this something easily fixable?
>>
>> After overload resolution, we know exactly which o
On Mon, 12 Aug 2013, Caroline Tice wrote:
> I have finished my first pass at the porting documentation. It is now
> available on the vtable verification feature web site:
> http://gcc.gnu.org/wiki/vtv
Please provide the links there in a form that does not require JavaScript
to read them (in par
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Thursday, August 22, 2013 10:37 AM
> To: Nick Clifton
> Cc: cherty...@gmail.com; ae...@post.ru; Weddington, Eric; gcc-
> patc...@gcc.gnu.org
> Subject: Re: RFA: AVR: Support building AVR Linux targets
>
>
On 08/21/13 14:59, Iyer, Balaji V wrote:
-Original Message- From: Aldy Hernandez
[mailto:al...@redhat.com] Sent: Wednesday, August 21, 2013 11:31 AM
To: Iyer, Balaji V Cc: r...@redhat.com; Jeff Law;
gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Cilk Keywords
(_Cilk_spawn and _Cilk_sync)
... I'm testing the below. Works fine so far. I'm going to commit it as
soon as a bootstrap on x86_64-linux completes again.
Paolo.
Index: configure.ac
===
--- configure.ac(revision 201924)
+++ configure.ac
On Thu, 22 Aug 2013 18:39:42 +0200
Paolo Carlini wrote:
> ... I'm testing the below. Works fine so far. I'm going to commit it
> as soon as a bootstrap on x86_64-linux completes again.
Sorry about that, I messed up doing some "harmless" reformatting
whilst preparing the patch :-(.
Thanks for fi
On Thu, Aug 22, 2013 at 11:16 AM, Jan Hubicka wrote:
>> On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka wrote:
>> >> >
>> >> > So the existing program needs to overwrite libsup++ symbol like we do
>> >> > with malloc?
>> >> > Of course with user defineed malloc function we should not propagate
>>
On Mon, 12 Aug 2013, Nick Clifton wrote:
> Hi Dennis, Hi Anatoly, Hi Eric,
>
> I have run into a small problem building GCC for an AVR Linux target -
> glibc-c.o is not being built. It turns out that the section handling
> "avr-*-*" in the config.gcc file is redefining tmake_file without
>
.. missing backslashes I would say.
Paolo.
.. I'm double checking, but I think that this commit broke the
bootstrap. I'm seeing:
/scratch/Gcc/svn-dirs/trunk/gcc/configure: line 26121: syntax error near
unexpected token `newline'
/scratch/Gcc/svn-dirs/trunk/gcc/configure: line 26121: ` aarch64 |
alpha | arm | avr | bfin | cris | i386 |
> On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka wrote:
> >> >
> >> > So the existing program needs to overwrite libsup++ symbol like we do
> >> > with malloc?
> >> > Of course with user defineed malloc function we should not propagate the
> >> > attribute,
> >> > but I think we could have it whe
On Thu, Aug 22, 2013 at 10:06:48AM -0400, David Edelsohn wrote:
> On Wed, Aug 21, 2013 at 11:57 PM, Alan Modra wrote:
>
> > Index: gcc/config/rs6000/t-linux64
> > ===
> > --- gcc/config/rs6000/t-linux64 (revision 201834)
> > +++ gcc/
>
> This should be a C++ front-end bug. The specific operator new
> from used in this placement-new should be folded,
> even if -fno-inline. Jason, is this something easily fixable?
>
> After overload resolution, we know exactly which operator new
> we are picking, and we know it is the one co
On Thu, Aug 22, 2013 at 10:39 AM, Jan Hubicka wrote:
>> >
>> > So the existing program needs to overwrite libsup++ symbol like we do with
>> > malloc?
>> > Of course with user defineed malloc function we should not propagate the
>> > attribute,
>> > but I think we could have it when we end up ca
Hi,
On 08/22/2013 05:22 PM, Jan Hubicka wrote:
On 08/22/2013 05:59 AM, Jan Hubicka wrote:
+/* Nonzero if RECORD_TYPE represents a final derivation of class. */
+#define TYPE_FINAL_P(NODE) \
+ (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)
How about if we put this flag on the BINFO rat
On Thu, Aug 22, 2013 at 10:38 AM, Alexander Monakov wrote:
> On Thu, 22 Aug 2013, Jan Hubicka wrote:
>
>> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > > > - I would like to recall issue if we can make NEW_EXPR annotated with
>> > > >MALLOC attribute. Without it, it is basically imposs
>
>
> On Thu, 22 Aug 2013, Jan Hubicka wrote:
>
> > > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > > > > - I would like to recall issue if we can make NEW_EXPR annotated with
> > > > >MALLOC attribute. Without it, it is basically impossible to track
> > > > >any dynamically allocat
On 08/22/2013 02:35 AM, Kirill Yukhin wrote:
> Despite of generic OR, mask version of OR do not clobber FLAGS_REG.
> Of course, we may conservatively think that it is, but I believe
> this is not good idea.
I believe that having two different patterns is a worse idea.
You can always split away th
OK.
Jason
Hi all,
here is a wrong-code fix for type-bound assignments, which makes sure
that these are resolved to polymorphic procedure calls. This was not
always the case, because we used the wrong ordering when checking for
defined-assignment procedures (looking for non-typebound ones first,
and for type
On Thu, 22 Aug 2013, Jan Hubicka wrote:
> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > > > - I would like to recall issue if we can make NEW_EXPR annotated with
> > > >MALLOC attribute. Without it, it is basically impossible to track
> > > >any dynamically allocated objects in th
> >
> > So the existing program needs to overwrite libsup++ symbol like we do with
> > malloc?
> > Of course with user defineed malloc function we should not propagate the
> > attribute,
> > but I think we could have it when we end up calling the runtime.
>
> I suspect the question is whether ou
Hi,
this problem was noticed by my verifier that binfo walks are not across type
hiearchy. ipa_intraprocedural_devirtualization is one remaining place where we
take class of object from OBJ_TYPE_REF_OBJECT instead of
obj_type_ref_class_type.
Unforutnately I noticed that this problem is propagated
On Thu, Aug 22, 2013 at 10:21 AM, Jan Hubicka wrote:
>> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > > - I would like to recall issue if we can make NEW_EXPR annotated with
>> > >MALLOC attribute. Without it, it is basically impossible to track
>> > >any dynamically allocated object
On Thu, Aug 22, 2013 at 9:56 AM, Jakub Jelinek wrote:
> On Thu, Aug 22, 2013 at 09:53:35AM -0500, Gabriel Dos Reis wrote:
>> On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov
>> wrote:
>> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> >> > - I would like to recall issue if we can make NEW_E
> On 08/22/2013 05:59 AM, Jan Hubicka wrote:
> >+/* Nonzero if RECORD_TYPE represents a final derivation of class. */
> >+#define TYPE_FINAL_P(NODE) \
> >+ (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)
>
> How about if we put this flag on the BINFO rather than the type itself?
No problem
> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > > - I would like to recall issue if we can make NEW_EXPR annotated with
> > >MALLOC attribute. Without it, it is basically impossible to track
> > >any dynamically allocated objects in the middle-end
> >
> > operator new is replaceable b
On 08/22/2013 05:59 AM, Jan Hubicka wrote:
+/* Nonzero if RECORD_TYPE represents a final derivation of class. */
+#define TYPE_FINAL_P(NODE) \
+ (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)
How about if we put this flag on the BINFO rather than the type itself?
Jason
> >if (phase_wall > total->wall)
> > fprintf (fp, "wall%24.18e > %24.18e\n", phase_wall, total->wall);
> >if (phase_ggc_mem > total->ggc_mem)
> > - fprintf (fp, "ggc_mem %24u > %24u\n", phase_ggc_mem, total->ggc_mem);
> > + fprintf (fp, "ggc_mem %24lu > %24lu\n", phase_g
On 22/08/13 16:03, Jan Hubicka wrote:
> Hi,
> this patch fixes overflow happening in -ftime-report when printing memory
> usage
> of bigger WPA compilations.
>
> Honza
>
> * timevar.c (validate_phases): Use size_t for memory.
> * timevar.h (struct timevar_time_def): Use size_t for gg
Hi,
this was noticed by the ODR verifier. For variables we get unique_name wrong
because we first bring it local and then test if it is global.
This makes the ODR unification based on aassembler name to go wrong.
Bootstrapped/regtested x86_64-linux, will commit it shortly.
* ipa.c (funct
On Thu, Aug 22, 2013 at 09:53:35AM -0500, Gabriel Dos Reis wrote:
> On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov wrote:
> > On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> >> > - I would like to recall issue if we can make NEW_EXPR annotated with
> >> >MALLOC attribute. Without it, it i
Hi,
this patch fixes overflow happening in -ftime-report when printing memory usage
of bigger WPA compilations.
Honza
* timevar.c (validate_phases): Use size_t for memory.
* timevar.h (struct timevar_time_def): Use size_t for ggc_mem.
Index: timevar.c
=
On 22/08/13 15:26, Julian Brown wrote:
> Hi,
>
> This patch fixes what I assume to be a simple omission from the
> configure test for debug_line assembler support in gcc/configure. This
> tripped an obscure corner-case test in our build infrastructure, which
> is fixed by the attached patch, but I
On Thu, Aug 22, 2013 at 9:38 AM, Alexander Monakov wrote:
> On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
>> > - I would like to recall issue if we can make NEW_EXPR annotated with
>> >MALLOC attribute. Without it, it is basically impossible to track
>> >any dynamically allocated objects
>
> Btw, how does this all scale with the worst testcase? That is, a very deep
> inheritance hierarchy with each level virtually overriding all methods and
> very many duplicate input files? Is that really the worst case? We should
> make sure not to introduce quadratic or worse algorithms. (I di
On Thu, 22 Aug 2013, Gabriel Dos Reis wrote:
> > - I would like to recall issue if we can make NEW_EXPR annotated with
> >MALLOC attribute. Without it, it is basically impossible to track
> >any dynamically allocated objects in the middle-end
>
> operator new is replaceable by user progr
Hi Christian and Jakub,
I'm curious whether there was ever any resolution for:
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.
We've encountered what appears to be the same issue internally when
building a cross for powerpc64le-linux-gnu:
/scratch/tmp/anton/toolchain/build/src/gcc/libgc
On Thu, Aug 22, 2013 at 8:19 AM, Jan Hubicka wrote:
>
> Hi,
> this patch started as a work to make cxa_pure_virtual as noreturn. This
> is good for middle-end to figure out that it should not care about
> devirtualizing to it and it should devirtualize speculative where there
> is only one varian
Hi,
This patch fixes what I assume to be a simple omission from the
configure test for debug_line assembler support in gcc/configure. This
tripped an obscure corner-case test in our build infrastructure, which
is fixed by the attached patch, but I don't otherwise have a way of
testing the patch at
On Thu, Aug 22, 2013 at 9:08 AM, Tim Shen wrote:
> Booted and tested with -m32, -m64 and -m64 debug-mode under x86_64
> GNU/Linux and committed(r201914).
...and here's the patch committed.
--
Tim Shen
emptygroup.patch
Description: Binary data
On 14 Aug 11:44, Kirill Yukhin wrote:
PING?
Thanks, K
On Wed, Aug 21, 2013 at 11:57 PM, Alan Modra wrote:
> Index: gcc/config/rs6000/t-linux64
> ===
> --- gcc/config/rs6000/t-linux64 (revision 201834)
> +++ gcc/config/rs6000/t-linux64 (working copy)
> @@ -25,8 +25,8 @@
> # it doesn't t
On 08/21/2013 05:13 PM, Mike Stump wrote:
O
that should include the tree-core.h file as well as the tree-api.h file.
No… I don't see a client for tree-api. Logically, you can segregate them down
at the bottom of tree-core.h.
We are then left with this tree-api.h file which will be included
Hi all,
the SIZEOF intrinsic currently returns the size according to the
*declared* type for polymorphic variables. I think this doesn't really
make much sense and it also causes ICEs when SIZEOF is called on
CLASS(*) variables (which don't really have a declared type).
Therefore I'm proposing to
Hi,
this patch started as a work to make cxa_pure_virtual as noreturn. This
is good for middle-end to figure out that it should not care about
devirtualizing to it and it should devirtualize speculative where there
is only one variant. I ended up switching the function building
stuff to use ecf_
Ugh.. thanks, you are right. That points to another problem that I
didn't see before:
3) *linux* targets that do not append to tm_p_file (s390x-*-linux* and
s390x-ibm-tpf* - your patch addresses that problem correctly) OR
tmake_file (bfin*-linux-uclibc* or crisv32-*-linux* | cris-*-linux*)
(btw b
Jan Hubicka wrote:
>Hi,
>this patch fixes some issues with ipa-devirt I noticed since the
>initial
>commit.
>
> 1) I added fixes and comments Doji suggested (thanks!)
>
>2) During the callgraph construction new external nodes may be created
>that
>needs to be added into the inheritance graph get m
Hi,
we fail to diagnose such illegal declarations when they occur at
instantiation time.
Patch should be rather straightforward, possibly modulo exact wording;
permerror vs error; something error recovery related (not touching the
CLASSTYPE_HAS_MUTABLE setting seems ok to me).
Booted and t
>>> The attached new version is what I'm regtesting right now (with the
>>> whole BT_DERIVED branch removed, since it should not be needed). Ok if
>>> it succeeds?
>>
>> It does regtest cleanly. Ok for trunk and 4.8?
>>
> Yes.
Thanks, committed to trunk as r201919. Will backport to 4.8 soon.
Chee
Le 22/08/2013 12:49, Janus Weil a écrit :
> Hi,
>
>>> Thus the condition should probably be
>>> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled
>>> before? OK with that change (if it works).
>>
>> Good point. And yes, it works.
>>
>> However, on second thought, I wonder why
Hi,
>> Thus the condition should probably be
>> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled
>> before? OK with that change (if it works).
>
> Good point. And yes, it works.
>
> However, on second thought, I wonder why we need to treat the case
> "selector->ts.type == BT_
On 26 September 2012 13:11, Ulrich Weigand wrote:
> ChangeLog:
>
> * lower-subreg.c (enum classify_move_insn): Rename
> SIMPLE_PSEUDO_REG_MOVE to DECOMPOSABLE_SIMPLE_MOVE.
> (find_decomposable_subregs): Update.
> (decompose_multiword_subregs): Add DECOMPOSE_COPIES p
This patch consolidates initialization routines of various pretty
printers -- at the moment, we have unfortunately very few (basic, C, C++).
It adds a default constructor to pretty_printer (which in turn made
obvious we needed one for output_buffer), c_pretty_printer, and
cxx_pretty_printer. The
Hi,
this patch moves CLASSTYPE_FINAL and DECL_FINAL_P to middle end trees,
so I can use them in my type inheritance analysis.
Incrementally I would like to introduce DECL_CPP_CONSTURCTOR_P/DESTRUCTOR,
too, since we need to know about their C++ specific semantics. However
I failed to follow the sam
Hi Mikael,
thanks for the review!
>> + else if (selector->ts.u.derived)
>
> Hum, accessing ts.u.derived is correct only if selector->ts.type is
> BT_DERIVED or BT_CLASS, isn't it?
yes.
> Thus the condition should probably be
> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was hand
Hello Richard,
On 19 Aug 14:17, Richard Henderson wrote:
> On 08/14/2013 12:23 AM, Kirill Yukhin wrote:
> > + ;; For AVX512F mask support
> > + UNSPEC_KIOR
> > + UNSPEC_KXOR
> > + UNSPEC_KAND
> > + UNSPEC_KANDN
>
> I thought we determined that you didn't need these,
> that "*Yk" as a constra
On Thu, Aug 22, 2013 at 4:56 PM, Paolo Carlini wrote:
> Ok, thanks!
Committed.
--
Tim Shen
On 08/22/2013 05:55 AM, Tim Shen wrote:
I simply replace 8 spaces in indentation with a tab.
Bootstrap passed.
Ok, thanks!
Paolo.
On Wed, Aug 21, 2013 at 11:21:32PM +0400, Alexander Ivchenko wrote:
> I'm sorry for that. The following patch cured my build of those
> targets; it is also preserving the initial presence of c99. There were
> plenty of targets that were changed by my patch, I hope this time I
> didn't miss anything
Thanks for doing this. I haven't had chance to look at the branch yet
(hope to soon), but the results on mips64-linux-gnu look pretty good:
http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg02033.html
The only failures that stand out as being possibly wide-int-related are:
FAIL: gcc.dg/fixed
96 matches
Mail list logo
