On Tue, Mar 27, 2012 at 7:20 PM, Richard Henderson wrote:
> On 03/27/12 09:37, Uros Bizjak wrote:
>>> > Now, in this particular case, there might be another option to
>>> > avoid this hassle completely: I understand that this UNSPEC is
>>> > simply a magic marker to make the address use the fs: o
On Wed, Mar 28, 2012 at 1:07 AM, Vladimir Makarov wrote:
> The following patch implements general spilling one class pseudos
> into another class hard registers *instead of memory* in LRA.
Can't find the patch itself
- Joey
On Tue, Mar 27, 2012 at 10:36 PM, Jakub Jelinek wrote:
> As the following testcase shows, the sse2_loadlpd splitter when
> the destination (and at the same operand from which the second
> DFmode element is taken) is a MEM and the other DFmode operand
> is a register stores into wrong part of memo
On 03/28/2012 03:15 AM, Terry Guo wrote:
Hello,
Thanks Paolo Carlini for pointing out that I should put code changes in
Makefile.am. This updated patch addresses this issue. Is it OK to trunk?
Sure, thanks.
Paolo.
Hello,
Thanks Paolo Carlini for pointing out that I should put code changes in
Makefile.am. This updated patch addresses this issue. Is it OK to trunk?
BR,
Terry
2012-03-26 Terry Guo
* testsuite/Makefile.am (TEST_GCC_EXEC_PREFIX): New.
* testsuite/Makefile.in: Regenerated.
d
On Tue, Mar 27, 2012 at 11:51 PM, Steven Bosscher wrote:
> On Tue, Mar 27, 2012 at 11:07 PM, Eric Botcazou wrote:
>>> With this patch a variable named "_Jv_CLS" is written out. The
>>> assembly before and after the patch is the same, except for the
>>> variable name. I want to write out a nameles
Hi Richard,
Segment registers %fs and %gs are special in 64bit mode. For a memory
operand "%fs:address", its effective address is the base address of %fs +
address. The base address of %fs are hidden and "mov %fs, %ax" will only
access the visible part of %fs, which is the 16bit segment selector
On Tue, Mar 27, 2012 at 11:07 PM, Eric Botcazou wrote:
>> With this patch a variable named "_Jv_CLS" is written out. The
>> assembly before and after the patch is the same, except for the
>> variable name. I want to write out a nameless variable but I don't
>> know how.
>
> Try tree_output_constan
Hi All,
This patch fixes an issue reported by one of our customers where an instruction
exception gets raised when using '__sync_fetch_and_add' on a PowerPC 440
processor. The instruction causing the exception is 'lwsync'. Luckily Joseph
laid the groundwork when solving a similar issue for e500
> With this patch a variable named "_Jv_CLS" is written out. The
> assembly before and after the patch is the same, except for the
> variable name. I want to write out a nameless variable but I don't
> know how.
Try tree_output_constant_def.
--
Eric Botcazou
> Bootstrapped/regtested on x86_64-suse-linux, applied on mainline. Should
> it be applied to the release branches as well?
>
>
> 2012-03-26 Eric Botcazou
>
> PR rtl-optimization/52629
> * reload1.c (count_pseudo): Short-circuit common case.
> (count_spilled_pseudo): Return ea
> Changelog:
> * expmed.c (store_bit_field_1): Fix wordnum value for big endian targets
The author line was missing so I put:
2012-03-27 Aurelien Buhrig
PR middle-end/51893
* expmed.c (store_bit_field_1): Fix wordnum value for big-endian
targets.
> Will this fix be ba
On 03/27/12 13:23, Andrew Stubbs wrote:
> gcc/
> * config/arm/arm.md (arch): Add neon_onlya8 and neon_nota8.
> (arch_enabled): Handle new arch types.
> (one_cmpldi2): Add NEON support.
Looks good to me.
r~
Hi!
As the following testcase shows, the sse2_loadlpd splitter when
the destination (and at the same operand from which the second
DFmode element is taken) is a MEM and the other DFmode operand
is a register stores into wrong part of memory, it does what
the sse2_loadhpd splitter does, while it sh
Hello,
The Java front end emits assembly from class.c:emit_register_classes()
to fill the .jcr section. This is not something a front end ought to
be doing. Things to write out to the assembler output file should go
through the varpool/varasm mechanism. The attached patch makes
emit_register_class
* include/std/functional (mem_fn): Qualify to prevent ADL.
* testsuite/20_util/function_objects/mem_fn/adl.cc: New.
Tested x86_64-linux, committed to trunk. Not a regression but should
be safe for all branches.
commit be288d23ed09bfabb8d1bc736e236c5b9e80beb3
Author: Jonathan Wakely
On 08/03/12 18:03, Richard Henderson wrote:
On 03/08/12 08:19, Andrew Stubbs wrote:
+ (set_attr "arch" "nota8,*,*,onlya8")
+ (set_attr_alternative "insn_enabled"
+ [(if_then_else (match_test "TARGET_NEON")
+ (const_string "yes") (const_string "no"))
+(const
Applied.
Index: htdocs/gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.105
diff -u -r1.105 changes.html
--- htdocs/gcc-4.7/changes.html 26 Mar 2012 13:04:45 - 1.105
+++ h
Add more PPH timers and stats.
We are spending too much time inside the reading of template bodies.
This patch adds more timers that pinpoint the problem to be the
hashing of specialization tables. We spend roughly 50% of PPH reading
inside the hashing code.
2012-03-27 Diego Novillo
cp/Cha
On Tue, 27 Mar 2012, H.J. Lu wrote:
> Hi,
>
> This patch removes MaskExists property from config/*/*.opt files
> since MaskExists handling has been removed. Tested on Linux/x86-64.
> There is no difference between options.h before and after the patch.
> OK for trunk?
OK.
--
Joseph S. Myers
jo
On Tue, Mar 27, 2012 at 8:59 PM, Mike Stump wrote:
>> and errors from the middle end are mostly for exotic
>> code (involving asm()s and the like). Bailing out after parse errors
>> is therefore IMHO the right thing to do for the common case.
>
> Some are for very exotic things, yes, but not all o
On Mar 26, 2012, at 1:56 PM, Steven Bosscher wrote:
> This patch is one way to address PR44982.
That's a great idea, I like it. There is only one problem that I know of that
prevents it from going in now. We emit errors/warnings from below finalize and
there is a feature in which we emit all t
On Tue, Mar 27, 2012 at 8:34 PM, H.J. Lu wrote:
> %fs and %gs are special in 64bit mode. For a memory operand
> "%fs:address", its effective address is base address of %fs + address.
> The base address of %fs and %fs are hidden. "mov %fs, %eax"
> will only access the visible part of %fs, which i
On Tue, Mar 27, 2012 at 10:53 AM, Uros Bizjak wrote:
> On Tue, Mar 27, 2012 at 7:28 PM, H.J. Lu wrote:
>
>> GCC needs to move the value in the %fs segment
>> register into %r32 or %r64. This instruction
>>
>> "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
>>
>> does exactly what GCC wants.
>
> Sorr
On Tue, Mar 27, 2012 at 7:28 PM, H.J. Lu wrote:
> GCC needs to move the value in the %fs segment
> register into %r32 or %r64. This instruction
>
> "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
>
> does exactly what GCC wants.
Sorry, I really don't understand what you are trying to say.
You are
2012/3/27 Georg-Johann Lay :
> This patch fixes a problem with the -mtiny-stack option:
>
> Architectures avr2 and avr25 mix targets with 8-bit SP and 16-bit SP so that
> -mtiny-stack is no good for multilib selection:
>
> If a frame pointer has to be set up from an 8-bit SP it is a difference if
>
On Sat, Mar 24, 2012 at 03:42:29PM -0700, H.J. Lu wrote:
> Hi,
>
> In i386 option mask, there is OPTION_MASK_ISA_64BIT for -m64 or -mx32
> code generations and OPTION_MASK_ISA_X32 for -mx32 code generation. We
> support
>
> -m64: OPTION_MASK_ISA_64BIT && !OPTION_MASK_ISA_X32
> -mx32: OPTION_MASK_
Hi,
This patch removes MaskExists property from config/*/*.opt files
since MaskExists handling has been removed. Tested on Linux/x86-64.
There is no difference between options.h before and after the patch.
OK for trunk?
Thanks.
H.J.
---
2012-03-27 H.J. Lu
* config/arm/arm.opt (mapc
On Tue, Mar 27, 2012 at 9:57 AM, Uros Bizjak wrote:
> On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu wrote:
>
Well, generally speaking, reload makes a lot of assumptions on how
addresses can look like; it needs to, since if a target rejects an
address as invalid as-is, reload must fix it
> The optimization might be useful for some other processors which
> have direct move insns for the two considered classes and when IRA for
> some reasons did not use the class union. At least I see
> that we could try this for ARM (spilling general regs into VF regs)
> and for extended powerpc a
On 03/27/12 09:37, Uros Bizjak wrote:
>> > Now, in this particular case, there might be another option to
>> > avoid this hassle completely: I understand that this UNSPEC is
>> > simply a magic marker to make the address use the fs: or gs:
>> > segment override, right? Now that GCC supports addr
The following patch implements general spilling one class pseudos
into another class hard registers *instead of memory* in LRA.
Currently, the patch implements spilling of general reg pseudos into
SSE regs for Intel Core architecture as it is recommended by Intel
optimization guide. Such opt
Adds a new flag -fpph-statistics. When used, it shows various collected
stats at the end of PPH processing.
2012-03-27 Diego Novillo
c-family/ChangeLog.pph
* c.opt (fpph-stats): Add flag.
cp/ChangeLog.pph
* pph-core.c (pph_stats): Declare.
(pph_init): Initialize.
On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu wrote:
>>> Well, generally speaking, reload makes a lot of assumptions on how
>>> addresses can look like; it needs to, since if a target rejects an
>>> address as invalid as-is, reload must fix it up -- and it can do
>>> so only by making assumptions ...
On Tue, Mar 27, 2012 at 9:37 AM, Uros Bizjak wrote:
> On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand wrote:
>
>>> Since fixing reload issues is some kind of black magic, I'd like to
>>> ask Ulrich and Richard for their opinion on this approach.
>>
>> Well, generally speaking, reload makes a lot
On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand wrote:
>> Since fixing reload issues is some kind of black magic, I'd like to
>> ask Ulrich and Richard for their opinion on this approach.
>
> Well, generally speaking, reload makes a lot of assumptions on how
> addresses can look like; it needs to
Uros Bizjak wrote:
> In a corner case of a reload, reload pass can generate partially
> reloaded address, where not all registers get allocated to a hard reg.
> When this address is checked with ix86_legitimate_address, it is
> rejected, since in strict mode, pseudos are not valid address
> regist
Sebastian Huber writes:
> What is the purpose of the ctrbegin.o and crtend.o?
The same as crtbeginS.o and crtendS.o, except for non-shared linking.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something
On Mon, Mar 26, 2012 at 9:03 PM, H.J. Lu wrote:
>>> Attached patch fixes this situation by (partially) reloading only
>>> remaining pseudo(s), leaving UNSPEC in the address RTX.
>>>
>>> 2012-03-26 Uros Bizjak
>>>
>>> PR target/52698
>>> * config/i386/i386-protos.h (ix86_legitimiz
On 03/09/2012 10:01 AM, Sebastian Huber wrote:
Hi,
please have a look at the attached patch. Test suite results for GCC 4.7
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00986.html
I get the same test suite results with:
powerpc-*-eabi* | powerpc-*-rtems*)
tmake_file="${tmake_file} rs60
On Mon, 26 Mar 2012, H.J. Lu wrote:
> The same set of macros are provided. The only differences are the
> order of bits used and macro definitions. I am doing a full bootstrap and
> test on Linux/x86-64. OK for trunk if there are no regressions?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
Ping
13 марта 2012 г. 15:12 пользователь Ilya Enkovich
написал:
> Ping
>
> 27 февраля 2012 г. 6:39 пользователь Ilya Enkovich
> написал:
>>>
>>> Undef TARGET_OS_CPP_BUILTINS and define TARGET_OS_CPP_BUILTINS
>>> in linux.h with GNU_USER_TARGET_OS_CPP_BUILTINS and
>>> ANDROID_TARGET_OS_CPP_BUILTI
Ping
13 марта 2012 г. 15:13 пользователь Ilya Enkovich
написал:
> Ping
>
> 27 февраля 2012 г. 6:41 пользователь Ilya Enkovich
> написал:
>>> You should keep those *_SPEC and define them with new
>>> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
>>> by other non-linux targets. In linux.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-4.7.0.sv.po', has just
And the patch is now attached
Ramana
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 900d09a..6e82fb0 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -247,5 +247,5 @@ extern int vfp3_const_double_for_fract_bits (rtx);
extern void a
Hi,
One of the problems with ivopts is that the auto-increment modelling
just takes into account whether HAVE_PRE_INC and friends are defined
for the architecture. However on ARM the VFP addressing modes don't
really support PRE_INCREMENT and POST_DECREMENT forms and hence there
is a bias in ivopt
This fixes PR52720.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied on the
trunk and the branch.
Richard.
2012-03-27 Richard Guenther
PR middle-end/52720
* fold-const.c (try_move_mult_to_index): Handle &x.array more
explicitely.
* gcc.dg/torture
Thomas Schwinge writes:
> libgcc/
> * config/alpha/linux-unwind.h (alpha_fallback_frame_state): Use
> siginfo_t instead of struct siginfo.
> * config/bfin/linux-unwind.h (bfin_fallback_frame_state): Likewise.
> * config/i386/linux-unwind.h (x86_fallback_frame_state): Likew
This patch fixes a problem with the -mtiny-stack option:
Architectures avr2 and avr25 mix targets with 8-bit SP and 16-bit SP so that
-mtiny-stack is no good for multilib selection:
If a frame pointer has to be set up from an 8-bit SP it is a difference if
there is no SP_H or of the SP is just tr
Hi,
I noticed that the tests were failing in ARM mode. Fixed thusly as
these tests are only meant to be run for Thumb state.
Committed to trunk.
regards.
Ramana
2012-03-27 Ramana Radhakrishnan
* gcc.target/arm/thumb-ifcvt.c: Only run for -mthumb.
* gcc.target/arm/thumb-16bit
Chung-Lin Tang wrote:
> This patch fixes a case in sh.c:find_barrier(), triggered by a testcase
> in glibc. The scanning starts from a GOT move instruction, records
> itself in 'last_got', but does not find a second GOT move (to reset
> last_got to NULL).
>
> It finishes by trying to insert a new
Oleg Endo wrote:
> The attached patch generalizes the move insn displacement calculations a
> little bit. Before, the same address rebasing code was present in
> sh_legitimize_address as well as sh_legitimize_reload_address. I've
> pulled those out into a separate function as a preparation step
On Mar 22, 2012, at 6:34 PM, Richard Henderson wrote:
> On 03/22/12 07:55, Tristan Gingold wrote:
>> 2012-03-22 Tristan Gingold
>>
>> * config/ia64/unwind-ia64.h: Declare unw_word and unw_sword.
>> (unw_table_entry): Use unw_word instead of unsigned long.
>> (_Unwind_FindTableE
Hi,
On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher wrote:
Hello,
This patch is one way to address PR44982. I see no good reason to
cgraph_finalize_compilation_unit if there were parse errors. As Richi
already pointed out, GCC traditionally has proceeded after parse
errors to preserve warnin
On Mar 16, 2012, at 4:14 PM, Richard Henderson wrote:
> On 03/16/12 04:56, Tristan Gingold wrote:
>> 2012-03-16 Tristan Gingold
>>
>> * config/ia64/vms.h (CASE_VECTOR_MODE): Define.
>> * config/ia64/ia64.md: Remove mode in template.
>> Sign extend operand in expand_simple_binop
On Mar 27, 2012, at 10:38 AM, Janne Blomqvist wrote:
> On Tue, Mar 27, 2012 at 11:01, Tristan Gingold wrote:
>> Hi,
>>
>> this patch fixes this issue. Is it OK ?
>
> Ok.
No check-gfortran regressions on x86_64-darwin, committed.
>> Maybe we should include the AC_DEFINE action within GCC_CHE
On Tue, 27 Mar 2012, Martin Jambor wrote:
> Hi,
>
> this fixes a thinko that leads to wrong-code generation that is in the
> "new" SRA since the beginning. When there are two unscalarizable
> regions in an access tree, one within another, the aggregate
> assignment modification code may use them
This fixes a couple of bugs I noticed in std::result_of, the first new
test covers those bugs, the second new test is just taken from the
standard to test result_of a little more thoroughly.
* include/std/type_traits (result_of): Fix handling of cv-quals.
* testsuite/20_util/result
Hi,
this fixes a thinko that leads to wrong-code generation that is in the
"new" SRA since the beginning. When there are two unscalarizable
regions in an access tree, one within another, the aggregate
assignment modification code may use them as basis of new memory
accesses, which means it very l
On Tue, 27 Mar 2012, Eric Botcazou wrote:
> > I see. Though the code does not affect layout but only access "layout"
> > for bitfields. I'm fine with fixing the issues we run into elsewhere,
> > just the langhook is a possibility I had in mind from the start, in
> > case frontends differ in thei
On Tue, Mar 27, 2012 at 11:01, Tristan Gingold wrote:
> Hi,
>
> this patch fixes this issue. Is it OK ?
Ok.
> Maybe we should include the AC_DEFINE action within GCC_CHECK_MATH_FUNC.
> Will try to do that.
That looks like a cleaner solution, yes, and less chance for typos to sneak in.
> Sor
> I see. Though the code does not affect layout but only access "layout"
> for bitfields. I'm fine with fixing the issues we run into elsewhere,
> just the langhook is a possibility I had in mind from the start, in
> case frontends differ in their memory model for bitfields.
Understood. Accordi
Hi!
Ping.
On Wed, 21 Mar 2012 15:56:04 +0100, I wrote:
> On Thu, 15 Mar 2012 11:57:00 -0400, Carlos O'Donell
> wrote:
> > On Thu, Mar 15, 2012 at 11:05 AM, Thomas Schwinge
> > wrote:
> > > On 26 Feb 2012 18:17:52 -, drep...@sourceware.org wrote:
> > >> http://sources.redhat.com/git/gitweb.
On Mar 27, 2012, at 9:51 AM, Tristan Gingold wrote:
>
> On Mar 26, 2012, at 11:43 PM, Janne Blomqvist wrote:
> [...]
>
>> On x86_64-unknown-linux-gnu bootstrap I see the following:
>>
>>
>> make[1]: Entering directory
>> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libg
Now that we are back in stage1, I'd like to apply
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to
toc reference rtl in order to properly specify r2 dependencies. More
commentary in that url. I'm reposting the patch here since the old
one no longer applies cleanly, and I've ad
On Mar 26, 2012, at 11:43 PM, Janne Blomqvist wrote:
[...]
> On x86_64-unknown-linux-gnu bootstrap I see the following:
>
>
> make[1]: Entering directory
> `/home/janne/src/gfortran/trunk/objdir-git/x86_64-unknown-linux-gnu/libgfortran'
> make check-am
> make[2]: Entering directory
> `/home/ja
On Tue, 27 Mar 2012, Eric Botcazou wrote:
> > Btw, I put things in stor-layout.c exactly to allow a langhook
> > eventually controlling things for the bitfield representative.
> > Mind adding one that simply disables them completely for Ada?
> > Or maybe, for selected record types, so that we do
>
On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher wrote:
> Hello,
>
> This patch is one way to address PR44982. I see no good reason to
> cgraph_finalize_compilation_unit if there were parse errors. As Richi
> already pointed out, GCC traditionally has proceeded after parse
> errors to preserve wa
> Btw, I put things in stor-layout.c exactly to allow a langhook
> eventually controlling things for the bitfield representative.
> Mind adding one that simply disables them completely for Ada?
> Or maybe, for selected record types, so that we do
>
> if (lang_hooks.types.lower_bitfield_layout (rl
69 matches
Mail list logo
