We've been using a bare-metal 'arm-elf' cross-compiler toolchain over the years
since GCC 2.95.x/GCC3/GCC4, and it has worked fine.
Now it seems though like the 'arm-elf' target seems obsolete, and we are trying
to switch to 'arm-none-eabi'.
Though we use no standard-libs at all, we are really h
On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote:
> On 12 April 2012 09:05, Jakub Jelinek wrote:
> > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
> >
> > The directory should be /libhf/ or /libhfp/ f
2012/4/11 Jason Merrill :
[...]
> Your ChangeLog needs to be adjusted. :)
I did write an updated ChangeLog, but I pasted here the wrong one...
I committed it to trunk yesterday, hopefully with the correct
ChangeLog . I'll be backporting it to 4.7 after a relaxing weekend :-)
--
Fabien
On Wed, Apr 11, 2012 at 6:37 PM, Diego Novillo wrote:
> This patch makes the branch to build in C++ mode by default.
>
> Tested on x86_64. Committed.
Note that for merging the branch the support to build with a C host compiler
should be removed (and docs updated).
Richard.
>
> ChangeLog.cxx-co
On Wed, Apr 11, 2012 at 11:01 PM, Eric Botcazou wrote:
> Hi,
>
> this is the spurious error on asm statements of the form:
>
> error: 'asm' operand requires impossible reload
>
> present for IA-64 on mainline and 4.7 branch. As diagnosed by Ulrich, the
> code
> responsible for the error implici
> Perhaps HLE_ACQUIRE / HLE_RELEASE should be something like HLE_START /
> HLE_END instead? Not particularly great names, but at least it avoids
> overloading ACQUIRE/RELEASE and thus should make it clearer that you
> still need to specify a memory order.
>
IMHO, this is also not as good, since AC
On Wed, Apr 11, 2012 at 11:01:40PM +0200, Eric Botcazou wrote:
> 2012-04-11 Eric Botcazou
>
> PR target/48496
> * config/ia64/constraints.md (Q): Only accept non-volatile MEMs and
> also pseudo-registers during reload.
>
>
> 2012-04-11 Eric Botcazou
>
> * gcc.targe
That's a GCC 4.6-4.8 regression. Pointer intents apply to the
association status and not to the value. Thus, assigning to an
intent(in) pointer is fine. The problem was that the LHS is no pointer
due to the array access ("dt%ptr(1) =") thus, the check got triggered.
Build and regtested on x86
On 12/04/12 02:48, Joey Ye wrote:
> For thumb1 use move + add instructions for immediate move [256-510].
>
> Following is a complete range if combine an imm mov with listed
> instructions. Among them, lsls and neg have already been implemented. The
> only missing opportunity is add, in which I en
Folks,
Here is patch with removed implied atomic ACQUIRE/RELEASE. Could you
please have a look?
ChangeLog entry:
2012-04-12 Kirill Yukhin
* builtins.c (get_memmodel): Remove check of upper bound.
(expand_builtin_atomic_compare_exchange): Mask memmodel values.
* config/i
On Thu, Apr 12, 2012 at 01:37:24PM +0400, Kirill Yukhin wrote:
> Folks,
> Here is patch with removed implied atomic ACQUIRE/RELEASE. Could you
> please have a look?
+
Hello,
This is a followup on a suggestion made along the thread at
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00967.html
where we were observing the middle-end setting invalid REG_EQUIV
notes on set(mem) insns. At the time we had fixed specific locations
where this was happening via explicit
Clarifying:
On Apr 12, 2012, at 11:54 , Olivier Hainque wrote:
> At the time we had fixed specific locations
> where this was happening via explicit calls to set_unique_reg_note.
We had fixed the problems observable at the time by preventing
calls to set_unique_reg_notes when they would lead t
This makes us also use max-iteration knowledge when considering costs
for prefetching and parallelization instead of only relying on
iteration estimates which are sometimes not available.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-04-11 Richard Guenther
On Wed, Apr 11, 2012 at 5:38 PM, Andi Kleen wrote:
> Igor Zamyatin writes:
>
>> Hi All!
>>
>> It is known that imul placement is rather critical for Atom processors
>> and changes try to improve imul scheduling for Atom.
>>
>> This gives +5% performance on several tests from new OA 2.0 testsuite
On Wed, Apr 11, 2012 at 6:10 PM, Richard Guenther
wrote:
> On Wed, Apr 11, 2012 at 3:38 PM, Andi Kleen wrote:
>> Igor Zamyatin writes:
>>
>>> Hi All!
>>>
>>> It is known that imul placement is rather critical for Atom processors
>>> and changes try to improve imul scheduling for Atom.
>>>
>>> Th
On Thu, Apr 12, 2012 at 12:20 PM, Igor Zamyatin wrote:
> On Wed, Apr 11, 2012 at 6:10 PM, Richard Guenther
> wrote:
>> On Wed, Apr 11, 2012 at 3:38 PM, Andi Kleen wrote:
>>> Igor Zamyatin writes:
>>>
Hi All!
It is known that imul placement is rather critical for Atom processors
>
On Wed, Apr 11, 2012 at 5:34 PM, Andi Kleen wrote:
> Richard Guenther writes:
>>
>> 5% is not moderate. Your patch does enable unrolling at -O2 but not -O3,
>> why? Why do you disable register renaming? check_imull requires a function
>> comment.
>>
>> This completely looks like a hack for EEMB
On Wed, Apr 11, 2012 at 12:39 PM, Richard Guenther
wrote:
> On Tue, Apr 10, 2012 at 8:43 PM, Igor Zamyatin wrote:
>> Hi All!
>>
>> Here is a patch that enables unroll at O2 for Atom.
>>
>> This gives good performance boost on EEMBC 2.0 (~+8% in Geomean for 32
>> bits) with quite moderate code siz
On Thu, Apr 12, 2012 at 1:05 PM, Igor Zamyatin wrote:
> On Wed, Apr 11, 2012 at 12:39 PM, Richard Guenther
> wrote:
>> On Tue, Apr 10, 2012 at 8:43 PM, Igor Zamyatin wrote:
>>> Hi All!
>>>
>>> Here is a patch that enables unroll at O2 for Atom.
>>>
>>> This gives good performance boost on EEMBC
>
> This is a big change. Maybe it is better to break it into 2
> parts:
>
> 1. Introduce gnu-user32.h only, which can be reviewed by x86 backend
> maintainers. Another possibility is to add gnu-user-common.h instead of
> gnu-user32.h so that no changes to config.gcc are needed.
> 2. Add Android
Data-dependence analysis gets analyzing a[3] vs. a[{3, +, -1}_1] wrong
where it claims there is no dependence. That is because
analyze_siv_subscript_cst_affine uses chrec_is_positive to distinguish
cases but that returns "always negative" for zero (zero, in this case
being the distance between 3
On Thu, Apr 12, 2012 at 12:38:44AM +0200, Torvald Riegel wrote:
> On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote:
> > > Tests passing, bootstrap in progress.
> > >
> > > Comments?
> >
> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> > see that in the code. I th
> Can atom execute two IMUL in parallel? Or what exactly is the pipeline
> behavior?
As I understand from Intel's optimization reference manual, the behavior is as
follows: if the instruction immediately following IMUL has shorter latency,
execution is stalled for 4 cycles (which is IMUL's laten
> Is the standard condition for define_memory_constraint here
> /* Likewise if the address will be reloaded because
>reg_equiv_address is nonzero. For reg_equiv_mem
>we have to check. */
> else
Hi,
this is what I'm going to commit to mainline and 4_7-branch to fix the
regression.
Tested x86_64-linux, debug-mode too.
Thanks,
Paolo.
2012-04-12 Paolo Carlini
PR libstdc++/52942
* include/bits/stl_function.h (_Identity, _Select1st, _Selec
On 4/12/12 4:31 AM, Richard Guenther wrote:
On Wed, Apr 11, 2012 at 6:37 PM, Diego Novillo wrote:
This patch makes the branch to build in C++ mode by default.
Tested on x86_64. Committed.
Note that for merging the branch the support to build with a C host compiler
should be removed (and doc
On 04/11/2012 06:38 PM, Torvald Riegel wrote:
On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote:
Perhaps HLE_ACQUIRE / HLE_RELEASE should be something like HLE_START /
HLE_END instead? Not particularly great names, but at least it avoids
overloading ACQUIRE/RELEASE and thus should make it c
On Thu, Apr 12, 2012 at 2:00 PM, Alexander Monakov wrote:
>
>> Can atom execute two IMUL in parallel? Or what exactly is the pipeline
>> behavior?
>
> As I understand from Intel's optimization reference manual, the behavior is as
> follows: if the instruction immediately following IMUL has shorte
On Thu, Apr 12, 2012 at 08:21:47AM -0400, Andrew MacLeod wrote:
> On 04/11/2012 06:38 PM, Torvald Riegel wrote:
> >On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote:
> >Perhaps HLE_ACQUIRE / HLE_RELEASE should be something like HLE_START /
> >HLE_END instead? Not particularly great names, but at
On Thu, 2012-04-12 at 13:36 +0200, Andi Kleen wrote:
> On Thu, Apr 12, 2012 at 12:38:44AM +0200, Torvald Riegel wrote:
> > On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote:
> > > > Tests passing, bootstrap in progress.
> > > >
> > > > Comments?
> > >
> > > Do you really imply ACQUIRE/RELEASE w
On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
wrote:
> On Thu, Apr 12, 2012 at 2:00 PM, Alexander Monakov wrote:
>>
>>> Can atom execute two IMUL in parallel? Or what exactly is the pipeline
>>> behavior?
>>
>> As I understand from Intel's optimization reference manual, the behavior is
>> a
On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin wrote:
> On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
> wrote:
>> On Thu, Apr 12, 2012 at 2:00 PM, Alexander Monakov
>> wrote:
>>>
Can atom execute two IMUL in parallel? Or what exactly is the pipeline
behavior?
>>>
>>> As I underst
Hi Andrew,
> Does it make any sense to simply predefine the possible valid
> combinations with the HLE bit already set? it at least removes any
> possible invalid combinations and forces the programmer to consciously
> choose their memory model.
>
> ie,
> __ATOMIC_HLE_XACQ_CONSUME
> __ATOMIC_
> What if another vendor shows up, perhaps on another architecture?
HLE code is currently usually x86 specific. e.g. for practical spin locks
you have to include a __builtin_ia32_pause() on lock locked to stop speculation,
otherwise the lock path will speculate too, which is very inefficient.
So
> > __ATOMIC_HLE_XACQ_CONSUME
> > __ATOMIC_HLE_XACQ_ACQUIRE
> > __ATOMIC_HLE_XACQ_ACQ_REL
> > __ATOMIC_HLE_XACQ_SEQ_CST
> >
> > __ATOMIC_HLE_XREL_RELEASE
> > __ATOMIC_HLE_XREL_ACQ_REL
> > __ATOMIC_HLE_XREL_SEQ_CST
> >
> > or whatever happens to be valid... Doesn't really scale to adding
> > mor
On 12.04.2012 16:38, Richard Guenther wrote:
On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin wrote:
On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
wrote:
On Thu, Apr 12, 2012 at 2:00 PM, Alexander Monakov wrote:
Can atom execute two IMUL in parallel? Or what exactly is the pipeline
be
On Thu, Apr 5, 2012 at 6:15 PM, Kai Tietz wrote:
> Hello,
>
> this patch adds some basic folding capabilities to fold-const for
> equal and none-equal comparisons
> on integer typed argument.
>
> ChangeLog
>
> 2012-04-05 Kai Tietz
>
> * fold-const.c (fold_comparison_1): New
> func
On Wed, Apr 11, 2012 at 11:00:04AM +0200, Richard Guenther wrote:
> On Wed, Apr 11, 2012 at 6:15 AM, Alan Modra wrote:
> Well - you are expecting generic code to understand your arch-specific
> UNSPEC. It of course cannot.
Right.
> (USE (mem:BLK (reg 1)))
> (CLOBBER (mem:BLK (reg 1)))
>
> re
On Thu, 2012-04-12 at 08:21 -0400, Andrew MacLeod wrote:
> On 04/11/2012 06:38 PM, Torvald Riegel wrote:
> > On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote:
> >>
> > Perhaps HLE_ACQUIRE / HLE_RELEASE should be something like HLE_START /
> > HLE_END instead? Not particularly great names, but a
> > So would need much more benchmarking on macro workloads first at least.
>
> Like what, for example? I believe in this case everything also
> strongly depends on test usage model (e.g. it usually compiled with Os
> not O2) and, let's say, internal test structure - whether there are
> hot loops
> Would that be an acceptable option for everyone? Andi, would proper
> documentation resolve your ease-of-use concerns?
Proper documentation is needed in any case, but I would strongly prefer an
inherently hard-to-misuse interface. I think Andrew's proposal is the best
for that so far.
-Andi
2012/4/12 Andrey Belevantsev :
> On 12.04.2012 16:38, Richard Guenther wrote:
>>
>> On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin
>> wrote:
>>>
>>> On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
>>> wrote:
On Thu, Apr 12, 2012 at 2:00 PM, Alexander Monakov
wrote:
>
>
On 12.04.2012 17:54, Richard Guenther wrote:
2012/4/12 Andrey Belevantsev:
On 12.04.2012 16:38, Richard Guenther wrote:
On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin
wrote:
On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
wrote:
On Thu, Apr 12, 2012 at 2:00 PM, Alexander Monakov
On 28/02/12 15:27, Richard Earnshaw wrote:
> The pattern to match a big-endian machine for linux is ambiguous as
> reported by the PR and can cause some little-endian triplets to be
> confused as big-endian.
>
> This patch makes the string unambiguous.
>
> R.
>
> * config.gcc (arm*-*-linux
> I would suggest that we keep the HLE acq/rel bits independent of the
> memory order bits. Both are independent on a conceptual level. And we
> should add documentation that tells programmers that memory orders need
> always be specified.
>
Sorry, I didn't get your point. You propose to separate
Eventually I'll succeed in making tree-optimize.c empty. At least
the pass stuff I'm interested in get's better now.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-04-12 Richard Guenther
* Makefile.in (cgraphunit.o): Add $(EXCEPT_H) dependency.
2012/4/12 Andrey Belevantsev :
> On 12.04.2012 17:54, Richard Guenther wrote:
>>
>> 2012/4/12 Andrey Belevantsev:
>>>
>>> On 12.04.2012 16:38, Richard Guenther wrote:
On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin
wrote:
>
>
> On Thu, Apr 12, 2012 at 4:24 PM, Richar
On Mon, Apr 9, 2012 at 8:37 AM, Alexandre Oliva wrote:
> On Jun 3, 2011, Alexandre Oliva wrote:
>
>> According to http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01082.html
>> on Nov 20, 2009, Alexandre Oliva wrote:
>
>>> On Nov 19, 2009, Richard Guenther wrote:
In fact this exchanging of th
On Thu, Apr 5, 2012 at 3:49 PM, William J. Schmidt
wrote:
> On Thu, 2012-04-05 at 11:23 +0200, Richard Guenther wrote:
>> On Wed, Apr 4, 2012 at 9:15 PM, William J. Schmidt
>> wrote:
>> >
>> > Unfortunately this seems to be necessary if I name the two passes
>> > "reassoc1" and "reassoc2". If I
Ping.
On 26/03/12 11:14, Andrew Stubbs wrote:
On 28/02/12 17:45, Andrew Stubbs wrote:
Hi all,
This patch adds a DImode negate pattern for NEON.
Unfortunately, the NEON vneg instruction only supports vectors, not
singletons, so there's no direct way to do it in DImode, and the
compiler ends up
This fixes PR52549 - we are running into an overzealous assert
that wants to make sure we don't have PLUS_EXPR on pointers.
But that code does not really check this and falls foul of
the conversion removal code right before it that transforms
(void *)(a + b) to a + b.
Fixed as follows.
Bootstrap
This removes the special casing of zero from convert_to_pointer
(why would only that need overflow flag handling? and why would
the generic code below not properly handle it ...)
That sounds better than papering over the issue with noting
that integer_zerop can return true for non-INTEGER_CSTs a
On Wed, Apr 11, 2012 at 4:12 PM, Michael Meissner
wrote:
> It was brought to my attention that when I rewrote the floating point
> conversion operations for power7, I did not notice that the power4 and 970
> powerpc's actually support the FCFID (floating point convert) instruciton in
> 32-bit mode
This patch is a kind of follow up to the other one for the same PR -
though this one is for a separate test case, it is not a regression and
it's about actual/formal checks.
When trying to fix the rejects-valid bug, I realized that one function
was never accessed as a call to expr.c's gfc_chec
On Thu, Apr 12, 2012 at 9:22 AM, Alan Modra wrote:
> I tried that. It doesn't work without something else in the insn to
> stop rtl-dce deleting it, so you may as well use SETs. But thanks for
> the prod in the right direction. We do get slightly better results
> when the regs are not hidden a
Hi,
On Fri, Apr 06, 2012 at 06:13:20PM +0200, Eric Botcazou wrote:
> > 2012-04-03 Martin Jambor
> >
> > * expr.c (expand_expr_real_1): Pass type, not the expression, to
> > set_mem_attributes for a memory temporary. Do not call the
> > function for temporaries with a different alia
On 26/03/12 11:14, Andrew Stubbs wrote:
> On 28/02/12 17:45, Andrew Stubbs wrote:
>> Hi all,
>>
>> This patch adds a DImode negate pattern for NEON.
>>
>> Unfortunately, the NEON vneg instruction only supports vectors, not
>> singletons, so there's no direct way to do it in DImode, and the
>> compi
On Thu, Apr 12, 2012 at 5:34 PM, David Edelsohn wrote:
> On Thu, Apr 12, 2012 at 9:22 AM, Alan Modra wrote:
>
>> I tried that. It doesn't work without something else in the insn to
>> stop rtl-dce deleting it, so you may as well use SETs. But thanks for
>> the prod in the right direction. We d
Hi,
On Wed, Apr 04, 2012 at 04:42:05PM +0200, Richard Guenther wrote:
> On Wed, 4 Apr 2012, Martin Jambor wrote:
>
> > Hi everyone, especially Richi and Eric,
> >
> > I'd like to know what is your attitude to changing SRA's
> > build_ref_for_model to what it once looked like, so that it produces
On Apr 12, 2012, at 17:34 , David Edelsohn wrote:
> This version is okay, but I also want to give Richi and Olivier an
> opportunity to comment if they still have any concerns.
Thanks :) I'm rebuilding our old compiler with the patch
and will double check how things go on our original failing c
On 12/04/12 16:48, Richard Earnshaw wrote:
If negation in Neon needs a scratch register, it seems to me to be
somewhat odd that we're disparaging the ARM version.
Good point, I'm really meaning to provide missing functionality in NEON
to prevent unnecessary moves, rather than cause them, so I
On 12/04/12 17:16, Andrew Stubbs wrote:
> On 12/04/12 16:48, Richard Earnshaw wrote:
>> If negation in Neon needs a scratch register, it seems to me to be
>> somewhat odd that we're disparaging the ARM version.
>
> Good point, I'm really meaning to provide missing functionality in NEON
> to preve
On Thu, Apr 5, 2012 at 6:49 AM, William J. Schmidt
wrote:
> On Thu, 2012-04-05 at 11:23 +0200, Richard Guenther wrote:
>> On Wed, Apr 4, 2012 at 9:15 PM, William J. Schmidt
>> wrote:
>> >
>> > Unfortunately this seems to be necessary if I name the two passes
>> > "reassoc1" and "reassoc2". If I
> "Gaby" == Gabriel Dos Reis writes:
Manuel> So, in fact, libcpp is buggy for not implementing this (as can be seen
Manuel> in emacs). If/When libcpp is fixed, the column info will be correct
Manuel> for tabs. And then, one may care about printing tabs as anything
Manuel> different from a sin
On Thu, Apr 12, 2012 at 11:53 AM, Tom Tromey wrote:
>> "Gaby" == Gabriel Dos Reis writes:
>
> Manuel> So, in fact, libcpp is buggy for not implementing this (as can be seen
> Manuel> in emacs). If/When libcpp is fixed, the column info will be correct
> Manuel> for tabs. And then, one may care
On Thu, 2012-04-12 at 09:50 -0700, H.J. Lu wrote:
> On Thu, Apr 5, 2012 at 6:49 AM, William J. Schmidt
> wrote:
> > On Thu, 2012-04-05 at 11:23 +0200, Richard Guenther wrote:
> >> On Wed, Apr 4, 2012 at 9:15 PM, William J. Schmidt
> >> wrote:
> >> >
> >> > Unfortunately this seems to be necessary
On Apr 12, 2012, at 18:07 , Olivier Hainque wrote:
> I'm rebuilding our old compiler with the patch
> and will double check how things go on our original
> failing case.
All is well :) Thanks Alan!
> Well, the commit did not add a testcase and when I looked up the patch
> in the mailing list archive
> (http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01449.html) it said it
> was fixing problems not reproducible on trunk so it's basically
> impossible for me to evaluate whether it is still necessa
On Thursday 12 April 2012 02:05:23 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> > All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>
> The directory should be /libhf/ or /libhfp/ for that for consistency
> with all the other architectures.
On Thursday 12 April 2012 03:47:29 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote:
> > On 12 April 2012 09:05, Jakub Jelinek wrote:
> > > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> > >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.s
On Thu, Apr 12, 2012 at 01:49:16PM -0400, Mike Frysinger wrote:
> > ia64 installs in /lib, because it isn't a multilibbed architecture.
>
> because distros choose not to support it. in first gen chips, there was
> hardware support for running x86. so if we were to be strict, there should
> hav
On Thu, 2012-04-12 at 18:13 +0400, Kirill Yukhin wrote:
> > I would suggest that we keep the HLE acq/rel bits independent of the
> > memory order bits. Both are independent on a conceptual level. And we
> > should add documentation that tells programmers that memory orders need
> > always be spec
On Thursday 12 April 2012 13:53:13 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 01:49:16PM -0400, Mike Frysinger wrote:
> > > ia64 installs in /lib, because it isn't a multilibbed architecture.
> >
> > because distros choose not to support it. in first gen chips, there was
> > hardware support
Getting bounces from this message. Let's try again.
- Forwarded message from Steve McIntyre -
From: Steve McIntyre
Date: Wed, 11 Apr 2012 23:37:55 +0100
To: cross-dis...@lists.linaro.org
Cc: Adam Conrad , linaro-toolch...@lists.linaro.org,
Jeff Law , libc-po...@sourceware.org,
Hello!
Attached patch fixes issues around AVX2 vpermps and vpermd instructions.
1. Changes second argument of _mm256_permutevar8x32_ps to __m256i type
and consequently changes second argument of
__builtin_ia32_permvarsf256 argument to __v8si type.
2. Changes avx2_permvarv2sf pattern to accept v8s
prettyprinters.exp is never run except in non-parallel check or when
requested explicitly. Tested on powerpc-linux and checked in as
obvious.
Andreas.
2012-04-12 Andreas Schwab
* testsuite/Makefile.am (check_DEJAGNUnormal0): Run
prettyprinters.exp.
* testsuite/Makefil
Hi,
> prettyprinters.exp is never run except in non-parallel check or when
> requested explicitly. Tested on powerpc-linux and checked in as
> obvious.
Thanks Andreas.
Since you seem to pay good attention to these testing details, I wonder if you
could also help with the issue I noticed again
Sorry for the delay in getting back to you on this; I just keep thinking
there has to be a better way to deal with this issue than this
increasingly complex fixup machinery.
The basic problem we're dealing with is that two typedefs from different
contexts are considered identical for the purpo
Reviewers: asharif1, jingyu, Diego Novillo,
Message:
Hi, the newest chrome gcc (from google-main) fails to linking anything,
by looking into specs file, it seems that 'link_emulation' section is
missing in specs.
The problem I found is that SUBTARGET_EXTRA_SPECS, which is not empty
for chromeos,
On Thu, 2012-04-12 at 09:50 -0700, H.J. Lu wrote:
> On Thu, Apr 5, 2012 at 6:49 AM, William J. Schmidt
> wrote:
> > On Thu, 2012-04-05 at 11:23 +0200, Richard Guenther wrote:
> >> On Wed, Apr 4, 2012 at 9:15 PM, William J. Schmidt
> >> wrote:
> >> >
> >> > Unfortunately this seems to be necessary
Paolo Carlini writes:
> Since you seem to pay good attention to these testing details, I wonder if
> you could also help with the issue I noticed again over the last days with
> make check-performance not actually doing much if make check isn't run
> before. I bet a fix would turn out to be just
Here we have a testcase that affects both the C++ memory model and
transactional memory.
[Hans, this is caused by the same problem that is causing the
speculative register promotion issue you and Torvald pointed me at].
In the following testcase (adapted from the PR), the loop invariant
moti
On 04/12/2012 11:43 PM, Andreas Schwab wrote:
Paolo Carlini writes:
Since you seem to pay good attention to these testing details, I wonder if
you could also help with the issue I noticed again over the last days with
make check-performance not actually doing much if make check isn't run
befor
Ping.
On Tue, Apr 3, 2012 at 12:47 PM, Sriraman Tallam wrote:
> Hi,
>
> i386 maintainers - Is this patch ok?
>
> Thanks,
> -Sri.
>
> On Mon, Apr 2, 2012 at 5:48 PM, Sriraman Tallam wrote:
>> On Mon, Apr 2, 2012 at 5:38 AM, Richard Guenther
>> wrote:
>>> On Sat, Mar 31, 2012 at 1:03 AM, Srirama
, and necessitated the restructuring of
type definitions in the _Hashtable. I think the current form allows
some nice advantages in terms of nested types and expressiveness.
tested x86/linux
tested x86/linux -debug
-benjamin
20120412-334.patch.bz2
Description: application/bzip
86 matches
Mail list logo
