On 24 Jul 2014, at 03:48, Trevor Saunders wrote:
> On Thu, Jul 24, 2014 at 02:00:24AM +0200, Oleg Endo wrote:
>> On Wed, 2014-07-23 at 11:37 +0200, Richard Biener wrote:
>>> On Fri, Jul 18, 2014 at 3:08 AM, Trevor Saunders
>>> wrote:
On Thu, Jul 17, 2014 at 06:36:31AM +0200, Andi Kleen wr
On Wed, Jul 23, 2014 at 04:52:23PM -0700, Andrew Pinski wrote:
> > Comments, objections? Ok to apply the preliminary patch?
>
> Yes, what if you don't move the tests but just change how the .exp to
> use the same infrastructure as gcc.dg/torture instead?
Yeah. I believe gcc.c-torture/compile/ ha
On Wed, Jul 23, 2014 at 11:45 PM, Nathan Sidwell wrote:
> This second patch cleans up some more global names. the three functions
> should not be visible to the user. I'm not sure if they're attempting to
> export an interface to the user but they're (a) undocumented and (b) don't
> follow exist
Thomas Schwinge writes:
> Hi!
>
> On Thu, 24 Jul 2014 01:47:09 +0200, Bernd Schmidt
> wrote:
>> (git doesn't seem to produce something
>> nice for the renames unfortunately)
>
> Are you maybe looking for the the -M or -C options to certain commands
> (diff, show, ...)?
Or set diff.renames in
On Thu, Jul 24, 2014 at 10:21:14AM +0400, Yury Gribov wrote:
> On 07/24/2014 12:09 AM, Jakub Jelinek wrote:
> >>Ah internal fns. Those cannot have attributes indeed (technical
> >>limitation).
> >>Martin was working on putting those flags elsewhere (cgraph, though internal
> >>functions don't
On Wed, Jul 23, 2014 at 6:29 PM, Jan Hubicka wrote:
>> On July 23, 2014 4:42:22 PM CEST, Jan Hubicka wrote:
>> >> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
>> >> >> I don't see why
>> >> >>
>> >> >> long x[1024];
>> >> >>
>> >> >> Q *q = new (x) Q;
>> >> >> q->~Q ();
>> >> >> new (x) T
Hi,
I reverted my patches about inlining memset on arm, it can't build glibc
properly. I will try to resolve the issue.
Sorry for the inconvenience.
Revert r212893:
PR target/55701
* config/arm/arm.md (setmem): New pattern.
* config/arm/arm-protos.h (struct tune_pa
Hi!
On Thu, 5 Jun 2008 12:04:30 -0400, Jakub Jelinek wrote:
> --- gcc/omp-low.c (.../trunk) (revision 136314)
> +++ gcc/omp-low.c (.../branches/gomp-3_0-branch) (revision 136352)
> @@ -223,20 +222,223 @@ extract_omp_for_data (tree for_stmt, str
> fd->sched_kind = OMP_CLAUSE_SCH
On Thu, Jul 24, 2014 at 3:52 AM, Pengfei Yuan <0xcool...@gmail.com> wrote:
> There are more.
>
> In toplev.c:
> /* One region RA really helps to decrease the code size. */
> if (flag_ira_region == IRA_REGION_AUTODETECT)
> flag_ira_region
> = optimize_size || !optimize ? IRA_REGION_ON
On Thu, Jul 24, 2014 at 8:57 AM, Richard Sandiford
wrote:
> Ping. Originaly message was here:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01113.html
Ok.
Thanks,
Richard.
> Richard Sandiford writes:
>> Richard Sandiford writes:
>>> Jan Hubicka writes:
Hi,
>>>
IRA initializa
On Thu, Jul 24, 2014 at 8:58 AM, Richard Sandiford
wrote:
> Ping. Original message was here:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01267.html
Ok.
Thanks,
Richard.
> Richard Sandiford writes:
>> My patch to reduce the amount of rtx garbage created:
>>
>> 2014-05-17 Richard Sandi
On Wed, Jul 23, 2014 at 9:56 PM, Andi Kleen wrote:
>> > Why didn't you replace the tree.c uses BTW?
>>
>> Patches were already quite big, but I'll add it.
>
> Actually I handled them all in tree.c. Did you
> mean something else?
I meant transform the iterative_hash_* _implementations_ to
use the
On 23/07/14 22:33 +0200, François Dumont wrote:
I have a small question regarding some code next to the one I am
modifying in this patch. I can see lines like:
propagating_allocator() noexcept = default;
When using a default implementation shouldn't we let the compiler
decide if it
On 07/24/2014 12:17 PM, Andrew Pinski wrote:
On Wed, Jul 23, 2014 at 9:10 PM, Hongxu Jia wrote:
1. How to reproduce the issue:
1) manually modify gcc/Makefile.in to delay the generation of config.h:
...
diff --git gcc-4.9.0/gcc/Makefile.in gcc-4.9.0/gcc/Makefile.in
--- gcc-4.9.0/gcc/Makefile.i
Hi Guys,
I am checking in the patch below to fix a small DWARF generation
problem with the RX backend. The stack_push pattern contains two
separate operations that act in parallel, but they were written as if
they happened in sequence. Which meant that the DWARF generated to
show where
Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00958.html
Kyrill
On 14/07/14 11:01, Kyrill Tkachov wrote:
On 11/07/14 14:20, Alexander Monakov wrote:
On Fri, 11 Jul 2014, Kyrill Tkachov wrote:
On 10/07/14 22:53, Maxim Kuvyrkov wrote:
The patch looks good to me, but some cleanup suggesti
> > *shortptr = exp
> >
> > var = *shortptr
> > *intptr = exp
> >
> > var = *intptr
>
> Yes (that is, you can't hoist the *intptr = exp store above the var =
> *shortptr
> load with TBAA only). You can probably still hoist the chain with intptr>, it's not clear from your example.
Well,
The following fixes one of the most annoying parts of non-working -ftrapv,
namely that we only support >= word_mode trappings (quite annoying on
64bit archs where 'int' is not handled). At least on x86_64 libgcc
has all the libfuncs available for SImode so the following patch
arranges for them to
On Thu, Jul 24, 2014 at 11:23 AM, Jan Hubicka wrote:
>> > *shortptr = exp
>> >
>> > var = *shortptr
>> > *intptr = exp
>> >
>> > var = *intptr
>>
>> Yes (that is, you can't hoist the *intptr = exp store above the var =
>> *shortptr
>> load with TBAA only). You can probably still hoist th
On Thu, Jul 24, 2014 at 11:53 AM, Richard Biener
wrote:
> On Thu, Jul 24, 2014 at 11:23 AM, Jan Hubicka wrote:
>>> > *shortptr = exp
>>> >
>>> > var = *shortptr
>>> > *intptr = exp
>>> >
>>> > var = *intptr
>>>
>>> Yes (that is, you can't hoist the *intptr = exp store above the var =
>>>
On 22 Jul 21:56, Jeff Law wrote:
> On 04/16/14 08:03, Ilya Enkovich wrote:
> >Hi,
> >
> >This patch introduces changes in call graph for Pointer Bounds Checker.
> >
> >New fields instrumented_version, instrumentation_clone and orig_decl are
> >added for cgraph_node:
> > - instrumentation_clone fi
> Any reason you don't make 'k' a function parameter?
Yes, ISL'll generate the following code, if 'k' a function parameter:
for (int c1 = 0; c1 <= 24; c1 += 1)
S_3(c1);
However, we could use -fno-ipa-cp to get the ISL AST, which contains
isl_ast_op_pdiv_r. What do you think about this?
> Can
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_if.
However, I've found out a problem. When I'm trying to generate Gimple
code from, for example, the following ISL AST:
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
S_6(c1);
if (c1 <= 48) {
S_3(c1);
> Is there a reason you have those global values? To my understanding they
> could possibly just be function parameters?
Yes, it would be fine for this test case. I've implemented this in the
improved version.
--
Cheers, Roman Gareev.
2014-07-23 Roman Gareev
On Jul 24, 2014, at 10:11 AM, Kyrill Tkachov wrote:
> Ping.
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00958.html
>
> Kyrill
>
> On 14/07/14 11:01, Kyrill Tkachov wrote:
>> On 11/07/14 14:20, Alexander Monakov wrote:
>>> On Fri, 11 Jul 2014, Kyrill Tkachov wrote:
On 10/07/14 22:53, M
The ACLE spec does not mention the int32x1_t, uint32x1_t, int16x1_t, uint16x1_t,
int8x1_t or uint8x1_t types currently in arm_neon.h, but just 'standard' types
int32_t, int16_t, etc. This patch is a global search-and-replace across
arm_neon.h (and the tests that depend on it).
Regressed (check
On 24/07/2014 12:09, Roman Gareev wrote:
Any reason you don't make 'k' a function parameter?
Yes, ISL'll generate the following code, if 'k' a function parameter:
for (int c1 = 0; c1 <= 24; c1 += 1)
S_3(c1);
However, we could use -fno-ipa-cp to get the ISL AST, which contains
isl_ast_op_p
On 24/07/2014 12:09, Roman Gareev wrote:
Is there a reason you have those global values? To my understanding they
could possibly just be function parameters?
Yes, it would be fine for this test case. I've implemented this in the
improved version.
LGTM.
Tobias
On 24/07/2014 12:09, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_if.
Nice.
However, I've found out a problem. When I'm trying to generate Gimple
code from, for example, the following ISL AST:
{
for (int c1 = 0; c1 <= 49; c1 += 1)
>
> Aggregate copies and memcpy transferring the dynamic type for example. Being
> able to tbaa union accesses for another. And yes, placement new.
I see that if we previously dropped all union accesses to 0, the current scheme
is nice improvement. But it seem to me it may be in use only when
Jiong Wang writes:
> gcc/testsuite/
> * gcc.dg/ira-shrinkwrap-prep-1.c (target): Add arm_nothumb
> * gcc.dg/ira-shrinkwrap-prep-2.c (target): Add arm_nothumb
> * gcc.dg/pr10474.c (target): Add arm_nothumb
arm_nothumb doesn't check for __arm__, so this enables it everywhere.
Installed as ob
On Tue, 22 Jul 2014, Mike Stump wrote:
> Then I’m shadow boxing. I assumed that people wanted to turn it on by
> default. I’m all for that, I think it is a good idea and a fine
> direction. :-) The only limitation is whitelisting exactly when it
> pops on and preflighting those at least onc
On 22 July 2014 15:52, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_expand_epilogue): Don't subtract
> outgoing area size when restore stack_pointer_rtx.
>
> gcc/testsuite/
> * gcc.target/aarch64/test_frame_12.c: Match optimized instruction
> sequences.
OK and committed.
Hello,
> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
> index a6a51cf..5e702a7 100644
> --- a/gcc/cgraph.h
> +++ b/gcc/cgraph.h
> @@ -191,6 +191,7 @@ struct GTY(()) cgraph_thunk_info {
>tree alias;
>bool this_adjusting;
>bool virtual_offset_p;
> + bool add_pointer_bounds_args;
>/* Set
On Thu, Jul 24, 2014 at 12:46 PM, Jan Hubicka wrote:
>>
>> Aggregate copies and memcpy transferring the dynamic type for example.
>> Being able to tbaa union accesses for another. And yes, placement new.
>
> I see that if we previously dropped all union accesses to 0, the current
> scheme
> is
On 22/07/14 15:52, Jiong Wang wrote:
> currently we are generating sub-optimal epilogue when there
> is frame pointer and there is outgoing area.
>
> take gcc.target/aarch64/test_frame_12.c for example:
>
> the epilogue for test_12 is:
>
>.L12:
>sub sp, x29, #1
On 07/23/2014 06:23 PM, Marat Zakirov wrote:
Hi there!
I made a patch which fixes regressions on ARM platforms with disabled
unaligned accesses. The problem is that 'arm_vect_no_misalign'
predicate do not check 'unaligned_access' global variable to determine
whether unaligned access to vecto
Hi all,
This fixes PR 61876 by not converting the round + cast into an lround
unless -fno-math-errno is specified.
This is because lround can potentially set math errno whereas round +
cast doesn't, so the transformation isn't universally valid.
This will cause the tests:
gcc.target/aarch64/f
Hi,
sorry for late reply, I've been on vacation and then preparing for
Cauldron. Anyway...
On Mon, Jun 30, 2014 at 05:13:13PM +0200, Bernd Schmidt wrote:
> On 06/17/2014 04:54 PM, Martin Jambor wrote:
> >Weird... does the following (untested) patch help?
> >
> >diff --git a/gcc/tree-sra.c b/gcc/
On 24/07/14 13:25, Richard Earnshaw wrote:
On 22/07/14 15:52, Jiong Wang wrote:
currently we are generating sub-optimal epilogue when there
is frame pointer and there is outgoing area.
take gcc.target/aarch64/test_frame_12.c for example:
the epilogue for test_12 is:
Ping.
Original Message
Subject:[PATCH][Ping v4] Add patch for debugging compiler ICEs
Date: Fri, 11 Jul 2014 17:44:28 +0400
From: Maxim Ostapenko
To: GCC Patches
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, Maxim Ostapenko
P
Under new pro/epi code, we could also utilize our store write-back to optimize
stack adjustment when there is no frame pointer.
* if there is candidate reg pair and adjustment amount is less than 512 then we
could use aarch64's paired store write-back.
* if there is only a single candidate reg an
Like [17/N], we do same optimization on epilogue for !frame_pointer_needed.
this is the last of this aarch64 stack patch set.
Improved testcases:
gcc.target/aarch64/test_frame_1.c
gcc.target/aarch64/test_frame_2.c
gcc.target/aarch64/test_frame_4.c
gcc.target/aarch64/tes
The following fixes PR61762 and 61894 by making folding from
const aggregates use native_encode/interpret when reaching
a tcc_constant initializer. To make this work efficiently
the patch introduces the ability to encode only a part of
a tree expression, namely from [off, off + len] when off is
n
sorry, attach patch.
ok for install?
thanks.
gcc/
* config/aarch64/aarch64.c (aarch64_popwb_single_reg): New function.
(aarch64_expand_epilogue): Optimize epilogue when !frame_pointer_needed.
gcc/testsuite/
* gcc.target/aarch64/test_frame_1.c: Match optimized instruction sequences.
On Thu, Jul 24, 2014 at 2:36 PM, Kyrill Tkachov wrote:
> Hi all,
>
> This fixes PR 61876 by not converting the round + cast into an lround unless
> -fno-math-errno is specified.
> This is because lround can potentially set math errno whereas round + cast
> doesn't, so the transformation isn't univ
On Thu, Jul 24, 2014 at 2:38 PM, Martin Jambor wrote:
> Hi,
>
> sorry for late reply, I've been on vacation and then preparing for
> Cauldron. Anyway...
>
> On Mon, Jun 30, 2014 at 05:13:13PM +0200, Bernd Schmidt wrote:
>> On 06/17/2014 04:54 PM, Martin Jambor wrote:
>> >Weird... does the followi
On Sat, Jul 12, 2014 at 8:15 AM, Marc Glisse wrote:
> On Thu, 10 Jul 2014, Richard Biener wrote:
>
>>> --- gcc/tree-into-ssa.c (revision 212109)
>>> +++ gcc/tree-into-ssa.c (working copy)
>>> @@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
>>> {
>>>tree def = DEF_FROM_PTR (de
On 24/07/14 13:51, Richard Biener wrote:
On Thu, Jul 24, 2014 at 2:36 PM, Kyrill Tkachov wrote:
Hi all,
This fixes PR 61876 by not converting the round + cast into an lround unless
-fno-math-errno is specified.
This is because lround can potentially set math errno whereas round + cast
doesn't
On Tue, Jul 22, 2014 at 06:31:32PM +0200, Martin Jambor wrote:
> Hi,
>
> in order to avoid spurious testsuite failures, I've checked in the
> following obvious patch so that the testcase always returns zero. I
> have verified it still properly tests for non-existence of the bug.
...and here goes
Hi Cesar!
On Wed, 23 Jul 2014 17:42:32 -0700, Cesar Philippidis
wrote:
> On 07/11/2014 03:29 AM, Jakub Jelinek wrote:
> > On Fri, Jul 11, 2014 at 12:11:10PM +0200, Thomas Schwinge wrote:
> >> To avoid duplication of work: with Jakub's Fortran OpenMP 4 target
> >> changes recently committed to tr
On Jun 5, 2014, at 3:04 PM, Jiong Wang wrote:
> For AArch64, there may have been an odd num core registers need to be saved.
>
> This small patch ensure we remain 16 byte aligned for subsequent STP writes
> of D registers.
>
> OK for trunk?
Hi Jiong,
How did you test the patch? You need to
2014-07-24 15:38 GMT+04:00 Jan Hubicka :
> Hello,
>
>> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
>> index a6a51cf..5e702a7 100644
>> --- a/gcc/cgraph.h
>> +++ b/gcc/cgraph.h
>> @@ -191,6 +191,7 @@ struct GTY(()) cgraph_thunk_info {
>>tree alias;
>>bool this_adjusting;
>>bool virtual_offs
Hi Maxim,
On 24/07/14 14:16, Maxim Kuvyrkov wrote:
On Jun 5, 2014, at 3:04 PM, Jiong Wang wrote:
For AArch64, there may have been an odd num core registers need to be saved.
This small patch ensure we remain 16 byte aligned for subsequent STP writes of
D registers.
OK for trunk?
Hi Jiong,
Hi all,
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 212635 (4.9.1 release) as r212977, and revert the backport of
the revision 211129 (committed as r212685) as r212866.
This will be part of a 2014.07 respinned release.
Thanks,
Yvan
On 07/24/2014 02:38 PM, Martin Jambor wrote:
This seems to be the statement which has its RHS converted to to a
MEM_REF[&_6], am I right? I wonder whether it is correct input
though, because it looks like it has mismatched types. The LHS is
clearly an aggregate of type struct S while the RHS is
> > So the patch is introducing yet another notion of clone (in addition to
> > existing virtual clones
> > and function versions used by ifun) and you add a new type of reference
> > (CHKP) to link the
> > original and the clone.
> >
> > Why do you need to link things in 3 different ways? (i.e.
Hi,
this patch fixes ARM LTO failures caused by my ctor offlining patch.
The problem is that error_mark_node used to mark offlined ctors is also
used specially thorough varasm.c mostly as an altenrative to "no constructor".
I am not quite sure this code is needed anyway as we don't output variables
> "Hongxu" == Hongxu Jia writes:
Hongxu> I tests on 4.10 (gcc-4.10-20140720), and this issue still existed.
It seems to me that the "generated_files" code should handle this:
generated_files = config.h tm.h $(TM_P_H) $(TM_H) multilib.h \
[...]
$(ALL_HOST_OBJS) : | $(generated_fi
On 22 July 2014 15:52, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.h (frame): New fields "wb_candidate1" and
> "wb_candidate2".
> * config/aarch64/aarch64.c (aarch64_layout_frame): Calcualte new added
> fields.
OK and applied.
/Marcus
On 22 July 2014 15:52, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_save_callee_save_common): New
> parameter "skip_wb".
> (aarch64_restore_callee_save_common): Likewise.
> (aarch64_expand_prologue): Update call site.
> (aarch64_expand_epilogue): Likewise.
The function
On 24 July 2014 13:43, Jiong Wang wrote:
> Under new pro/epi code, we could also utilize our store write-back to
> optimize
> stack adjustment when there is no frame pointer.
>
> * if there is candidate reg pair and adjustment amount is less than 512 then
> we
> could use aarch64's paired store wr
On 24 July 2014 13:48, Jiong Wang wrote:
> gcc/
>* config/aarch64/aarch64.c (aarch64_popwb_single_reg): New function.
>(aarch64_expand_epilogue): Optimize epilogue when !frame_pointer_needed.
>
> gcc/testsuite/
>* gcc.target/aarch64/test_frame_1.c: Match optimized instruction
> sequen
>
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-109.c
> b/gcc/testsuite/gcc.dg/vect/vect-109.c
> index 854c970..fb87e2c 100644
> --- a/gcc/testsuite/gcc.dg/vect/vect-109.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-109.c
> @@ -1,4 +1,4 @@
> -/* { dg-require-effective-target vect_int } */
> +/* { dg-req
strlen() will get string length excluding '\0', but strcpy() will append
'\0' in the end, so need XNEWVEC additional byte, or cause memory over
flow.
Signed-off-by: Chen Gang
---
gcc/gcc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6cd08ea..8e
On 07/23/2014 10:31 PM, Ed Smith-Rowland wrote:
+pedwarn (token->location, OPT_Wpedantic,
+"ISO C++ forbids typename key in template template parameter");
This should mention -std=c++1z.
+ if (tag_type == none_type)
+cp_parser_error (parser, "expected type-parameter-key")
On 07/24/2014 04:27 PM, Marat Zakirov wrote:
On 07/23/2014 06:23 PM, Marat Zakirov wrote:
Hi there!
I made a patch which fixes regressions on ARM platforms with disabled
unaligned accesses. The problem is that 'arm_vect_no_misalign'
predicate do not check 'unaligned_access' global variable
Three targets had the same for_each_rtx function to check for a TLS symbol.
This patch adds a generic version instead.
Some other targets have a variation that checks for target-specific
UNSPEC sequences too so I've left those alone. They're all prefixed
by the target name so there's no name clas
In gcc/configure.ac:
AC_SUBST(enable_accelerator)
offload_targets=`echo $offload_targets | sed -e 's#,#:#'`
AC_DEFINE_UNQUOTED(OFFLOAD_TARGETS, "$offload_targets",
Looks like, it should be: sed -e 's#,#:#g'
-- Ilya
Hello DJ,
sorry for late reply. Patch is ok. Please apply.
Thanks,
Kai
- Original Message -
>
> This patch changes the logic in "crtbegin" that looks for libgcc.dll
> such that the test is only done once, guaranteeing consistent results
> between the register and deregister cases.
>
>
Hi!
On Thu, 20 Mar 2014 15:42:48 +0100, I wrote:
> On Tue, 18 Mar 2014 14:50:44 +0100, I wrote:
> > On Tue, 18 Mar 2014 16:37:24 +0400, Ilmir Usmanov
> > wrote:
> > > This patch introduces support of OpenACC loop directive (and combined
> > > directives) in C front-end up to GENERIC. Currently
Hello!
Adding -g to compile flags breaks unwinding on alpha due to
non-existent FDE entries. This is illustrated by compiling a hello.c
program:
w/o -g:
$gcc -O2 -c hello.c
$ objdump --dwarf=frames-interp hello.o
hello.o: file format elf64-alpha
Contents of the .eh_frame section:
000
> sorry for late reply. Patch is ok. Please apply.
Applied. Thanks!
Rohit wrote:
> This is related to the following bug:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60102
>
> I have tried to fix the e500v2 build on GCC v4.9.0 with the attached patch.
> Can you please review and comment on the changes especially DWARF_FRAME_REG=
> NUM, DWARF_REG_TO_UNWIND_COLU
Well, I was lucky enough to gain access to an alpha pca56 for a day (I say
lucky, this may not be repeatable!). However I was not able to build the Ada
frontend, due (AFAICT) to the image being too big for relocations. (Moreover, my
understanding is that the default memory model for Alpha, is the
On Jul 24, 2014, at 12:06 AM, Jakub Jelinek wrote:
> On Wed, Jul 23, 2014 at 04:52:23PM -0700, Andrew Pinski wrote:
>>> Comments, objections? Ok to apply the preliminary patch?
>>
>> Yes, what if you don't move the tests but just change how the .exp to
>> use the same infrastructure as gcc.dg/tor
[ dup, sorry ]
On Jul 24, 2014, at 12:06 AM, Jakub Jelinek wrote:
> On Wed, Jul 23, 2014 at 04:52:23PM -0700, Andrew Pinski wrote:
>>> Comments, objections? Ok to apply the preliminary patch?
>>
>> Yes, what if you don't move the tests but just change how the .exp to
>> use the same infrastructu
Hello!
> Well, I was lucky enough to gain access to an alpha pca56 for a day (I say
> lucky, this may not be repeatable!). However I was not able to build the Ada
>
> frontend, due (AFAICT) to the image being too big for relocations. (Moreover,
> my understanding is > that the default memory mode
David Edelsohn wrote:
> On Mon, Jul 14, 2014 at 2:52 PM, Ulrich Weigand wrote:
> > gcc/testsuite/ChangLog:
> >
> > * config/rs6000/rs6000.c (rs6000_function_arg): If a float argument
> > does not fit fully into floating-point registers, and there is still
> > space in the r
Hello!
2014-07-24 Uros Bizjak
* go/go-gcc.cc (Gcc_backend::global_variable_set_init): Rename
symtab_get_node to symtab_node::get.
Tested on x86_64-linux-gnu and committed to mainline SVN.
Uros.
Index: go-gcc.cc
===
--- g
Hello!
Attached patch avoids a bunch of:
gcc/fortran/intrinsic.texi:1665: warning: node next `ATOMIC_CAS' in
menu `ATOMIC_FETCH_ADD' and in sectioning `ATOMIC_DEFINE' differ
warnings.
2014-07-24 Uros Bizjak
* intrinsic.texi (Intrinsic Procedures) : Move to
correct menu position to m
2014-07-23 12:04 GMT+04:00 Senthil Kumar Selvaraj
:
> The below patch adds a new preprocessor define for the device name
> (__AVR_DEVICE_NAME__) that was passed to the compiler.
>
> While the device name macro (say __AVR_ATmega128__) can be used to
> check for a specific device, there is no way rig
On 07/24/2014 07:57 PM, Uros Bizjak wrote:
Hello!
2014-07-24 Uros Bizjak
* go/go-gcc.cc (Gcc_backend::global_variable_set_init): Rename
symtab_get_node to symtab_node::get.
Tested on x86_64-linux-gnu and committed to mainline SVN.
Uros.
Hello,
thank you for your fix. As I se
On 07/23/2014 07:29 AM, Richard Biener wrote:
On Wed, Jul 23, 2014 at 12:44 PM, Jason Merrill wrote:
On 07/22/2014 02:34 PM, Richard Biener wrote:
As discussed during the Cauldron keeping some builtin doesn't help because
you are not forced to access the newly created object via the pointer
On 24/07/2014 10:55, Jonathan Wakely wrote:
On 23/07/14 22:33 +0200, François Dumont wrote:
I have a small question regarding some code next to the one I am
modifying in this patch. I can see lines like:
propagating_allocator() noexcept = default;
When using a default implementatio
On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote:
> On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson
> wrote:
> > Jan-Benedict, which host gcc version do you use when getting
> > most targets to build with config-list.mk? Maybe we can just
> > set the initial version to that instead of 4.4.4.
>
First of all, thanks a lot for taking this on! A few nitpicks:
On 07/21/2014 11:06 PM, Braden Obrzut wrote:
grokvardecl (tree type,
tree name,
+tree orig_declarator,
const cp_decl_specifier_seq *declspecs,
int initialized,
int
On Wed, Jul 23, 2014 at 6:29 AM, Jonathan Wakely wrote:
> As an aside, we already have divide-by-zero bugs in , it
> would be nice if someone could look at that.
I'll take a look at this soon.
On 07/17/2014 08:23 AM, Jan Hubicka wrote:
Given my experience about numbers of functions that become reachable when you
stream all virtuals into LTO,
I wonder if we don't want to use possible_polymorphic_call_targets within the
front-end to avoid instantiating
those that can't be called?
Yes
> It seems that the problem here is more general; a template argument list is
> not in scope within that same template argument list. Can't we fix that
> without special-casing conversion ops?
I think conversion ops really are a special case. It's the only case
where the template parameters refer
On 07/24/2014 06:11 AM, Thomas Schwinge wrote:
> OMP_LIST_DEVICEPTR remains to be converted, which can be done as a later
> follow-up patch.
Yes, that's the plan.
> I'd suggest to continue to handle all the data clauses...
>
>>
>> /* Match OpenMP and OpenACC directive clauses. MASK is a bitm
On 24 July 2014 22:15, Ulrich Drepper wrote:
> On Wed, Jul 23, 2014 at 6:29 AM, Jonathan Wakely wrote:
>> As an aside, we already have divide-by-zero bugs in , it
>> would be nice if someone could look at that.
>
> I'll take a look at this soon.
That would be great, thanks!
On 24 July 2014 21:11, François Dumont wrote:
>
> Yes I have tested with no other changes in my tree and got only those pretty
> printers errors which are unrelated I think:
>
> Python Exception iter() returned non-iterator of type
> '_contained':
> $2 = std::experimental::optional [no contained v
``
> >Given my experience about numbers of functions that become reachable when
> >you stream all virtuals into LTO,
> >I wonder if we don't want to use possible_polymorphic_call_targets within
> >the front-end to avoid instantiating
> >those that can't be called?
>
> Yes, I think we need to do
This version addresses the review feedback. begin is gone now.
add_flag is in the class. The changes in tree.c are nearer
the original code now. Some other minor cleanups.
Passed bootstrap and test and x86_64-linux. Ok to commit
now?
Thanks,
-Andi
From: Andi Kleen
Should not really change any behavior, it's just a more abstract
interface, but uses the same underlying hash functions.
lto/:
2014-07-24 Andi Kleen
* lto.c (hash_canonical_type): Convert to inchash.
(iterative_hash_canonical_type): Dito.
---
gcc/lto/lto.c
From: Andi Kleen
Some files in gcc, like lto or tree, do large scale incremential hashing.
The current jhash implementation of this could be likely improved
by using an incremential hash that does not do a full rehashing
for every new value added.
This patch adds a new "inchash" class that abstr
From: Andi Kleen
No substantial changes, although the hash values will be slightly
different.
v2: add_flag moved to inchash. Some minor changes.
gcc/:
2014-07-24 Andi Kleen
* lto-streamer-out.c (hash_tree): Convert to inchash.
---
gcc/lto-streamer-out.c | 251 +
From: Andi Kleen
v2: Use commutative interface. Be much nearer to the old
code.
gcc/:
2014-07-24 Andi Kleen
* tree.c (build_type_attribute_qual_variant): Use inchash.
(type_hash_list): Dito.
(attribute_hash_list): Dito
(iterative_hstate_expr): Dito.
(
No, I didn't.
2014-07-24 16:50 GMT+08:00 Richard Biener :
> On Thu, Jul 24, 2014 at 3:52 AM, Pengfei Yuan <0xcool...@gmail.com> wrote:
>> There are more.
>>
>> In toplev.c:
>> /* One region RA really helps to decrease the code size. */
>> if (flag_ira_region == IRA_REGION_AUTODETECT)
>> f
1 - 100 of 109 matches
Mail list logo
