The GIMPLE level if-conversion code was purely
written to make loops suitable for vectorization.
I`m not surprised to read that.
It wasn't meant to provide if-conversion of
scalar code in the end (even though it does).
Serendipity sure is nice. ;-)
We've discussed enabling the versioni
On Fri, 2015-07-10 at 14:27 -0500, Segher Boessenkool wrote:
> On Fri, Jul 10, 2015 at 10:43:43AM -0700, Steve Ellcey wrote:
> >
> > I have a basic GCC testing question. I built a native GCC and ran:
> >
> > make RUNTESTFLAGS='dg.exp' check
> >
> > Everything passed and according to the lo
On Fri, Jul 10, 2015 at 10:43:43AM -0700, Steve Ellcey wrote:
>
> I have a basic GCC testing question. I built a native GCC and ran:
>
> make RUNTESTFLAGS='dg.exp' check
>
> Everything passed and according to the log file it used the unix.exp
> as the target-board. But if I try running:
On 07/10/2015 09:04 AM, Armin Rigo wrote:
Hi David,
On 10 July 2015 at 16:11, David Malcolm wrote:
AIUI, we have CALL_INSN instructions all the way through the RTL phase
of the backend, so we can identify which locations in the generated code
are calls; presumably we'd need at each CALL_INSN t
I have a basic GCC testing question. I built a native GCC and ran:
make RUNTESTFLAGS='dg.exp' check
Everything passed and according to the log file it used the unix.exp
as the target-board. But if I try running:
make RUNTESTFLAGS='dg.exp --target-board=unix' check
Then I get
On 10/07/15 16:16, Richard Earnshaw wrote:
> On 10/07/15 16:00, pins...@gmail.com wrote:
>>
>>
>>
>>
>>> On Jul 10, 2015, at 7:13 AM, Richard Earnshaw
>>> wrote:
>>>
On 10/07/15 13:18, Segher Boessenkool wrote:
> On Fri, Jul 10, 2015 at 10:02:06AM +0100, Richard Earnshaw wrote:
> Thi
On 10/07/15 16:00, pins...@gmail.com wrote:
>
>
>
>
>> On Jul 10, 2015, at 7:13 AM, Richard Earnshaw
>> wrote:
>>
>>> On 10/07/15 13:18, Segher Boessenkool wrote:
On Fri, Jul 10, 2015 at 10:02:06AM +0100, Richard Earnshaw wrote:
This isn't going to reliably work for ARM or AArch64.
Hi David,
On 10 July 2015 at 16:11, David Malcolm wrote:
> AIUI, we have CALL_INSN instructions all the way through the RTL phase
> of the backend, so we can identify which locations in the generated code
> are calls; presumably we'd need at each CALL_INSN to determine somehow
> which RTL express
> On Jul 10, 2015, at 7:13 AM, Richard Earnshaw
> wrote:
>
>> On 10/07/15 13:18, Segher Boessenkool wrote:
>>> On Fri, Jul 10, 2015 at 10:02:06AM +0100, Richard Earnshaw wrote:
>>> This isn't going to reliably work for ARM or AArch64. If the only call
>>> within a leaf function is via the A
On Fri, 2015-07-10 at 11:13 +0200, Armin Rigo wrote:
> Hi David, hi Basile,
>
> On 10 July 2015 at 03:53, David Malcolm wrote:
> > FWIW PyPy (an implementation of Python) defaults to using true GC, and
> > could benefit from GC support in GCC; currently PyPy has a nasty hack
> > for locating on-s
On 10/07/15 13:18, Segher Boessenkool wrote:
> On Fri, Jul 10, 2015 at 10:02:06AM +0100, Richard Earnshaw wrote:
>> This isn't going to reliably work for ARM or AArch64. If the only call
>> within a leaf function is via the ASM the compiler doesn't guarantee to
>> ensure the stack is aligned to th
On 07/10/2015 09:52 AM, Paolo Carlini wrote:
Good. Thus in practice the "immediate context" theory boils down to
those irrevocable instantiations, that wasn't completely clear to me,
thanks.
Right.
Does that imply that c++/62085 should be closed?
I think so, yes.
The compilers I have
here
Hi,
On 07/10/2015 03:42 PM, Jason Merrill wrote:
On 07/10/2015 07:26 AM, Paolo Carlini wrote:
I have an old question about an issue which I noticed a while ago, and
for example clearly shows up in c++/62085: in a few places in pt.c we
call complete_type from functions getting a tsubst_flags_t.
On 07/10/2015 07:26 AM, Paolo Carlini wrote:
I have an old question about an issue which I noticed a while ago, and
for example clearly shows up in c++/62085: in a few places in pt.c we
call complete_type from functions getting a tsubst_flags_t. Clearly,
complete_type often calls instantiate_clas
On 07/10/2015 04:09 AM, Richard Biener wrote:
On Thu, 9 Jul 2015, Uros Bizjak wrote:
Hello!
The patch was bootstrapped and tested on x86/x86-64.
Committed as rev. 225618.
2015-07-09 Vladimir Makarov
PR rtl-optimization/66782
* lra-int.h (struct lra_insn_recog_data):
On Fri, Jul 10, 2015 at 10:02:06AM +0100, Richard Earnshaw wrote:
> This isn't going to reliably work for ARM or AArch64. If the only call
> within a leaf function is via the ASM the compiler doesn't guarantee to
> ensure the stack is aligned to the ABI requirements.
Those archs have a link regis
Hi,
I have an old question about an issue which I noticed a while ago, and
for example clearly shows up in c++/62085: in a few places in pt.c we
call complete_type from functions getting a tsubst_flags_t. Clearly,
complete_type often calls instantiate_class_template_1, which, in turn,
often c
On 09/07/15 16:56, David Talmage wrote:
> I'm looking for a way to specify the LD_LIBRARY_PATH or LD_PRELOAD on the
> target system when running one of the DejaGNU test suites. I'm testing a gcc
> cross-compiler on a development board. I can't replace existing versions of
> libraries under test
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Friday, July 10, 2015 4:04 AM
To: Ajit Kumar Agarwal; Richard Biener; gcc@gcc.gnu.org
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [RFC] Design and Implementation for Path Splitt
Hi David, hi Basile,
On 10 July 2015 at 03:53, David Malcolm wrote:
> FWIW PyPy (an implementation of Python) defaults to using true GC, and
> could benefit from GC support in GCC; currently PyPy has a nasty hack
> for locating on-stack GC roots, by compiling to assembler, then carving
> up the a
On 08/07/15 22:15, Jeff Law wrote:
> On 07/08/2015 02:51 PM, Josh Poimboeuf wrote:
>> On Wed, Jul 08, 2015 at 11:22:34AM -0500, Josh Poimboeuf wrote:
>>> On Wed, Jul 08, 2015 at 05:36:31AM -0500, Segher Boessenkool wrote:
On Wed, Jul 08, 2015 at 11:23:09AM +0200, Martin Jambor wrote:
>> Fo
On 09/07/15 23:17, Basile Starynkevitch wrote:
> (this is triggered by a question on the Ocaml mailing list asking about
> SystemZ backend in Ocaml; SystemZ is today a backend for GCC & probably
> GCCJIT)
>
> We might want to support better good garbage collection schemes in GCC,
> particulari
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Friday, July 10, 2015 4:04 AM
To: Ajit Kumar Agarwal; Richard Biener; gcc@gcc.gnu.org
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [RFC] Design and Implementation for Path Splitti
On Thu, 9 Jul 2015, Uros Bizjak wrote:
> Hello!
>
> > The patch was bootstrapped and tested on x86/x86-64.
> >
> > Committed as rev. 225618.
> >
> > 2015-07-09 Vladimir Makarov
> >
> > PR rtl-optimization/66782
> > * lra-int.h (struct lra_insn_recog_data): Add comment about
> >
Vladimir Makarov writes:
> On 2015-07-05 7:11 AM, Ajit Kumar Agarwal wrote:
> > All:
> >
> > I am wondering allocation of hot data structure closer to the top of the
> > stack increases
> the performance of the application.
> > The data structure are identified as hot and cold data structure and
25 matches
Mail list logo
