On Mon, Jun 17, 2013 at 01:28:56AM +0300, Sergey Kljopov wrote:
Hi,
Reading the text
-
In a structure initializer, specify the name of a field to
initialize with `.fieldname =' before the element value. For
example, given the following structure,
struct point { int x, y;
I wrote the following test:
union foo { int i; double d; };
int main(int argc, char **argv)
{
union foo f = { .d = 4 };
ASSERT_EQ(0, f.i);
ASSERT_FEQ(4.0, f.d);
return 0;
}
ASSERT_EQ and ASSERT_FEQ are some macros which checks the falue and
gives some error
Hi Peter,
On Sat, Jun 15, 2013 at 2:44 AM, Peter Bergner berg...@vnet.ibm.com wrote:
I'm currently implementing support for hardware transactional memory in
the rs6000 backend for POWER8. Things seem to be mostly working, but I
have run into a few issues I'm wondering whether other people are
On Mon, 17 Jun 2013, Kugan wrote:
Hi,
I am attempting to fix Bug 43721 - Failure to optimise (a/b) and (a%b) into
single __aeabi_idivmod call
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721)
execute_cse_sincos tree level pass does similar cse so I attempted to use
similar approach
Hi,
I'm a Xen developer. We have coverage support (lcov replacement) in
order to extract coverage information. However would be very helpful to
have a way to put counters, structures and strings (file names) related
to coverage in different section. Actually there are no such options (it
would
In an environment with relatively old core components (dynamic
loader and glibc) but with up-to-date binutils (perhaps built along
with gcc) libatomic.so gets built in a way such that it is unusable
on the build system. A similar issue was reported in a mail leading
to
On Mon, 17 Jun 2013, Jan Beulich wrote:
expect runtime properties to be taken into account here. And
for cross builds I'd expect a way to control whether the final
binary would be using GNU IFUNC symbols rather than just
making this dependent upon tool chain capabilities.
For cross builds to
Hi,
I'm a Xen developer. We have coverage support (lcov replacement) in
order to extract coverage information. However would be very helpful to
have a way to put counters, structures and strings (file names) related
to coverage in different section. Actually there are no such options (it
On Mon, 2013-06-17 at 17:32 +0200, Jan Hubicka wrote:
Hi,
I'm a Xen developer. We have coverage support (lcov replacement) in
order to extract coverage information. However would be very helpful to
have a way to put counters, structures and strings (file names) related
to coverage in
I have a loop induction variable question involving post increment.
If I have this loop:
void *memcpy_word_ptr(int * __restrict d, int * __restrict s, unsigned int n )
{
int i;
for(i=0; in; i++) {*d++ = *s++; }
return d;
}
and compile it with: -O3 -fno-tree-loop-distribute-patterns,
the
On Mon, 2013-06-17 at 10:07 -0700, Steve Ellcey wrote:
I have a loop induction variable question involving post increment.
If I have this loop:
[...]
My question is is: why (and where) did ivopts decide to move the
post-increments above the usages in the first loop? In my case
(MIPS) the
On Mon, 2013-06-17 at 21:36 +0200, Oleg Endo wrote:
Sorry for not having an answer. I got curious, because just yesterday I
was looking at this one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
and thought that this is related, although it doesn't seem to.
I've tried the two functions
2013/6/18 Steve Ellcey sell...@mips.com:
On Mon, 2013-06-17 at 21:36 +0200, Oleg Endo wrote:
Sorry for not having an answer. I got curious, because just yesterday I
was looking at this one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
and thought that this is related, although it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53425
jbeulich at novell dot com changed:
What|Removed |Added
CC||jbeulich at novell dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Actually, seems the 3 argument Intel intrinsic is _bextr_u{32,64}, while the
GCC
intrinsic is __bextr_u{32,64}, so guess the two can coexist, we just need to
add the 3 argument one.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
Bug ID: 57633
Summary: I/O: Problem with formatted read: reading an
incomplete record under Windows
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Summary|I/O: Problem with formatted |I/O: Problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57634
Bug ID: 57634
Summary: Missed vectorization for a fixed point
multiplication reduction
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org ---
Another comment, which I missed to pass on from the original report:
It is crucial that the first line ends with a comma; without comma it works.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635
Bug ID: 57635
Summary: gcc hanging while compiling huge files
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635
--- Comment #1 from vijay Nag vijunag at gmail dot com ---
Let me know if you will need any additional information. It is also difficult
to isolate one single huge file from my project to attach it here. It will be
great if you can suggest me to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Attachment #30315|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636
Bug ID: 57636
Summary: cr16: ICE while building libgcc
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
--- Comment #3 from lailavrazda1979 at gmail dot com ---
Looks good to me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637
Bug ID: 57637
Summary: Miscompare on 178.galgel in SPEC2000 on arm
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
I've just come across a case where an option to disable that warning would be
handy: We have a foo.cc file defining some classes in an anon namespace. A unit
test does #include foo.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184
--- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com ---
Somebody could suggest an appropriate name for the warning. Then a patchlet
would be easy to do and also easy to approve I think (naming warnings is in
general a sensible idea)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com ---
... and of course a clearer wording for the warning itself.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53394
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16128
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55895
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
The original testcase (in Comment #0) is fixed in 4.8.1 and mainline as
duplicate of PR56794.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org ---
(gdb) p debug_tree (fn-decl)
function_decl 0x77045f00 soap_getindependent
type function_type 0x77042e70
type integer_type 0x76f155e8 int public SI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #182 from Jan Hubicka hubicka at gcc dot gnu.org ---
OK, after a while I should update the stats here. Richard's new tree merging
patch makes libxul linking a lot faster and less memory consuming.
Peak memory usage (in TOP) is now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
For comment #1, it looks like there is something wrong in
instantiation_dependent_expression_p: when finish_decltype_type calls it for
arr it returns false, where it seems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53950
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #183 from Jan Hubicka hubicka at gcc dot gnu.org ---
type merging stats
[WPA] read 43156894 SCCs of average size 2.270660
[WPA] 97994652 tree bodies read in total
[WPA] tree SCC table: size 8388593, 3830511 elements, collision ratio:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773
--- Comment #5 from Alan Hourihane alanh at fairlite dot co.uk ---
any news ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
Harald Anlauf anlauf at gmx dot de changed:
What|Removed |Added
CC||anlauf at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Bug ID: 57638
Summary: warning container: 'integer_cst’ not supported by
dump_type#type error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
20130617 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #14 from Ryo Furue furue at hawaii dot edu ---
(In reply to Steve Kargl from comment #11)
Overall, I think this kind of thing is better be a warning and that at
least
the compiler should allow the user to run such a code as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #15 from Ryo Furue furue at hawaii dot edu ---
(In reply to Harald Anlauf from comment #13)
Hi Harald,
Thanks for your message.
I would also prefer if gfortran behaved as you suggested.
Other compilers appear to generate warnings
is used for some stuff, I used just bfd in my
compilation).
gcc --version:
gcc (GCC) 4.9.0 20130617 (experimental)
I finally reached WPA stage of LTO, memory usage was about 8GB for ld and 11 GB
for lto1.
lto1 was running for about 20 minutes and following error occured:
lto1: error: ELF section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #16 from Ryo Furue furue at hawaii dot edu ---
(In reply to Steve Kargl from comment #12)
On Sun, Jun 16, 2013 at 11:33:49PM +, furue at hawaii dot edu wrote:
Is this an inconsistency in the implementation of -no-range-check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #17 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Mon, Jun 17, 2013 at 10:07:32PM +, furue at hawaii dot edu wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #16 from Ryo Furue furue at
at gmail dot com
--- Comment #7 from Martin Liška marxin.liska at gmail dot com ---
gcc --version:
gcc (GCC) 4.9.0 20130617 (experimental)
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #8 from Martin Liška marxin.liska at gmail dot com ---
Sorry, comment was not added to related linker kernel bug 57483.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
--- Comment #1 from Martin Liška marxin.liska at gmail dot com ---
gcc --version:
gcc (GCC) 4.9.0 20130617 (experimental)
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto_symtab_prevailing_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #9 from Martin Liška marxin.liska at gmail dot com ---
Simple error case:
/tmp/x.c
char dnet_ntoa();
int main() {
dnet_ntoa()
; return 0; }
gcc -flto /tmp/x.c
Result:
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
--- Comment #3 from Bas Vodde b...@odd-e.com ---
Thanks for the comments. I understand the problems in implementing a compiler,
when this is also unclear in the language itself.
Whatever is decided related to this, it would probably be a good
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
--- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
We need to audit all places where '\n' is used and make sure we are taking care
of the '\r' properly in read.c , etc.
Then review what were are doing when we get a premature end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #18 from Ryo Furue furue at hawaii dot edu ---
(In reply to Steve Kargl from comment #17)
real, parameter:: a = -1.0
if (a 0) write(*,*) sqrt(a)
With such a switch turned on, the compiler can replace sqrt(-1.0) with NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #19 from Ryo Furue furue at hawaii dot edu ---
(In reply to Ryo Furue from comment #18)
Sorry again. I made English error.
Yeah, I get it. You don't like the choice that gfortran
made 10+ years ago.
Not quite.
I meant, You
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57640
Bug ID: 57640
Summary: Explicit call of system literal operator complains
about leading underscore.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57640
--- Comment #1 from Ed Smith-Rowland 3dw4rd at verizon dot net ---
Created attachment 30317
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30317action=edit
Add declarator_p to checks to trigger warning.
Testing this fully but I think this
Hi,
I am working right now on PR/56892, which is about missing
inline-optimization for dllexported classes. That's caused by the
default for TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P hook, which
disallows inlining for any machine-attribute. By taking a closer look
to i386's attributes, I don't see
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 r105+ r165*4 +
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
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
can
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_name ()
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
It might
-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 occurs
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 address
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; Ramana
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,
This patch
-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. It's
On Fri, Jun 14, 2013 at 6:31 PM, Sandra Loosemore
san...@codesourcery.com 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
On Fri, Jun 14, 2013 at 11:17 PM, David Malcolm dmalc...@redhat.com 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,
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 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
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
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;
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
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 will be
On Mon, Jun 17, 2013 at 11:53 AM, Jan Hubicka hubi...@ucw.cz 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
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 sebastian.hu...@embedded-brains.de
PR target/55033
* gcc.target/powerpc/pr55033.c: Fix options.
---
On Sun, Jun 16, 2013 at 9:26 PM, Jakub Jelinek ja...@redhat.com 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
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
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
On Mon, 17 Jun 2013 13:12:09 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Sun, Jun 16, 2013 at 9:26 PM, Jakub Jelinek ja...@redhat.com
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
On Mon, Jun 17, 2013 at 11:53 AM, Jan Hubicka hubi...@ucw.cz 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
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, 17 Jun 2013 13:38:05 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
jul...@codesourcery.com wrote:
On Mon, 17 Jun 2013 13:12:09 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Sun, Jun 16, 2013 at 9:26 PM, Jakub
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 forbidden.
On 06/17/2013 02:27 PM, Julian Brown wrote:
On Mon, 17 Jun 2013 13:38:05 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
jul...@codesourcery.com wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour
On Mon, Jun 17, 2013 at 2:38 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 06/17/2013 02:27 PM, Julian Brown wrote:
On Mon, 17 Jun 2013 13:38:05 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
jul...@codesourcery.com wrote:
IIUC,
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
OK.
Jason
1 - 100 of 157 matches
Mail list logo
