Jan Hubicka hubi...@ucw.cz writes:
MIPS16 code can't do atomic operations directly, so it calls into out-of-line
versions that are compiled as -mno-mips16. These out-of-line versions use
the same open-coded implementation as you'd get in normal -mno-mips16 code.
Hmm, and I assume you don't
Jan Hubicka hubi...@ucw.cz writes:
MIPS16 code can't do atomic operations directly, so it calls into
out-of-line
versions that are compiled as -mno-mips16. These out-of-line versions use
the same open-coded implementation as you'd get in normal -mno-mips16 code.
Hmm, and I assume
Dear Group,
The below asm is generated for target cortex-m3 (gcc-4.6.3)
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push {r3, r4, r5, lr}
bl vAlgTNoOptimize
movs r0, #170
bl vFnCall
bl vAlgTOptimize
ldr r4, .L22
add
On Oct 9, 2013, at 2:14 AM, Umesh Kalappa umesh.kalap...@gmail.com wrote:
Dear Group,
The below asm is generated for target cortex-m3 (gcc-4.6.3)
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push {r3, r4, r5, lr}
bl
On Wed, Oct 09, 2013 at 10:59:35AM +0200, Jan Hubicka wrote:
I see, the previous implementation tricked the one-declaration rule by
introducing two names. What made the difference is that the second name
is expanded as builtin...
So you don't have __bulitin_sync_synchronize() at hand that
Dear Group ,
We are re-targeting the GCC to the CISC target ,which has the eight
8-bit registers and same register set can used as pair register for
16 bit computation i.e four 16-bits .
Any one in the group tell me ,How do i model this requirement using
the target macros like
Jakub Jelinek ja...@redhat.com writes:
On Wed, Oct 09, 2013 at 10:59:35AM +0200, Jan Hubicka wrote:
I see, the previous implementation tricked the one-declaration rule by
introducing two names. What made the difference is that the second name
is expanded as builtin...
So you don't have
On Wed, Oct 09, 2013 at 10:56:33AM +0100, Richard Sandiford wrote:
gcc/testsuite/
* gcc.target/i386/asm-rename-1.c: New file.
Index: gcc/testsuite/gcc.target/i386/asm-rename-1.c
===
--- /dev/null 2013-10-09
The first release candidate for GCC 4.8.2 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.2-RC-20131009
and shortly its mirrors. It has been generated from SVN revision 203308.
I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux. Please test
Status
==
The GCC 4.8.2-rc1 release candidate has been released.
The branch is frozen now, all changes require release manager approval
until the final release of GCC 4.8.2 which should happen roughly
one week after the release candidate.
Quality Data
Priority #
On Oct 9, 2013, at 5:24 AM, Umesh Kalappa umesh.kalap...@gmail.com wrote:
Dear Group ,
We are re-targeting the GCC to the CISC target ,which has the eight
8-bit registers and same register set can used as pair register for
16 bit computation i.e four 16-bits .
Any one in the group
Hi,
www.x86-64.org was down for several months and it is up
now, but not in its full capacity. I created a x86-64 psABI
group:
https://groups.google.com/forum/?hl=en#!forum/x86-64-abi
so that there is a mailing list we can discuss x86-64 psABI
related issues.
Thanks.
--
H.J.
Dear Jeff and the rest of Steering committee members,
Thank you very much for approving the license terms of the Cilk Library. I
couldn't attach the zipped copy of the patch due to its size, so here is a link
to the Cilk library patch that can be applied to the trunk:
Some observations:
* Various source files include x86-specific asm. At some point it will
need restructuring so that the architecture-specific parts go in
architecture-specific files and it's clear what to do to add support for
another architecture.
* Given that architecture dependency, the
As some may have seen I posted a patch to gcc-patches that adds a way to
embed GCC as a shared library, for Just-In-Time compilation, for use
e.g. by bytecode interpreters:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00228.html
I've gone ahead and created a git-only on the mirror as branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57310
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||jason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58666
Bug ID: 58666
Summary: make install after make bootstrap-lean fails starting
with r202895
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Resolution|--- |FIXED
--- Comment #4 from David Binderman dcb314 at hotmail dot com ---
Seems to be fixed by 20131009, revision 203302
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58666
--- Comment #1 from Mario Held mario.held at de dot ibm.com ---
Same behavior seen on my systems. A 'make' of GCC (s390x) sucessful, ' make
bootstrap-lean' fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58539
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Wed Oct 9 09:26:48 2013
New Revision: 203307
URL: http://gcc.gnu.org/viewcvs?rev=203307root=gccview=rev
Log:
Backport from mainline
2013-09-26 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #45 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Anything left to fix in this PR?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58663
Jan Kratochvil jan.kratochvil at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58667
Bug ID: 58667
Summary: Add -Wfloat-conversion
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Author: ebotcazou
Date: Wed Oct 9 12:59:02 2013
New Revision: 203315
URL: http://gcc.gnu.org/viewcvs?rev=203315root=gccview=rev
Log:
PR middle-end/58570
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
--- Comment #10 from Marc Glisse glisse at gcc dot gnu.org ---
Author: glisse
Date: Wed Oct 9 13:03:13 2013
New Revision: 203316
URL: http://gcc.gnu.org/viewcvs?rev=203316root=gccview=rev
Log:
2013-10-09 Marc Glisse marc.gli...@inria.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Wed Oct 9 14:51:28 2013
New Revision: 203323
URL: http://gcc.gnu.org/viewcvs?rev=203323root=gccview=rev
Log:
PR c++/58635
cp/
* semantics.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58654
John David Anglin danglin at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668
Bug ID: 58668
Summary: [arm with hardfp ABI]: internal compiler error: in
cond_exec_process_insns, at ifcvt.c:339
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669
Bug ID: 58669
Summary: does not detect all cpu cores/threads
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669
Andrew John Hughes gnu_andrew at member dot fsf.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669
--- Comment #2 from Andrew John Hughes gnu_andrew at member dot fsf.org ---
This is easily fixed with sysconf(_SC_NPROCESSORS_ONLN);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669
--- Comment #3 from Folkert van Heusden folkert at vanheusden dot com ---
Did some googling and with appropriate #ifdefs it should be at least on linux
possible to retrieve this value:
sysconf(_SC_NPROCESSORS_ONLN);
If that function can't figure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Bug ID: 58670
Summary: asm goto miscompilation
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669
--- Comment #4 from Andrew John Hughes gnu_andrew at member dot fsf.org ---
Yes, I just said that above. I'll propose a patch when I get chance.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58669
--- Comment #5 from Andrew John Hughes gnu_andrew at member dot fsf.org ---
Thanks for reporting this. I'll let you know when a fix is committed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #19 from Rick Regan exploringbinary at gmail dot com ---
I've looked into this and found that real.c/real.h use a precision of
SIGNIFICAND_BITS, which is dependent on an architecture-dependent value called
HOST_BITS_PER_LONG. In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
I see multiple issues:
1) commit_one_edge_insertion doesn't seem to cope with asm goto,
I think asm goto with only labels pointing to the fallthru bb's labels
can happen both for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48923
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58207
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58671
Bug ID: 58671
Summary: ICE with thread_local and self-referential variable
initialization
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58672
Bug ID: 58672
Summary: ICE with thread_local and variable of broken class
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58673
Bug ID: 58673
Summary: ICE in final_scan_insn for movti_ppc64 with
base+offset address
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58673
--- Comment #1 from Pat Haugen pthaugen at gcc dot gnu.org ---
Created attachment 30972
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30972action=edit
testcase
Another similar example, but this one is on a store to memory instead of a
load.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58674
Bug ID: 58674
Summary: [4.8/4.9 Regression] [c++11] ICE with template using
declaration
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675
Bug ID: 58675
Summary: ICE in rs6000_secondary_reload_inner:15460, type =
store
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58333
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50961
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58676
Bug ID: 58676
Summary: Intrinsic functions not considered pure actual
arguments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
This bug likely needs an update: the testcase is still rejected, but likewise
happens with ICC and clang.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #20 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
I suppose that for any 54-bit[*] odd integer multiplied by a power of two with
a large exponent (in absolute value), some decimal numbers close to this value
will be affected.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
asmwarrior asmwarrior at gmail dot com changed:
What|Removed |Added
CC||asmwarrior at
++,fortran,lto --disable-werror
--enable-checking=release --with-gmp=/usr/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131009 (experimental) [trunk revision 203302
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58671
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
Seems like a odd thing for a param. If the compile time increase is very
small ( 1%?) I would just make the new threshold default.
I don't understand the 'odd' here... params are exactly for this purpose, i.e.
to avoid hardcoding magic numbers in the compiler, so please elaborate.
--
Eric
Hi,
with the attached patch we use call-clobbered floating point registers
as save slots for general purpose registers in leaf functions.
Bootstrapped and regtested with various options and -march levels.
Committed to mainline.
Bye,
-Andreas-
2013-10-09 Andreas Krebbel
Just a cleanup of the s390_frame_info function.
Committed to mainline after regression test was fine.
Bye,
-Andreas-
2013-10-09 Andreas Krebbel andreas.kreb...@de.ibm.com
* config/s390/s390.c (s390_frame_info): Restructure function.
---
gcc/config/s390/s390.c | 112
Hi,
for stdarg the floating point argument registers in the register save
area must reside at an ABI-defined offset relative to the start of the save
area. So far were not able to optimize away save instructions with
the packed stack layout since this changed the offsets.
With the attached
Hi!
On Tue, 8 Oct 2013 22:04:23 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Oct 08, 2013 at 09:17:35AM +0200, Thomas Schwinge wrote:
Here are a few cleanup patches, mostly in the realm of OpenMP, so Jakub
gets a CC. OK to commit?
They look ok to me, but I'd prefer if they could
On Wed, Oct 09, 2013 at 10:56:25AM +0200, Thomas Schwinge wrote:
On Tue, 8 Oct 2013 22:04:23 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Oct 08, 2013 at 09:17:35AM +0200, Thomas Schwinge wrote:
Here are a few cleanup patches, mostly in the realm of OpenMP, so Jakub
gets a CC. OK
Thomas Schwinge wrote:
Meanwhile, here's another series that I assumed had gotten lost, but now
recovered thanks to Âgit fsckÂ. Also OK to commit?
_OPENMP pre-processor checks, openmp_version Fortran instrinsic checks.
Two remarks:
* When Jakub's patch gets it, one needs to update the C/C++
Hi!
I've backported the following patch to 4.8 branch,
bootstrapped/regtested on x86_64-linux and i686-linux,
committed.
2013-10-09 Jakub Jelinek ja...@redhat.com
Backport from mainline
2013-09-26 Richard Biener rguent...@suse.de
PR tree-optimization/58539
*
Hi!
This is the minimal fix for the issue mentioned in
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00333.html
that is being fixed as part of gomp-4_0-branch merge to trunk,
but for 4.8 I've applied this fix instead.
The testcase also includes the follow-up fix from
Hi!
On Wed, 9 Oct 2013 11:04:29 +0200, Jakub Jelinek ja...@redhat.com wrote:
The testing _OPENMP value against 201107 won't work after merge, it will be
201307 instead. The Fortran openmp_version will be still 201107 for now,
as Fortran OpenMP 4.0 support isn't there yet.
And:
On Wed, 9 Oct
Hi Honza,
Yep, I think we need to merge only those autmatas tha are same for both:
(define_automaton bdver3,bdver3_ieu,bdver3_load,bdver3_fp,bdver3_agu)
probably can become
(define_automaton bdver3,bdver3_fp)
with the corresponding reservations using bdver3_ieu,bdver3_load,bdver3_agu
On Tue, Oct 8, 2013 at 4:15 PM, Andrew MacLeod amacl...@redhat.com wrote:
On 10/08/2013 09:18 AM, Richard Biener wrote:
On Tue, Oct 8, 2013 at 2:58 PM, Andrew MacLeod amacl...@redhat.com
wrote:
I just took a quick stab at it... I think its pretty involved and
someone
with better loop
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 2nd subpatch. It fixes missing `v' constraints.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 3rd subpatch. It extends VF1 and VI iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 4th subpatch. It extends V iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000 2006 build
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 6th subpatch. It extends VI2 and VI124 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 5th subpatch. It introduces `multdiv' code iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 7th subpatch. It extends VI4 and VI8 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 8th subpatch. It extends VI48 and VI48_AVX2 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 10th subpatch. It introduces VI248_AVX2_8_AVX512F and VI124_256_48_512
iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 9th subpatch. It extends VI124_AVX2_48 and VI8F iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3.
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 11th subpatch. It introduces AVX-512 FMA instructions.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 13th subpatch. It introduces VI4_AVX iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 12th subpatch. It introduces VF_512 and VI_512 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3.
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 15th subpatch. It introduces VI48F_512 iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 14th subpatch. It introduces VI48F_256_512 iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 17th subpatch. It introduces V8FI and V16FI iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 18th subpatch. It introduces various new insns.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 20th subpatch. It introduces last insns of AVX-512F.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 19th subpatch. It extends extract and convert insn patterns.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 1st subpatch. It extends VI4F_128 and introduces VI48_512 iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no
On 01/10/13 11:15, Marcus Shawcroft wrote:
On 30 September 2013 14:23, Renlin Li renlin...@arm.com wrote:
OK for trunk?
Kind regards,
Renlin Li
gcc/ChangeLog:
2013-09-30 Renlin Li renlin...@arm.com
* config/arm/arm.c (arm_output_mi_thunk): Use plus_constant.
OK
/Marcus
Hi Renlin,
On Tue, Oct 8, 2013 at 7:52 PM, Eric Botcazou ebotca...@adacore.com wrote:
Probably because the actual accesses may overlap if we choose to
perform a bigger access.
Nope, simply because they share a byte.
The same can happen if we for struct { char c1; char c2; } perform
an HImode access in
On 8 October 2013 17:10, Alex Velenko alex.vele...@arm.com wrote:
gcc/testsuite/
2013-10-08 Alex Velenko alex.vele...@arm.com
* gcc.target/aarch64/vneg_f.c: New testcase.
* gcc.target/aarch64/vneg_s.c: New testcase.
gcc/
2013-10-08 Alex Velenko alex.vele...@arm.com
On Wed, Oct 9, 2013 at 1:31 AM, Andrew MacLeod amacl...@redhat.com wrote:
On 10/08/2013 07:44 AM, Andrew MacLeod wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
graphite.h should be unnecessary with moving the pass struct like you
did for other loop opts. Likewise tree-parloops.h
On Tue, Oct 8, 2013 at 11:04 PM, Easwaran Raman era...@google.com wrote:
In cfgexpand.c, variables in non-overlapping lexical scopes are
assigned same stack locations at -O1 and above. At -O0, this is
attempted only if the size of the stack objects is above a threshold
(32). The rationale is
Hi,
this is a completely different approach at fixing the bug, which overall
I like better.
In this case most of the patch touches cp_parser_decltype_expr: instead
of using cp_parser_postfix_expression only for member access
expressions, we accept all its valid return values (still
In my opinion the MEM_EXPR is wrong, as it is supposed to be
the tree equivalent of the memory access. At gimple level we
handle accesses at bit-granularity so bit-accesses are fine.
Not so at RTL level it seems.
[this also shows we probably should lower bit-granular accesses
at the
Hi!
On Tue, 8 Oct 2013 17:24:14 +0200, Jakub Jelinek ja...@redhat.com wrote:
These tests were expecting 5 loopfn matches, 3 on the fn definition, one
as GOMP_parallel_start argument and one called in between
GOMP_parallel_start and GOMP_parallel_end. But the new API is
to call GOMP_parallel
On 8 October 2013 17:25, Alex Velenko alex.vele...@arm.com wrote:
gcc/testsuite/
2013-09-10 Alex Velenko alex.vele...@arm.com
* gcc.target/aarch64/vdiv_f.c: New testcase.
gcc/
2013-09-10 Alex Velenko alex.vele...@arm.com
* config/aarch64/arm_neon.h
On 8 October 2013 17:35, Alex Velenko alex.vele...@arm.com wrote:
2013-10-08 Alex Velenko alex.vele...@arm.com
* gcc.target/aarch64/vadd_f64.c: New testcase.
* gcc.target/aarch64/vsub_f64.c: New testcase.
gcc/
2013-10-08 Alex Velenko alex.vele...@arm.com
*
On Wed, Oct 9, 2013 at 1:36 PM, Eric Botcazou ebotca...@adacore.com wrote:
In my opinion the MEM_EXPR is wrong, as it is supposed to be
the tree equivalent of the memory access. At gimple level we
handle accesses at bit-granularity so bit-accesses are fine.
Not so at RTL level it seems.
1 - 100 of 173 matches
Mail list logo
