"Steve Ellcey " writes:
> 2013-05-28 Steve Ellcey
>
> * config/mips/mti-linux.h (SYSROOT_SUFFIX_SPEC): Add micromips
> and mips16 directories.
> * config/mips/t-mti-linux (MULTILIB_OPTIONS): Add micromips and
> mips16.
> (MULTILIB_DIRNAMES): Ditto.
> (MULTILI
On Tue, 28 May 2013, David Edelsohn wrote:
> Richi,
>
> I would greatly appreciate if you would bootstrap and test this on
> ppc64-linux as well.
It's a no-op patch unless you specify -fvect-cost-model=cheap.
I'll do a bootstrap and regtest on ppc64-linux for your convenience
anyway.
I'll recor
On Tue, May 28, 2013 at 8:04 PM, David Malcolm wrote:
> On Mon, 2013-05-27 at 15:38 +0200, Richard Biener wrote:
>> On Sat, May 25, 2013 at 3:02 PM, David Malcolm wrote:
>> > Eliminate all direct references to "cfun" from macros in
>> > basic-block.h and introduce access methods t
On Wed, May 29, 2013 at 3:35 AM, Easwaran Raman wrote:
> I made a thinko when I asserted gcc_unreachable outside the main loop
> of appears_later_in_bb in my previous fix to PR 57337. It is quite
> possible for STMT1 to be followed by a one or more statements with the
> same UID till the end of th
Dear all,
this patch enables finalization (and polymorphic deallocation) for
allocatables for: end of scope, DEALLOCATE and intent(out).
As a side effect, an allocatable is no longer deallocated at the end of
the main program. (Variables declared in the main program have
automatically SAVE a
Hi,
on most platforms the Ada compiler doesn't enable trap-on-FP-exceptions, so
it's appropriate to set -fno-trapping-math there, which has been done in
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01461.html
However doing so can have an adverse effect if the architecture doesn't have a
suffi
Hi,
on most platforms the Ada compiler doesn't enable trap-on-FP-exceptions, so
it's appropriate to set -fno-trapping-math there, which has been done in
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01461.html
However doing so can have an adverse effect if the architecture doesn't have a
suffi
On Wed, May 29, 2013 at 10:33 AM, Eric Botcazou wrote:
> Hi,
>
> on most platforms the Ada compiler doesn't enable trap-on-FP-exceptions, so
> it's appropriate to set -fno-trapping-math there, which has been done in
> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01461.html
>
> However doing so c
My commit crossed the Cilk+ changes and only its testcases expose
that we do not set stmt UIDs on blocks we currently vectorize and
thus other vinfo_for_stmt calls have to be properly guarded.
Tested on x86_64-unknown-linux-gnu, applied as obvious.
Richard.
2013-05-29 Richard Biener
> Did you check that this doesn't cause traps on SPEC CPU 2000 / 2006
> when compiled with -ffast-math (something we generally want to support,
> even if it is on the border of validity)?
Do you mean SPECfp because some benchmarks might enable trap-on-FP-exceptions
and you nevertheless compile th
Mike Stump writes:
> On May 28, 2013, at 3:56 PM, Dehao Chen wrote:
>> The attached patch restricts the test only run on linux-gnu targets. Is it
>> ok?
>
> Ok. You can put HAVE_AS_DWARF2_DEBUG_LINE in a comment above it to help
> explain why the target restriction applies. The idea is, if en
On Wed, May 29, 2013 at 11:19 AM, Eric Botcazou wrote:
>> Did you check that this doesn't cause traps on SPEC CPU 2000 / 2006
>> when compiled with -ffast-math (something we generally want to support,
>> even if it is on the border of validity)?
>
> Do you mean SPECfp because some benchmarks might
On Tue, May 28, 2013 at 11:12 AM, Zamyatin, Igor
wrote:
> Several weeks ago Intel announced new microarchitecture named Silvermont (see
> for example
> http://newsroom.intel.com/community/intel_newsroom/blog/2013/05/06/intel-launches-low-power-high-performance-silvermont-microarchitecture
> ).
> Yes, SPECfp. And no, I don't think they enable trap-on-FP-exceptions but
> they may cause exceptional behavior even if -fno-trapping-math is specified
> (not sure if IA64 masks exceptions on the comparisons?)
The manual says that QNaNs signal Invalid for the signaling FP comparison
operators a
Hi,
On Tue, May 28, 2013 at 03:40:25PM +0200, Richard Biener wrote:
> On Tue, 28 May 2013, Martin Jambor wrote:
> > I've committed it s revision 199379, thanks. As far as the
> > non-top-levelness is concerned, the following (on top of the previous
> > patch) also survives bootstrap and testsuite
Hi!
On Tue, 28 May 2013 09:28:28 +0200, I wrote:
> On Wed, 08 May 2013 11:27:09 +0200, Rainer Orth
> wrote:
> > As described in [PR ada/57188], amd64-pc-solaris2.1[01] Ada bootstrap was
> > failing
> > for some time. It has turned out that this patch is the culprit:
> >
> > 2013-04-23 Eric B
Thanks Uros! Committed at r199405.
-Ganesh
-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com]
Sent: Thursday, May 23, 2013 4:47 PM
To: Gopalasubramanian, Ganesh
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH,i386] FP Reassociation for AMD bdver1 and bdver2
On Thu, May 23,
Hi
We want this to be backported to GCC48 branch.
Please approve.
Regards
Ganesh
-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com]
Sent: Tuesday, May 07, 2013 6:22 PM
To: Gopalasubramanian, Ganesh
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH,i386] Default alignment for
Hi,
Below patch added target specific macros for RX100, RX200, and RX600
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00050.html
Please review the patch and let me know if there should be any
modifications in it?
Regards,
Sandeep Kumar Singh,
KPIT Cummins InfoSystems Ltd.
Pune, India
"Iyer, Balaji V" writes:
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Richard Henderson
>> Sent: Tuesday, May 28, 2013 2:52 PM
>> To: Iyer, Balaji V
>> Cc: Jakub Jelinek; Aldy Hernandez; Jeff Law; 'Joseph S. Myers'; '
Hi Tobias,
> Small re-diff - but essentially unchanged.
>
> (I made a thinko when adding a _final call to
> gfc_trans_class_array_init_assign: Not in all contexts the _final should be
> called, only for INTENT(OUT). Thus, I remove the _final call and deferred it
> to the actual finalization call.
Hi,
I noticed that the scheduler created long dependence list about ~9000
elements long and slowed compilation time for about an hour. Attached
patch flushes the dependence list is case of it is longer than
MAX_PENDING_LIST_LENGTH. Tested with gcc testsite on x86_64-linux-gnu
with c and c++ enabled
Hello,
On Wed, May 29, 2013 at 2:01 PM, Dinar Temirbulatov wrote:
> Hi,
> I noticed that the scheduler created long dependence list about ~9000
> elements long and slowed compilation time for about an hour. Attached
> patch flushes the dependence list is case of it is longer than
> MAX_PENDING_LIS
This patch re-organizes the implementation of aarch64_classify_symbol in
preparation for add tiny absolute memory model support.
Regressed aarch64-none-elf, applied.
/Marcus
2013-05-29 Chris Schlumberger-Socha
Marcus Shawcroft
* config/aarch64/aarch64.c (aarch64_classi
Hi Sandeep,
Below patch added target specific macros for RX100, RX200, and RX600
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00050.html
Please review the patch and let me know if there should be any
modifications in it?
Sorry - I missed your original posting.
The patch is fine, please appl
Hi, This patch adds support for the tiny absolute memory model.
Regressed for aarch64-none-elf with each of
-mcmodel=tiny
-mcmodel=small
-mcmodel=small -fPIC
Applied.
/Marcus
2012-05-29 Chris Schlumberger-Socha
Marcus Shawcroft
* config/aarch64/aarch64-protos.h (
On 29/05/13 14:08, Marcus Shawcroft wrote:
Hi, This patch adds support for the tiny absolute memory model.
Regressed for aarch64-none-elf with each of
-mcmodel=tiny
-mcmodel=small
-mcmodel=small -fPIC
Applied.
This time with patch attached, oops, sorry.
/Marcus
/Marcus
2012-05-2
Janus Weil wrote:
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
I think this patch is ok. Just one nit:
@@ -5571,7 +5569,7 @@ gfc_dump_module (const char *name, int dump_flag)
FIXME: For backwards compatibility with the old uncompressed
module format, write an extra e
Hi Nick,
>> The patch is fine, please apply.
Thanks for the review.
I do not have write approvals to gcc-svn.
Could you please commit this for me?
Regards,
Sandeep Kumar Singh,
KPIT Cummins InfoSystems Ltd.
Pune, India
> -Original Message-
> From: nick clifton [mailto:ni...@redhat.com]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 29/05/2013 12:50, Thomas Schwinge ha scritto:
>>> How about we use something like the following [...] patch? In
>>> essence, replace the manual parsing in
>>> gcc/ada/gcc-interface/Makefile.in by using the values the
>>> configure script already c
On 05/29/2013 06:52 AM, Steven Bosscher wrote:
Hello,
On Wed, May 29, 2013 at 2:01 PM, Dinar Temirbulatov wrote:
Hi,
I noticed that the scheduler created long dependence list about ~9000
elements long and slowed compilation time for about an hour. Attached
patch flushes the dependence list is c
Hi,
Prior to adding conditional candidates to SLSR, the size of the
increment vector was bounded by the number of related candidates, and
the vector was malloc'd to be that size. With conditional candidates,
there can be an additional increment for each related PHI operand,
causing potential over
On Thu, May 23, 2013 at 6:18 AM, Teresa Johnson wrote:
> On Wed, May 22, 2013 at 2:05 PM, Teresa Johnson wrote:
>> Revised patch included below. The spacing of my pasted in patch text
>> looks funky again, let me know if you want the patch as an attachment
>> instead.
>>
>> I addressed all of Ste
Rainer Orth writes:
> "Iyer, Balaji V" writes:
[...]
>> This patch is committed to trunk at revision 199389.
>
> ... and immediately broke Solaris bootstrap, cf. PR bootstrap/57450.
Fixed implementing Richard's suggestion from the PR. Bootstrapped
without regressions on i386-pc-solaris2.10 and
On Wed, May 29, 2013 at 4:50 PM, Bill Schmidt
wrote:
> Hi,
>
> Prior to adding conditional candidates to SLSR, the size of the
> increment vector was bounded by the number of related candidates, and
> the vector was malloc'd to be that size. With conditional candidates,
> there can be an addition
Balaji,
Thanks for this new feature and I am relieved that so much of it works
successfully on PowerLinux and AIX.
I know that you have received a deluge of reports of issues with the
cilkplus support that you slowly are working through. I am seeing the
following new testsuite failures on AIX:
Patch updated and committed as r199412.
Thanks,
Dehao
* config/rs6000/predicates.md (rs6000_cbranch_operator): Accept some
unordered comparison operators when -fno-trapping-math is in effect
on the e500.
* config/rs6000/rs6000.c (rs6000_generate_compare): Remove dead code
and implement unordered comparison operators properly on the e500.
I'm okay wit
On Tue, May 28, 2013 at 5:35 PM, H.J. Lu wrote:
> On Tue, May 28, 2013 at 1:02 PM, Iyer, Balaji V
> wrote:
>>
>>
>>> -Original Message-
>>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>>> ow...@gcc.gnu.org] On Behalf Of Richard Henderson
>>> Sent: Tuesday, May 28, 2013 2:52
* sched-deps.c (sched_analyze_2): Flush dependence lists if
the sum of the read and write lists exceeds MAX_PENDING_LIST_LENGTH.
On Wed, May 29, 2013 at 6:49 PM, Jeff Law wrote:
> On 05/29/2013 06:52 AM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> On Wed, May 29, 2013 at 2:01 PM, Dinar Temi
The patch breaks compiling Open MPI with default compilation flags (for
that file: -O3 -fno-strict-aliasing):
../../../../../ompi/mca/btl/tcp/btl_tcp_frag.c:100:6: internal compiler
error: in operator[], at vec.h:815
bool mca_btl_tcp_frag_send(mca_btl_tcp_frag_t* frag, int sd)
See PR 57453
Here is the corrected version of change. Also, I think, I need
write-after-approval access to commit the change.
thanks, Dinar,
PR rtl-optimization/57268
* sched-deps.c (sched_analyze_2): Flush dependence lists if
the sum of the read and write lists exceeds
In gcc4-8, the max einline iterations are restricted to 1. For
AutoFDO, this is bad because early inline is not size restricted. This
patch allows einline to do multiple iterations in AutoFDO. It also
enables tracer optimization in AutoFDO.
Bootstrapped and passed regression test.
OK for googel-4
Hi Sandeep,
>>> The patch is fine, please apply.
Thanks for the review.
I do not have write approvals to gcc-svn.
Could you please commit this for me?
Done.
Cheers
Nick
The early inlining part is ok. The tracer optimization should be
revisited -- we should have more fine grain control on it (for
instance, based on FDO summary -- but that should be common to
FDO/LIPO).
David
On Wed, May 29, 2013 at 9:39 AM, Dehao Chen wrote:
> In gcc4-8, the max einline iteratio
Hi All,
This patch fixes a bug in one of the ARM peephole2 optimizations. The
peephole2 optimization in question was changed to use the CC-updating
form for all of the instructions produced by the peephole so that the
encoding will be smaller when compiling for thumb [1]. However, I don't
think
Hi,
[patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280,
libc/15407)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html
Message-ID: <20130514191244.ga12...@host2.jankratochvil.net>
Thanks,
Jan
On 30/05/2013, at 4:36 AM, Dinar Temirbulatov wrote:
> Here is the corrected version of change. Also, I think, I need
> write-after-approval access to commit the change.
>thanks, Dinar,
>
>PR rtl-optimization/57268
>* sched-deps.c (sched_analyze_2): Flush dependenc
Currently, ALLOCATE ignores the typespec for arrays. Such that:
ALLOCATE (t2 :: var(5))
will allocate as much memory as the base type requires instead of using
as much as "t2" does.
I explicitly exclude characters as it otherwise will fail for
allocate_with_typespec_1.f90, which uses:
Now as bonus with the proper patch.
Tobias
PS: I really wonder why Thunderbird's attach file dialog shows an
outdated directory content, unless one hits F5, if one opens the dialog
again :-(
Tobias Burnus wrote:
Currently, ALLOCATE ignores the typespec for arrays. Such that:
ALLOCATE (t2
> Honza,
>
> I would greatly appreciate if you would bootstrap GCC and run the
> testsuite with your symtab cleanup patches on ppc64-linux.
Testing on gcc110.fsffrance.org passed fine. I will re-test x86_64-linux
and go ahead with the patch and will mind to continue testing the patches
on both p
On 05/29/2013 10:36 AM, Dinar Temirbulatov wrote:
Here is the corrected version of change. Also, I think, I need
write-after-approval access to commit the change.
thanks, Dinar,
PR rtl-optimization/57268
* sched-deps.c (sched_analyze_2): Flush dependence lists
+ if (TARGET_DIRECT_MOVE)
+{
+ if (TARGET_POWERPC64)
+{
+ reload_gpr_vsx[TImode]= CODE_FOR_reload_gpr_from_vsxti;
+ reload_gpr_vsx[V2DFmode] = CODE_FOR_reload_gpr_from_vsxv2df;
+ reload_gpr_vsx[V2DImode] = CODE_FOR_reload_gpr_from_vsxv2
This patch re-enables -fdump-passes. It had stopped working because
dump_passes was changed to use the FOR_EACH_DEFINED_FUNCTION iterator,
however, functions are not marked as defined until after dump_passes
is called, in cgraph_analyze_functions. Fixed by iterating over all
functions.
Bootstrappe
On 05/28/13 16:20, Iyer, Balaji V wrote:
Regarding the tests, I will merge trunk->cilk-in-gomp so we can reuse the c-c++-
common infrastructure you wrote. There is no sense having multiple tests for
vectorlength, linear, etc.
Can you please add them under c-c++-common/cilk-plus/PS directory?
- if (mode == QImode || mode == HImode)
+ /* On power8, we want to use SImode for the operation. On previoius systems,
+ use the operation in a subword and shift/mask to get the proper byte or
+ halfword. */
+ if (TARGET_SYNC_HI_QI && (mode == QImode || mode == HImode))
+{
+ v
On 05/29/2013 02:11 PM, Teresa Johnson wrote:
This patch re-enables -fdump-passes. It had stopped working because
dump_passes was changed to use the FOR_EACH_DEFINED_FUNCTION iterator,
however, functions are not marked as defined until after dump_passes
is called, in cgraph_analyze_functions. Fix
On Wed, May 29, 2013 at 03:53:43PM -0400, David Edelsohn wrote:
> + if (TARGET_DIRECT_MOVE)
> +{
> + if (TARGET_POWERPC64)
> +{
> + reload_gpr_vsx[TImode]= CODE_FOR_reload_gpr_from_vsxti;
> + reload_gpr_vsx[V2DFmode] = CODE_FOR_reload_gpr_from_vs
On Wed, May 29, 2013 at 04:29:07PM -0400, David Edelsohn wrote:
> - if (mode == QImode || mode == HImode)
> + /* On power8, we want to use SImode for the operation. On previoius
> systems,
> + use the operation in a subword and shift/mask to get the proper byte or
> + halfword. */
> +
On Wed, May 29, 2013 at 1:32 PM, Jeff Law wrote:
> On 05/29/2013 02:11 PM, Teresa Johnson wrote:
>>
>> This patch re-enables -fdump-passes. It had stopped working because
>> dump_passes was changed to use the FOR_EACH_DEFINED_FUNCTION iterator,
>> however, functions are not marked as defined until
Hi!
On Wed, 29 May 2013 16:21:38 +0200, Paolo Bonzini wrote:
> Il 29/05/2013 12:50, Thomas Schwinge ha scritto:
> >>> How about we use something like the following [...] patch? In
> >>> essence, replace the manual parsing in
> >>> gcc/ada/gcc-interface/Makefile.in by using the values the
> >>>
On Tue, May 28, 2013 at 10:39 PM, Steven Bosscher wrote:
> On Tue, May 28, 2013 at 9:36 PM, Richard Sandiford
> wrote:
>> Hi Steven,
>>
>> Steven Bosscher writes:
>>> Imho the active-insn "idiom" is the best solution for the moment. I
>>> will fix this mess properly asap, probably next week.
>>
OK, I'll commit the early inline part.
Dehao
On Wed, May 29, 2013 at 10:00 AM, Xinliang David Li wrote:
> The early inlining part is ok. The tracer optimization should be
> revisited -- we should have more fine grain control on it (for
> instance, based on FDO summary -- but that should be commo
Hi
Since b/8397853 has been fixed, the related tests now passed, so we can remove
them from powerpc64-grtev3-linux-gnu.xfail now.
Tested with ./buildit --run_tests.
OK for google 4.7 branch?
thanks
Carrot
2013-05-29 Guozhi Wei
* powerpc64-grtev3-linux-gnu.xfail (*** g++): Remove passed re
Are there any further comments on this? Do I need to post a final
patch? Can it be committed yet?
ok.
David
On Wed, May 29, 2013 at 5:18 PM, Carrot Wei wrote:
> Hi
>
> Since b/8397853 has been fixed, the related tests now passed, so we can remove
> them from powerpc64-grtev3-linux-gnu.xfail now.
>
> Tested with ./buildit --run_tests.
>
> OK for google 4.7 branch?
>
> thanks
> Carrot
>
>
> 20
On 5/21/13, Diego Novillo wrote:
> On May 13, 2013 Lawrence Crowl wrote:
> > I still have not heard from i386 or ia64 folks. Anyone?
>
> The i386 bits look fine to me as well. Please wait 48 hours to
> give the i386 maintainers a chance to object.
Committed.
--
Lawrence Crowl
67 matches
Mail list logo
