Magnus Fromreide writes:
> Two spaces for members is common practice with GNU, and it seems to be
> used for libstdc++.
>
> One space for protection labels is not something I have heard of before
> and libstdc++ uses no indentation for them.
>
> A freshly started emacs also doesn't indent access l
We were always falling through to the memory default.
Also use standard_sse_constant_p on CONST_VECTOR.
* config/i386/i386.c (ix86_rtx_costs): Use standard_sse_constant_p
and don't fall thru from standard_80387_constant_p to the memory
fallback,
---
gcc/ChangeLog
Move the expansion code to i386.c next to mulv4si3. Eliminate
one shift by adding the highparts before shifting. Correct costs.
* config/i386/sse.md (mul3): Change from insn_and_split
to expander; move guts to ...
* config/i386/i386.c (ix86_expand_sse2_mulvxdi3): ... here
If we don't implement this pattern, the vectorizer is happy to
unpack the v4si and use the full mulv2di3. This results in
more element shuffling than is required.
* config/i386/i386.c (bdesc_args): Update. Change
IX86_BUILTIN_VEC_WIDEN_SMUL_ODD_V4SI to OPTION_MASK_ISA_SSE2.
The problem I'd like to solve is stuff like
pxor%xmm4, %xmm4
...
movdqa %xmm4, %xmm2
pcmpgtd %xmm0, %xmm2
In that there's no point performing the copy from xmm4
rather than just emitting a new pxor insn.
The Real Problem, as I see it, is that at the point (g)cse
runs
On Mon, 2012-06-25 at 15:17 -0700, Lawrence Crowl wrote:
> On 6/25/12, Joseph S. Myers wrote:
> > On Mon, 25 Jun 2012, Diego Novillo wrote:
> > > [ Added doc maintainers in CC ]
> > >
> I have added a bit more in the rationale, reached through the link
> at the end of that section.
>
> > > > +
>
On Tue, Jun 26, 2012 at 3:39 PM, Mike Stump wrote:
> On Jun 26, 2012, at 2:04 PM, Alexandre Oliva wrote:
>> I test i686-linux-gnu in a presumably unusual setting
>
> I like the setup and testing...
>
>> This worked fine for regression testing, but I've recently realized
>> (with the PR49888/53671
> As do I. The intent was for Ada and every other language with things like
> temporaries and cleanups to reuse the backend constructs, so that instead
> of writing optimizers, one for each language, to instead share the
> optimizer across languages. To me, the middle end and the backend are the
On Jun 26, 2012, at 2:04 PM, Alexandre Oliva wrote:
> I test i686-linux-gnu in a presumably unusual setting
I like the setup and testing...
> This worked fine for regression testing, but I've recently realized
> (with the PR49888/53671 mishap) that I'm getting tons of LTO testsuite
> failures (be
On Jun 26, 2012, at 1:55 AM, Steven Bosscher wrote:
> On Mon, Jun 25, 2012 at 10:46 AM, Eric Botcazou
> wrote:
>> It looks like DONT_USE_BUILTIN_SETJMP was invented for the IA-64, probably
>> because of the Register Stack Engine. But SPARC also has register windows,
>> albeit less sophisticated,
On Tue, Jun 26, 2012 at 2:04 PM, Alexandre Oliva wrote:
> I test i686-linux-gnu in a presumably unusual setting: it's an
> x86_64-linux-gnu system, and I've configured the GCC build to use as
> builddev tools wrapper scripts for as, ld, gnatmake and gcc that add
> flags that make them default to 3
On Tue, Jun 26, 2012 at 06:04:54PM -0300, Alexandre Oliva wrote:
> I test i686-linux-gnu in a presumably unusual setting: it's an
> x86_64-linux-gnu system, and I've configured the GCC build to use as
> builddev tools wrapper scripts for as, ld, gnatmake and gcc that add
> flags that make them defa
I test i686-linux-gnu in a presumably unusual setting: it's an
x86_64-linux-gnu system, and I've configured the GCC build to use as
builddev tools wrapper scripts for as, ld, gnatmake and gcc that add
flags that make them default to 32-bit.
This worked fine for regression testing, but I've recentl
On Jun 14, 2012, "H.J. Lu" wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671
These two patches cure the two remaining problems.
Basically, we have a problem of tracking equivalent FP-relative
addresses across basic blocks when SP varies. Once we lost track of SP,
pushing an argument f
On Jun 26, 2012, at 11:06 AM, Lawrence Crowl wrote:
> Alternatively, one could change the conventions to match an emacs
> style. Either is fine we me, as long as the style is reasonable.
It is really nice to be able to use 5 year old emacsen out of the box on the
source tree and have it just wor
On Jun 26, 2012, at 17:28 , Richard Henderson wrote:
> Ah, right, since convert_to_mode can just reshuffle the MEM.
>
> The patch is ok.
Great, will commit shortly.
Thanks a lot for your prompt feedback,
With Kind Regards,
Olivier
On Tue, 2012-06-26 at 19:51 +0100, Richard Sandiford wrote:
> > OK, I didn't really understand this setup before, but I think I get it
> > now and I see how I would use this to set -msynci. I guess I would
> > want to create a new triple for a multilib linux mips target so I will
> > work on that
On Jun 25, 2012, Richard Sandiford wrote:
> I'll leave the proper fix to Alex.
ACK. Thanks for the patch, it should help me get started.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.or
On Jun 26, 2012, Christophe Lyon wrote:
> On 25.06.2012 17:24, Joseph S. Myers wrote:
>> On Mon, 25 Jun 2012, Christophe Lyon wrote:
>>
>>> Ping?
>> I advise CCing appropriate maintainers (in this case, build system
>> maintainers) on pings.
>>
> Ping again, CCing build system maintainers as su
This patch creates the fields _CPU, _Priority and _Dispatching_Domain in
tasks' corresponding records when a rep item (pragm/attribute definition
clause/aspect specification) for this aspect is present.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-06-26 Vincent Pucci
* exp_
Forbid the use of attribute 'Old outside of postconditions, as required in
Ada 2012. Similarly as for 'Result, it may also be used in Ensures clauses
of test cases and contract cases attached to the subprogram. There is no need
anymore to detect specially references to local variables, which would
On Jun 26, 2012, at 11:29 AM, Janis Johnson wrote:
> Procedure scan-dump-times in scandump.exp uses a printable version of
> the scanned pattern in the line reported to the test summary but others
> in that file don't.
> OK for trunk?
Ok.
On Jun 26, 2012, at 9:07 AM, Michael Matz wrote:
> I agree with Jason. TARGET_EXPR and CLEANUP_POINT_EXPR might currently be
> used only for C++, but I think they are sensible general constructs to be
> supported by the gimplifier.
As do I. The intent was for Ada and every other language with
On Jun 26, 2012, at 1:59 AM, Nick Clifton wrote:
> I am applying the patch below to the 4.7 branch. It fixes the
> simple_return pattern in the RX backend so that it uses the
> (simple_return) rtl. This fixes 59 gcc testsuite failures and
> introduces no regressions.
>
> I plan on applying
On 06/26/2012 02:47 PM, Joseph S. Myers wrote:
We should start by documenting standards that are a conservative and
uncontroversial extension of the C coding standards currently used - if we
need to ask the question about whether something should be allowed, it
should not be allowed in the initia
On 06/26/2012 10:36 AM, John David Anglin wrote:
> I was just thinking that __builtin_setjmp/__builtin_longjmp might not
> interwork with the
> libc versions on hpux10.
They don't need to.
r~
Steve Ellcey writes:
> On Mon, 2012-06-25 at 20:00 +0100, Richard Sandiford wrote:
>> Or to put it another way, MIPS_ISA_LEVEL_SPEC and MIPS_ARCH_FLOAT_SPEC
>> make the multilib options explicit on the command line. You can then
>> use that information to add whatever options you want to be the d
On Tue, 26 Jun 2012, Lawrence Crowl wrote:
> Shall we enable RTTI?
I think any proposal for adding a new C++ feature to the standards should
go in its own thread on the gcc list with a meaningful subject, not this
thread which should simply be about integrating uncontroversial standards
in the
Procedure scan-dump-times in scandump.exp uses a printable version of
the scanned pattern in the line reported to the test summary but others
in that file don't. This patch fixes that in the remaining procedures
in scandump.exp. The primary advantage of using the printable pattern
is with pattern
On Mon, Jun 25, 2012 at 7:13 PM, Mike Stump wrote:
> On Jun 25, 2012, at 3:15 PM, Sterling Augustine wrote:
>> On Sat, Jun 23, 2012 at 3:55 AM, Dominique Dhumieres
>> wrote:
As I don't have access to a Darwin machine to test a fix, would you
mind updating the test?
>>>
>>> The failures
Lawrence Crowl writes:
[...]
| Shall we enable RTTI?
Benjamin made compelling arguments for doing this. And I agree.
-- Gaby
On 6/26/12, Jason Merrill wrote:
> On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
> > +orgcc_unreachable. If the checks are expensive or the
> > +compiler can reasonably carry on after the error, they may be
> > +conditioned on--enable-checking.
>
> by using gcc_checking_assert
I inserted that su
Committed as posted.
On Mon, Jun 25, 2012 at 8:35 PM, Jason Merrill wrote:
> OK.
>
> Jason
> With that concern stated, I will write into the conventions whatever
> concensus arises.
>
> Of course, I have no objection to an occasional inline cleanup.
> That is, build with -Werror and adjusting inlines that have,
> through the course of time, become larger than is useful.
This seems to
On 6/26/12, Martin Jambor wrote:
> On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
> > > I have no idea. I don't use emacs. The two-space rule for
> > > members comes from the wiki. The one-space rule for protection
> > > labels is common practice. If folks want something else,
On 6/25/12, Alexandre Oliva wrote:
> On Jun 25, 2012, Lawrence Crowl wrote:
>> +These conventions will change over time,
>> +but changing them requires that a convincing rationale.
>
> s/that//
>
>> +Complex heirarchies are to be avoided.
>
> s/heir/hier/
Both fixed.
--
Lawrence Crowl
On 6/26/2012 1:21 PM, Steven Bosscher wrote:
On Tue, Jun 26, 2012 at 7:09 PM, John David Anglin wrote:
On 6/26/2012 11:38 AM, Richard Henderson wrote:
On 06/26/2012 01:55 AM, Steven Bosscher wrote:
If __builtin_setjmp actually does work for ia64, why should we keep
DONT_USE_BUILTIN_SETJMP? Co
On Tue, Jun 26, 2012 at 7:09 PM, John David Anglin wrote:
> On 6/26/2012 11:38 AM, Richard Henderson wrote:
>>
>> On 06/26/2012 01:55 AM, Steven Bosscher wrote:
>>>
>>> If __builtin_setjmp actually does work for ia64, why should we keep
>>> DONT_USE_BUILTIN_SETJMP? Could it break user code somehow
On 06/26/2012 07:12 PM, Tobias Burnus wrote:
+i = 1
That should be i = 0, sorry for attaching an old version of the patch.
Tobias
+call foo(ac)
+call foo(at)
+call bar(ac)
+call bar(at)
+if (i /= 12) call abort()
+
This patch assumes that the basic assumed-rank support is included,
http://gcc.gnu.org/ml/fortran/2012-06/msg00144.html
The attached patch implements the support of passing non-assumed-rank
type/class arrays to assumed-rank class/type dummy arguments (type was
working before). And passing assu
On 6/26/2012 11:38 AM, Richard Henderson wrote:
On 06/26/2012 01:55 AM, Steven Bosscher wrote:
If __builtin_setjmp actually does work for ia64, why should we keep
DONT_USE_BUILTIN_SETJMP? Could it break user code somehow?
It's an ABI change for anyone using --enable-sjlj-exceptions.
But I don't
On Tue, Jun 26, 2012 at 06:07:09PM +0200, Michael Matz wrote:
> I agree with Jason. TARGET_EXPR and CLEANUP_POINT_EXPR might currently be
> used only for C++, but I think they are sensible general constructs to be
> supported by the gimplifier.
>
> But I also think that the option to disable st
Hi,
On Tue, 26 Jun 2012, Jason Merrill wrote:
> > (the gimplifier code should be in Frontend code that lowers to GENERIC
> > really and the WITH_CLEANUP_EXPR code should be C++ frontend specific
> > ...).
>
> TARGET_EXPR has been a back-end code since the dawn of GCC version
> control; if it'
On 06/26/2012 01:55 AM, Steven Bosscher wrote:
> If __builtin_setjmp actually does work for ia64, why should we keep
> DONT_USE_BUILTIN_SETJMP? Could it break user code somehow?
It's an ABI change for anyone using --enable-sjlj-exceptions.
But I don't know who that would be...
r~
On 06/26/2012 03:40 AM, Olivier Hainque wrote:
> Hello Richard,
>
> On Jun 25, 2012, at 20:36 , Richard Henderson wrote:
>
>> Can you explain the sequence that results in multiple memory
>> references? Because I can't see how it can...
>
> Compared to the point at which we were observing the p
On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
+orgcc_unreachable. If the checks are expensive or the
+compiler can reasonably carry on after the error, they may be
+conditioned on--enable-checking.
by using gcc_checking_assert
[Rationale]
+FIXME: Discussion of deleting inappropraite special
On 06/26/2012 04:28 AM, Richard Guenther wrote:
No - the fact that the flag is C++ specific but in common.opt is odd enough
and -ftemp-reuse-stack sounds very very generic - which in fact it is not,
it's a no-op in C. Is there a more formal phrase for the temporary kind that
is affected?
Not t
Hi Matt,
There's also a trivial documentation fix:
[PATCH 1/2] doc: Correct __builtin_arm_tinsr prototype documentation
and a test to exercise the intrinsics:
[PATCH 2/2] arm: add iwMMXt mmx-2.c test
These have both been checked in.
It turns out that both needed minor updates as some of th
On Tue, 26 Jun 2012, William J. Schmidt wrote:
> On Tue, 2012-06-26 at 15:06 +0200, Richard Guenther wrote:
> > On Mon, 25 Jun 2012, William J. Schmidt wrote:
> >
> > > Here's a new version of the main strength reduction patch, addressing
> > > previous comments. A couple of quick notes:
> > >
On 06/14/2012 11:55 AM, Florian Weimer wrote:
This is another attempt at ensuring that operator new[] always returns a
block of sufficient size.
This is on top of my previous patch rejecting VLA allocations:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00616.html
I've committed the patch refer
On 25/06/12 15:59, Matthew Gretton-Dann wrote:
> All,
>
> This patch adds vectoriser support for VFMA to the ARM Neon backend.
>
> Note that the VFP VFNMA and VFNMS instructions do not have Neon
> equivalents.
>
> OK?
Sorry, no. The neon versions of FMA do not handle denormalized values,
so th
Thanks for the comments, I'll look into it later in the summer.
On Tue, 26 Jun 2012, Richard Guenther wrote:
On Sat, Jun 23, 2012 at 7:18 PM, Marc Glisse wrote:
Hello,
thanks for looking into the patch. A couple more details now that I am back
from a conference:
On Wed, 20 Jun 2012, Marc G
On 25/06/12 15:59, Matthew Gretton-Dann wrote:
> All,
>
> This patch adds support to the ARM backend for generating floating-point
> fused multiply-accumulate.
>
> OK?
>
> gcc/ChangeLog:
>
> 2012-06-25 Matthew Gretton-Dann
>
> * config/arm/iterators.md (SDF): New mode iterator.
>
OK.
Jason
On Sat, Jun 23, 2012 at 7:18 PM, Marc Glisse wrote:
> Hello,
>
> thanks for looking into the patch. A couple more details now that I am back
> from a conference:
>
>
> On Wed, 20 Jun 2012, Marc Glisse wrote:
>
>> On Wed, 20 Jun 2012, Richard Guenther wrote:
>>
>>> On Sun, Jun 10, 2012 at 4:16 PM,
On Sat, 23 Jun 2012, Jan Hubicka wrote:
> >
> > Tailcalls have no argument setup cost and no return value cost.
> > This patch adjusts estminate_num_insns to reflect that.
> >
> > Honza, does this look correct?
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > Thanks,
> > Ri
Hi,
On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
...
> > I have no idea. I don't use emacs. The two-space rule for members
> > comes from the wiki. The one-space rule for protection labels is
> > common practice. If folks want something else, changes are fine
> > with me.
I
This fixes PR53752 - reinstantiating the behavior for an array with
domain [0, USIZE_MAX] during mangling (mangle it as zero-size array).
Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk
and the 4.7 branch?
Thanks,
Richard.
2012-06-26 Richard Guenther
PR c++/53752
On Tue, Jun 26, 2012 at 1:28 PM, Steven Bosscher wrote:
> On Tue, Jun 26, 2012 at 11:26 AM, Steven Bosscher
> wrote:
>> Hello,
>>
>> I'm going through the comments in http://gcc.gnu.org/PR33190
>> one-by-one. This patch addresses comment #0. OK for trunk?
Ok.
Thanks,
Richard.
> This is for co
On Tue, Jun 26, 2012 at 11:26 AM, Steven Bosscher wrote:
> Hello,
>
> I'm going through the comments in http://gcc.gnu.org/PR33190
> one-by-one. This patch addresses comment #0. OK for trunk?
This is for comment #1:
PR other/33190
* doc/tm.texi.in: Document LOGICAL_OP_NON_SHORT_C
This fixes PR53676, extending SCEV analysis to analyze truncated
operations by analyzing the operation on truncated operands instead.
Bootstrapped and tested on x86_64-unknown-linux-gnu, I plan to
install this tomorrow.
Richard.
2012-06-26 Richard Guenther
PR middle-end/53676
Hello Richard,
On Jun 25, 2012, at 20:36 , Richard Henderson wrote:
> Can you explain the sequence that results in multiple memory
> references? Because I can't see how it can...
Compared to the point at which we were observing the problem,
the code has changed a bit in this area though not s
Hi,
this patch solves problem where comdat symbols are incorrectly optimized out
even if used from
object file. With V1 plugin API this will lead to unnecesary symbols kept in
the object file.
I am not sure how important it is, since they are not that common.
I will backport this to 4.7 if Moz
Hi,
so, to make progress on the graphite front we want to get rid of the ppl
dependency. We start from Tobis move-to-isl-and-isl-scheduler branch at
github, merged current trunk into that (see also Richis mails about
cloog/isl configury), and add ISL implementations of the essential parts
tha
On Tue, Jun 26, 2012 at 11:26 AM, Steven Bosscher wrote:
> Hello,
>
> I'm going through the comments in http://gcc.gnu.org/PR33190
> one-by-one. This patch addresses comment #0. OK for trunk?
Ok.
Thanks,
Richard.
> Ciao!
> Steven
On Tue, Jun 26, 2012 at 2:43 AM, Iain Buclaw wrote:
> On 19 June 2012 17:08, Steven Bosscher
> wrote:
>> BTW you also include output.h in those two files, and I am about two
>> patches away from adding output.h to the list of headers that no front
>> end should ever include (a front end should n
Hello,
I'm going through the comments in http://gcc.gnu.org/PR33190
one-by-one. This patch addresses comment #0. OK for trunk?
Ciao!
Steven
pr33190_1.diff
Description: Binary data
On 25/06/12 22:30, Matthias Klose wrote:
> On 25.06.2012 18:21, Matthias Klose wrote:
>> On 25.06.2012 15:22, Richard Earnshaw wrote:
>>> On 25/06/12 13:08, Matthias Klose wrote:
gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of
arm*-*-linux-*eabi for ARM Linux/GNU EABI.
Hi Guys,
I am applying the patch below to the 4.7 branch. It fixes the
simple_return pattern in the RX backend so that it uses the
(simple_return) rtl. This fixes 59 gcc testsuite failures and
introduces no regressions.
I plan on applying a similar patch to the mainline sources once I
On Mon, Jun 25, 2012 at 10:46 AM, Eric Botcazou
wrote:
> It looks like DONT_USE_BUILTIN_SETJMP was invented for the IA-64, probably
> because of the Register Stack Engine. But SPARC also has register windows,
> albeit less sophisticated, and can do without it. Morever, the Ada compiler
> uses __
On 25.06.2012 17:24, Joseph S. Myers wrote:
On Mon, 25 Jun 2012, Christophe Lyon wrote:
Ping?
I advise CCing appropriate maintainers (in this case, build system
maintainers) on pings.
Ping again, CCing build system maintainers as suggested by Joseph.
(BTW I'm proposing to modify code which w
On Tue, Jun 26, 2012 at 9:03 AM, Dehao Chen wrote:
> Hi, Richard,
>
> You are right, setting UNKNOWN_LOCATION will not affect addr2line
> result. Here is the updated patch:
>
> Passed bootstrap and gcc regression tests.
>
> Is it ok for trunk?
Yes.
Thanks,
Richard.
> Thanks,
> Dehao
>
> Index:
On Mon, Jun 25, 2012 at 5:44 PM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>
>> In this testcase the alignment of arr[i] should be irrelevant - it is
>> not part of
>> the stmts that are going to be vectorized. But of course this may be
>> simply an odering issue in how we analyze data-refe
On Mon, Jun 25, 2012 at 6:25 PM, Xinliang David Li wrote:
> Are there any more concerns about this patch? If not, I'd like to check it in.
No - the fact that the flag is C++ specific but in common.opt is odd enough
and -ftemp-reuse-stack sounds very very generic - which in fact it is not,
it's a
On Mon, 25 Jun 2012, Jakub Jelinek wrote:
> Hi!
>
> On vectors, even when they satisfy
> integer_zerop/integer_onep/integer_all_onesp, the routine doesn't
> handle vector types and it is questionable if it would be a good
> optimization for them anyway. We don't handle complex there either,
> so
Ping ?
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00806.html
libgcc/ChangeLog
2012-06-13 Nick Clifton
* fp-bit.h (FLOAT_BIT_ORDER_MISMATCH): If
LIBGCC2_FLOAT_BIT_ORDER_MISMATCH is defined then use this to
determine if FLOAT_BIT_ORDER_MISMATCH should be defined.
Hi, Richard,
You are right, setting UNKNOWN_LOCATION will not affect addr2line
result. Here is the updated patch:
Passed bootstrap and gcc regression tests.
Is it ok for trunk?
Thanks,
Dehao
Index: tree-inline.c
===
--- tree-inlin
77 matches
Mail list logo
