2013/6/16 Ondřej Bílka :
> On Sat, Jun 15, 2013 at 05:13:31PM +0800, Chung-Ju Wu wrote:
>> 2013/6/14 Joseph S. Myers :
>> > On Thu, 13 Jun 2013, Richard Biener wrote:
>> >
>> >> Btw, rather than these kind of patches I'd appreciate if someone would
>> >> look
>> >> at a simple pre(post?)-commit ho
OK
/Marcus
On 17 June 2013 14:43, Yufeng Zhang wrote:
> Hi,
>
> This patch sets STACK_ARGUMENTS_SIZE with 0 for AArch64 as variadic
> arguments to 'bar' are passed in registers on this target.
>
> OK for the trunk?
>
> Thanks,
> Yufeng
>
> gcc/testsuite/
>
> * gcc.dg/torture/stackalign/bu
I'd like to apply the following set of patches supporting powerpc64le
to the 4.8 branch. David has stated that he's happy with the idea,
even though technically these are not regressions. OK?
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01374.html
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg002
2013/6/18 David Edelsohn :
> gcc/testsuite/ChangeLog
> 2013-06-17 Sebastian Huber
>
> PR target/55033
> * gcc.target/powerpc/pr55033.c: Fix options.
>
> Okay.
>
> Thanks, David
>
> P.S. Please explicitly copy me on patches.
Hi, Sebastian,
Since David has pproved your patch,
do you need me to h
On 06/17/13 12:23, Richard Henderson wrote:
On 06/17/2013 10:13 AM, Aldy Hernandez wrote:
- data.simduid = tree_low_cst (gimple_call_arg (stmt, 0), 1);
+ data.simduid = gimple_call_arg (stmt, 0);
Doesn't this copy the ADDR_EXPR from the call into simduid?
simduid_to_vf::has
On Mon, Jun 17, 2013 at 2:20 PM, Jason Merrill wrote:
>> I have not thought deeply about constrained friend declarations. What
>> would a friend temploid look like?
>
>
> I was thinking something like
>
> template struct A {
> T t;
> requires Addable()
> friend A operator+(const A& a1, cons
Hi,
On 06/17/2013 10:30 PM, Jason Merrill wrote:
On 06/17/2013 04:08 PM, Paolo Carlini wrote:
+ if (TREE_CODE (TREE_TYPE (*tp)) == ARRAY_TYPE
+ && !TYPE_DOMAIN (TREE_TYPE (*tp))
+ && DECL_INITIAL (*tp)
+ && type_dependent_expression_p (DECL_INITIAL (*tp)))
+return *tp;
Earlier today I wrote:
On 06/17/2013 08:41 AM, Joseph S. Myers wrote:
On Mon, 17 Jun 2013, Julian Brown wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour and the C++ memory model is a
recognised deficiency in the ARM EABI. It might be an unpopular
su
On Thu, Jun 13, 2013 at 11:37 AM, Alan Modra wrote:
> Revised patch with offsettable_ok_by_alignment change, avoiding dumb
> idea of using statement expressions. This one actually bootstraps and
> passes regression testing.
>
> * config/rs6000/rs6000.h (enum data_align): New.
> (
Hello,
I tried to compile LTO kernel with latest gcc, applied patch by
Jan http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334#c6:
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto_symtab_prevailing_decl(tree_node*)
../../gcc/lto-symtab.c:644
0x50afe4
Andi Kleen wrote:
>
>Current trunk cannot build LTO kernels now, with your patch,
>as reported earlier.
>
>Please fix ASAP. I'm surprised that you checked in a patchkit
>with such serious reported problems.
Instructions for reproducing this issue appreciated. I've never built lto
kernels.
Ric
On 06/17/2013 04:08 PM, Paolo Carlini wrote:
+ if (TREE_CODE (TREE_TYPE (*tp)) == ARRAY_TYPE
+ && !TYPE_DOMAIN (TREE_TYPE (*tp))
+ && DECL_INITIAL (*tp)
+ && type_dependent_expression_p (DECL_INITIAL (*tp)))
+ return *tp;
I think this approach makes sense, but
Hi,
while triaging this PR (the original issue is already fixed) Jonathan
added to the audit trail the attached testcase, which we are still
mishandling. It seems to me that something is wrong in
instantiation_dependent_expression_p: when finish_decltype_type is
called the first time by the p
On Mon, 2013-06-17 at 10:41 +0200, Eric Botcazou wrote:
> > My mistake. It's because arm_legitimize_address cannot re-factor "[r105 +
> > r165*4 + (-2064)]" into "rx = r105 + (-2064); [rx + r165*4]". Do you
> > suggest that this kind of transformation should be done in backend? I can
> > think of
On 06/17/2013 02:10 PM, Andrew Sutton wrote:
You mean you don't need anymore in logic.cc? I think we want
the include in general if we're going to support people using the
C++ standard library.
I don't. Those decisions are above my pay grade, so I'm doing my best
not to make them.
If you d
Ping? I think these are the most recent versions of the unreviewed
patches in the series:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00287.html
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00760.html
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01085.html
There are also these two parts that
On 06/17/2013 02:09 PM, Jakub Jelinek wrote:
On Mon, Jun 17, 2013 at 01:44:25PM -0400, Jason Merrill wrote:
On 06/17/2013 12:54 PM, Joseph S. Myers wrote:
I suppose it's OK to fix the regression, though really we should be
eliminating these early convert_to_* optimizations (optimizing later on
Ping.
Thanks,
Sharad
On Wed, Jun 5, 2013 at 11:18 AM, Sharad Singhai wrote:
> Ping.
>
> Thanks,
> Sharad
>
>
> On Tue, May 28, 2013 at 11:35 AM, Sharad Singhai wrote:
>> Sorry, my patch had bad formatting in one of the functions
>> (output_gcov_file). Here is the corrected version.
>>
>> Thank
Hello Everyone,
I am adding a new execution test to the array notation suite. In array
notation's __sec_reduce_max_ind and __sec_reduce_min_ind builtin functions, if
there is a tie for max/min value, then the higher index should be returned. In
this case, all the values are the same, so
>> 2. I left the include in system.h, because removing it will
>> result in errors due to an inclusion of . It's probable
>> that both can be removed, but I didn't test it with this patch.
>
>
> You mean you don't need anymore in logic.cc? I think we want
> the include in general if we're going
On Mon, Jun 17, 2013 at 01:44:25PM -0400, Jason Merrill wrote:
> On 06/17/2013 12:54 PM, Joseph S. Myers wrote:
> >I suppose it's OK to fix the regression, though really we should be
> >eliminating these early convert_to_* optimizations (optimizing later on
> >GIMPLE if possible) rather than adding
Current trunk cannot build LTO kernels now, with your patch,
as reported earlier.
Please fix ASAP. I'm surprised that you checked in a patchkit
with such serious reported problems.
-Andi
backup/lsrc/git/linux-lto-2.6/lib/decompress_unlzo.c: In function 'unlzo':
/backup/lsrc/git/linux-lto-2.6/
On Fri, Jun 14, 2013 at 11:08 AM, Sriraman Tallam wrote:
> On Fri, Jun 14, 2013 at 1:43 AM, Richard Biener
> wrote:
>> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
>>> On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
> * tree-inline.c (expand_call_inline): Allow the err
On 06/17/2013 12:54 PM, Joseph S. Myers wrote:
I suppose it's OK to fix the regression, though really we should be
eliminating these early convert_to_* optimizations (optimizing later on
GIMPLE if possible) rather than adding to them.
My thought as well. How hard is it to fix this in gimple fo
2013/6/17 Richard Henderson :
> On 06/16/2013 11:55 PM, Kai Tietz wrote:
>> +static bool
>> +ix86_function_attribute_inlinable_p (const_tree fndecl ATTRIBUTE_UNUSED)
>> +{
>> + return true;
>> +}
>
> This is hook_bool_const_tree_true.
Right, we could define macro to this ...
> I have an idea tha
On 06/17/2013 10:18 AM, Jan Hubicka wrote:
Does ODR hold also for extern "C" declarations in C++?
Yes.
In C, you can treat all structurally identical types as the same, right?
In next step we can sort out other reasons they
are not merged by Richard's merging code but stil equivalent in C++
On Mon, Jun 17, 2013 at 10:12:41AM +0200, Jan Hubicka wrote:
> > > CPU: AMD64 family10, speed 2100 MHz (estimated)
> > > Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
> > > unit mask of 0x00 (No unit mask) count 75
> > > samples %app name symbol
On Mon, 2013-06-17 at 11:18 +0200, Richard Biener wrote:
> On Fri, Jun 14, 2013 at 11:17 PM, David Malcolm wrote:
> > ggc_pch_write_object's parameter "d" is marked with ATTRIBUTE_UNUSED,
> > but in fact it is used in 4 places at the end of the function.
> >
> > Successfully bootstrapped on x86_64
On 06/17/2013 10:13 AM, Aldy Hernandez wrote:
> - data.simduid = tree_low_cst (gimple_call_arg (stmt, 0), 1);
> + data.simduid = gimple_call_arg (stmt, 0);
Doesn't this copy the ADDR_EXPR from the call into simduid?
> simduid_to_vf::hash (const value_type *p)
> {
> - return p->simd
On 06/12/13 16:36, Jakub Jelinek wrote:
On Wed, Jun 12, 2013 at 10:38:00AM -0700, Richard Henderson wrote:
On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
So the built-ins would take address of this decl, something else?
Perhaps address, perhaps just referenced uninitialized?
True, assuming no
On 06/17/2013 10:00 AM, Iyer, Balaji V wrote:
> In hindsight, I could have for __sec_reduce_max and __sec_reduce_min. I was
> more familiar with conditional expression. Out of curiosity, is there a big
> performance benefit of using max/min expr over conditional?
There can be. The COND->MIN/MAX t
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Richard Henderson
> Sent: Thursday, June 13, 2013 12:19 PM
> To: Aldy Hernandez
> Cc: Iyer, Balaji V; gcc-patches@gcc.gnu.org; Jason Merrill (ja...@redhat.com)
> Subject: Re:
On Mon, 17 Jun 2013, Jakub Jelinek wrote:
> The following patch shows a performance regression caused by the C++ changes
> to evaluate side-effects in x += foo (); first and only then do the
> addition. Previously if x was say int and foo () returned unsigned long
> long, convert_to_integer would
On 06/17/2013 08:41 AM, Joseph S. Myers wrote:
On Mon, 17 Jun 2013, Julian Brown wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour and the C++ memory model is a
recognised deficiency in the ARM EABI. It might be an unpopular
suggestion, but how about d
Hi!
lex_raw_string right now only undoes phase {1,2} transformations in between
R"delim( and )delim", while it should undo them everywhere between R" and
the final ". The following patch implements that, and adds testsuite
coverage for that. Bootstrapped/regtested on x86_64-linux and i686-linux,
Hello Everyone,
This patch will make one of the array notation tests a runnable one
instead of a compile only. I have also changed the return values from just '1'
to distinct values so that it is easier to debug. This patch is committed as
obvious.
Here is the ChangeLog entry:
+2013-06
On 06/16/2013 11:55 PM, Kai Tietz wrote:
> +static bool
> +ix86_function_attribute_inlinable_p (const_tree fndecl ATTRIBUTE_UNUSED)
> +{
> + return true;
> +}
This is hook_bool_const_tree_true.
I have an idea that perhaps the default ought to be true, and that the few
targets (like mep) that hav
Hi!
The following patch shows a performance regression caused by the C++ changes
to evaluate side-effects in x += foo (); first and only then do the
addition. Previously if x was say int and foo () returned unsigned long
long, convert_to_integer would narrow the addition to unsigned int, but
as w
Hi!
This instruction has the predicates/constraints wrong, the r/m argument is
the middle-one, the value from which it should be extracted, rather than
the packed start/length argument. This got broken with PR50766, where the
patch hasn't touched just BMI2, but for unknown reasons also this BMI
i
On Mon, Jun 17, 2013 at 03:52:54PM +, Joseph S. Myers wrote:
> On Mon, 17 Jun 2013, Jakub Jelinek wrote:
>
> > > +; What the sanitizer should instrument
> > > +Variable
> > > +unsigned int flag_sanitize
> >
> > Can't you just add Var(flag_sanitize) to the line after fsanitize= ?
>
> I think
gcc/testsuite/ChangeLog
2013-06-17 Sebastian Huber
PR target/55033
* gcc.target/powerpc/pr55033.c: Fix options.
Okay.
Thanks, David
P.S. Please explicitly copy me on patches.
On Mon, 17 Jun 2013, Jakub Jelinek wrote:
> > +; What the sanitizer should instrument
> > +Variable
> > +unsigned int flag_sanitize
>
> Can't you just add Var(flag_sanitize) to the line after fsanitize= ?
I think that would create a string variable, whereas an integer is what's
wanted here.
--
On 17/06/13 16:03, Sofiane Naci wrote:
Hi,
This patch adds a r<-w alternative to the aarch64_dup_lane pattern and
updates the testcase gcc.target/aarch64/scalar_intrinsics.c accordingly.
The patch has been successfully tested on a full regression run in
aarch64-none-elf.
OK for trunk?
-
T
Hi,
This patch adds a r<-w alternative to the aarch64_dup_lane pattern and
updates the testcase gcc.target/aarch64/scalar_intrinsics.c accordingly.
The patch has been successfully tested on a full regression run in
aarch64-none-elf.
OK for trunk?
-
Thanks
Sofiane
aarch64-dup-alternative.d
Hi!
Looks good, though I'd appreciate Joseph to look at this from the
option handling POV. Some nits from me below:
On Fri, Jun 14, 2013 at 09:04:40PM +0200, Marek Polacek wrote:
> --- gcc/opts.c.mp 2013-06-14 19:23:02.300554991 +0200
> +++ gcc/opts.c2013-06-14 20:00:30.377638168 +02
On Mon, 17 Jun 2013, Julian Brown wrote:
> IIUC, the incompatibility between the specified
> -fstrict-volatile-bitfields behaviour and the C++ memory model is a
> recognised deficiency in the ARM EABI. It might be an unpopular
> suggestion, but how about disabling the option by default for C++ on
On Mon, 17 Jun 2013, Marek Polacek wrote:
> This improves the diagnostics messages in case we're using initial
> declarations in the for loop, but we're not using C99 or newer standard;
> in this case we shouldn't forget about =c11 and =gnu11, where the
> initial declaration is fine as well.
>
>
> On Mon, 17 Jun 2013, Jan Hubicka wrote:
>
> > > On 06/17/2013 09:35 AM, Jan Hubicka wrote:
> > > >To get meaningful warnings, we need to know what decls/types are subject
> > > >to ODR. Do you think you can make C++ FE to drop a flag so middle-end
> > > >know?
> > > >We can LTO ODR and non-ODR
On Mon, 17 Jun 2013, Jan Hubicka wrote:
> > On 06/17/2013 09:35 AM, Jan Hubicka wrote:
> > >To get meaningful warnings, we need to know what decls/types are subject
> > >to ODR. Do you think you can make C++ FE to drop a flag so middle-end know?
> > >We can LTO ODR and non-ODR languages together.
> On 06/17/2013 09:35 AM, Jan Hubicka wrote:
> >To get meaningful warnings, we need to know what decls/types are subject
> >to ODR. Do you think you can make C++ FE to drop a flag so middle-end know?
> >We can LTO ODR and non-ODR languages together.
>
> Basically everything in C++ is subject to th
On 06/17/2013 09:35 AM, Jan Hubicka wrote:
To get meaningful warnings, we need to know what decls/types are subject
to ODR. Do you think you can make C++ FE to drop a flag so middle-end know?
We can LTO ODR and non-ODR languages together.
Basically everything in C++ is subject to the ODR. Ther
Hi,
This patch sets STACK_ARGUMENTS_SIZE with 0 for AArch64 as variadic
arguments to 'bar' are passed in registers on this target.
OK for the trunk?
Thanks,
Yufeng
gcc/testsuite/
* gcc.dg/torture/stackalign/builtin-apply-2.c: set
STACK_ARGUMENTS_SIZE with 0 if __aarch64__ is
> On 06/17/2013 09:09 AM, Jan Hubicka wrote:
> >also one quick question. I was dumping on when my odr tests fails and only
> >case I do not understand is the case where decls_same_for_odr ends up
> >comparing
> >IDENTIFIER_NODE and TYPE_DECL of the same name.
>
> Hmm, I would guess that it comes
> On 06/17/2013 09:07 AM, Jan Hubicka wrote:
> >>Yes. Also for template instantiations and inline functions
> >>(basically, decls with TREE_COMDAT set). That isn't very
> >
> >Can't those be just merged based on assembler name?
>
> Yes, though they can have local classes that are also subject to
On 06/17/2013 09:09 AM, Jan Hubicka wrote:
also one quick question. I was dumping on when my odr tests fails and only
case I do not understand is the case where decls_same_for_odr ends up comparing
IDENTIFIER_NODE and TYPE_DECL of the same name.
Hmm, I would guess that it comes from TYPE_NAME b
On 06/17/2013 09:07 AM, Jan Hubicka wrote:
Yes. Also for template instantiations and inline functions
(basically, decls with TREE_COMDAT set). That isn't very
Can't those be just merged based on assembler name?
Yes, though they can have local classes that are also subject to the ODR.
I th
Hi,
also one quick question. I was dumping on when my odr tests fails and only
case I do not understand is the case where decls_same_for_odr ends up comparing
IDENTIFIER_NODE and TYPE_DECL of the same name. Does this mean that they are
different in class hiearchy or do I miss some equality case?
> On 06/17/2013 06:05 AM, Jan Hubicka wrote:
> >It is my understanding that C++ standard enforces one definition rule for
> >types, too (to enable sane mangling?) and that we can basically match types
> >by their name and contextes (namespaces/outer classes)?
>
> Yes. Also for template instantiat
OK.
Jason
On 06/17/2013 06:05 AM, Jan Hubicka wrote:
It is my understanding that C++ standard enforces one definition rule for
types, too (to enable sane mangling?) and that we can basically match types
by their name and contextes (namespaces/outer classes)?
Yes. Also for template instantiations and inl
On Mon, Jun 17, 2013 at 2:38 PM, Bernd Schmidt wrote:
> On 06/17/2013 02:27 PM, Julian Brown wrote:
>> On Mon, 17 Jun 2013 13:38:05 +0200
>> Richard Biener wrote:
>>
>>> On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
>>> wrote:
IIUC, the incompatibility between the specified
-fstrict-vo
On 06/17/2013 02:27 PM, Julian Brown wrote:
> On Mon, 17 Jun 2013 13:38:05 +0200
> Richard Biener wrote:
>
>> On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
>> wrote:
>>> IIUC, the incompatibility between the specified
>>> -fstrict-volatile-bitfields behaviour and the C++ memory model is a
>>> re
On Mon, Jun 17, 2013 at 01:27:38PM +0100, Julian Brown wrote:
> Well -- I'm certainly no expert on the C++ memory model, but I am under
> the impression (that I can't seem to verify by googling ;-)) that
> accesses to adjacent bitfields during volatile access of a particular
> bitfield are forbidde
On Mon, 17 Jun 2013 13:38:05 +0200
Richard Biener wrote:
> On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
> wrote:
> > On Mon, 17 Jun 2013 13:12:09 +0200
> > Richard Biener wrote:
> >
> >> On Sun, Jun 16, 2013 at 9:26 PM, Jakub Jelinek
> >> wrote:
> >> > On Sun, Jun 16, 2013 at 01:08:12PM -0600
Hello Everyone,
Is this patch OK for trunk?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Wednesday, June 12, 2013 1:22 PM
> To: gcc-patches@gcc.gnu.org
> Cc: anna.m.tikhon...@gmail.com
> Subject: [PATCH] for for c/PR57541
>
> Hello Everyone,
>
> On Mon, Jun 17, 2013 at 11:53 AM, Jan Hubicka wrote:
> > Hi,
> > this patch makes it possible to fold through aliases. It may seem
> > unimportant, but we
> > run into those cases in C++ where extra name aliases may get used by
> > devirtualization
> > machinery. The patch also fixes the fol
On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown wrote:
> On Mon, 17 Jun 2013 13:12:09 +0200
> Richard Biener wrote:
>
>> On Sun, Jun 16, 2013 at 9:26 PM, Jakub Jelinek
>> wrote:
>> > On Sun, Jun 16, 2013 at 01:08:12PM -0600, Sandra Loosemore wrote:
>> >> This patch fixes the PR23623 regression. I
On Mon, 17 Jun 2013 13:12:09 +0200
Richard Biener wrote:
> On Sun, Jun 16, 2013 at 9:26 PM, Jakub Jelinek
> wrote:
> > On Sun, Jun 16, 2013 at 01:08:12PM -0600, Sandra Loosemore wrote:
> >> This patch fixes the PR23623 regression. In conjunction with part
> >> 2 of the series, it also fixes the
This patch makes the following changes:
* Define MAX_CONDITIONAL_EXECUTE in arm backend using max_insns_skipped,
which is set based on the current tune.
* Update max_insns_skipped for Cortex-A15 tune to be 2 (instead of 5).
* Use max_insns_skipped in thumb2_final_prescan_insn to decide when to
com
Hi,
This patch fixes an ICE where the compiler crashes (with NEON enabled)
during expansion of an instruction such as:
pr48335-5.c:17:1: error: unrecognizable insn:
}
^
(insn 9 8 10 2 (set (reg:DI 116 [ s ])
(unspec:DI [
(mem/c:DI (plus:SI (reg/f:SI 105 virtual-stack-var
On Sun, Jun 16, 2013 at 9:26 PM, Jakub Jelinek wrote:
> On Sun, Jun 16, 2013 at 01:08:12PM -0600, Sandra Loosemore wrote:
>> This patch fixes the PR23623 regression. In conjunction with part 2
>> of the series, it also fixes the new volatile-bitfields-3.c test
>> case.
>>
>> As I noted in previou
Tested on powerpc64-unknown-linux-gnu with:
make -k check RUNTESTFLAGS="--target_board=unix'{-m64,-m32,-m32/-mpowerpc64}'"
gcc/testsuite/ChangeLog
2013-06-17 Sebastian Huber
PR target/55033
* gcc.target/powerpc/pr55033.c: Fix options.
---
gcc/testsuite/gcc.target/powerpc/pr55
On Mon, Jun 17, 2013 at 11:53 AM, Jan Hubicka wrote:
> Hi,
> this patch makes it possible to fold through aliases. It may seem
> unimportant, but we
> run into those cases in C++ where extra name aliases may get used by
> devirtualization
> machinery. The patch also fixes the following long st
Hi Zhenqiang,
This patch causes PR57637 (miscompare in SPEC2000). I'll try to reduce a
testcase.
Thanks,
Kyrill
> The *arm_simple_return is the same as "simple_return" used by
> shrink-wrap. *arm_return and *arm_simple_return are not merged
> since
> *arm_return is for "Often the return insn wil
Hi,
during LTO we seem to give up on many valid devirtualization cases because
the types are not merged by type merging machinery. This is i.e. because their
declarations are different; one unit define a function, while in the other
unit it is just an external declaration.
It is my understanding t
Hi,
this patch makes it possible to fold through aliases. It may seem unimportant,
but we
run into those cases in C++ where extra name aliases may get used by
devirtualization
machinery. The patch also fixes the following long standing bug:
jh@gcc10:~/trunk/build2/gcc$ cat t.c
static int a=4;
s
This improves the diagnostics messages in case we're using initial
declarations in the for loop, but we're not using C99 or newer standard;
in this case we shouldn't forget about =c11 and =gnu11, where the
initial declaration is fine as well.
Ok for trunk?
2013-06-17 Marek Polacek
PR
On 06/17/13 10:24, Kyrylo Tkachov wrote:
Hi all,
This arm testsuite patch initialises an array in the
unaligned-memcpy-2.c test to ensure alignment, making the test pass.
This is similar to the patch
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00683.html.
Ok for trunk?
Ok - thanks for catchi
Hi all,
This arm testsuite patch initialises an array in the
unaligned-memcpy-2.c test to ensure alignment, making the test pass.
This is similar to the patch
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00683.html.
Ok for trunk?
Thanks,
Kyrill
gcc/testsuite/
2013-06-17 Kyrylo Tkachov
On Fri, Jun 14, 2013 at 11:17 PM, David Malcolm wrote:
> ggc_pch_write_object's parameter "d" is marked with ATTRIBUTE_UNUSED,
> but in fact it is used in 4 places at the end of the function.
>
> Successfully bootstrapped on x86_64-unknown-linux-gnu.
>
> OK for trunk?
Ok.
Thanks,
Richard.
> 201
On Fri, Jun 14, 2013 at 6:31 PM, Sandra Loosemore
wrote:
> On 06/14/2013 06:31 AM, Richard Biener wrote:
>
>> I think we can split the patch up, so let me do piecewise approval of
>> changes.
>>
>> The changes that remove the packedp flag passing around and remove
>> the warning code are ok. The
On Mon, 17 Jun 2013, Kugan wrote:
> Can you please help to review this patch? Richard reviewed the original patch
> and asked it to be split into two parts. Also, he wanted a review from RTL
> maintainer for the RTL changes.
>
> Thanks,
> Kugan
>
> On 03/06/13 11:43, Kugan wrote:
> > Hi,
> >
>
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Monday, June 17, 2013 4:42 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address
mode
> when expanding array reference
>
> > My mistake.
Ping?
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00493.html
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 10 June 2013 11:52
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw; Ra
> My mistake. It's because arm_legitimize_address cannot re-factor "[r105 +
> r165*4 + (-2064)]" into "rx = r105 + (-2064); [rx + r165*4]". Do you
> suggest that this kind of transformation should be done in backend? I can
> think of some disadvantages by doing it in backend:
> Different kinds of
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Monday, June 17, 2013 3:32 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address
mode
> when expanding array reference
>
> > The problem
> > CPU: AMD64 family10, speed 2100 MHz (estimated)
> > Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit
> > mask of 0x00 (No unit mask) count 75
> > samples %app name symbol name
> > 4504711.7420 lto1 inflate_fast
>
On Sat, 15 Jun 2013, Jan Hubicka wrote:
> >
> > I've managed to fix nearly all reported missed merged types for cc1.
> > Remaining are those we'll never be able to merge (merging would
> > change the SCC shape) and those that eventually end up refering
> > to a TYPE_STUB_DECL with a make_anon_nam
On Mon, Jun 17, 2013 at 09:46:30AM +0200, Eric Botcazou wrote:
> > This really should come with testcases (e.g. guality ones).
>
> guality testcases are barely maintainable, especially on non-x86 platforms,
> so
> I'd rather not enter this business. I'll discuss with Joel and see whether
> we
> This really should come with testcases (e.g. guality ones).
guality testcases are barely maintainable, especially on non-x86 platforms, so
I'd rather not enter this business. I'll discuss with Joel and see whether we
can coordinate with the GDB side.
--
Eric Botcazou
> The problem occurs when accessing local array element. For example,
> # VUSE <.MEM_27>
> k_8 = parent[k_29];
>
> GCC calculates the address in three steps:
> 1) addr is calculated as "r105 + (-2064)".
> 2) offset is calculated as "r165*4".
> 3) calls offset_address to combine the address into "r
91 matches
Mail list logo
