PING?
On Thu, Sep 22, 2011 at 2:28 PM, Ozkan Sezer wrote:
> Hi:
>
> Unless I'm missing something, the mingw CPP_SPEC changes introduced in
> r171833 have a typo: -D_REENTRANCE should read -D_REENTRANT . Patchlet
> below. Please review, and apply if it's OK.
>
>
> config/i386/mingw-w64.h (CPP_SPE
Richard Sandiford writes:
> Jan Hubicka writes:
>> the problem is sign overflow in time computation. Time should be
>> capped by MAX_TIME and we compute MAX_TIME * INLINE_SIZE_SCALE *
>> 2. This happens to be >2^31 & <2^32 so we overflow here because of use
>> of signed arithmetics.
>>
>> Index:
Bernd Schmidt writes:
> On 09/14/11 11:03, Richard Sandiford wrote:
>> ...I didn't see from an admittedly quick read of the patch how you
>> handle memory disambiguation between iterations. If a loop includes:
>>
>> lb $3,($4)
>> sb $5,1($4)
>>
>> then the two instructions can be reor
Just a suggestion, but...
Bernd Schmidt writes:
> Index: gcc/cfgcleanup.c
> ===
> --- gcc/cfgcleanup.c (revision 178734)
> +++ gcc/cfgcleanup.c (working copy)
> @@ -1488,6 +1488,16 @@ outgoing_edges_match (int mode, basic_bl
>e
On 09/30/2011 08:54 PM, Joseph S. Myers wrote:
> On Fri, 30 Sep 2011, Ramana Radhakrishnan wrote:
>
>> On 26 July 2011 10:01, Dr. David Alan Gilbert
>> wrote:
>>>
>>> +
>>> +extern unsigned int __write(int fd, const void *buf, unsigned int count);
>>
>> Why are we using __write instead of write?
Hi!
The operand can be not just SSA_NAME, but also gimple_is_min_invariant
and in that case we can ICE on the assert later on.
Example testcase is:
extern int c[64];
int
foo (int a)
{
int x = a > 1;
int y = &c[60] < (int *) 0x12345678UL;
return x | y;
}
which is undefined behavior, so I'm n
Ping for:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00558.html
which fixes an expand-time bug in thunks that return BLKmode structures
in registers. Tested on x86_64-linux-gnu and arm-linux-gnueabi.
Thanks,
Richard
Hello,
Regarding this shrink-wrapping patch, I would suggest to describe, in a
comments of one or two sentences, what shkink-wrapping means in the context
of GCC.
http://en.wikipedia.org/wiki/Shrink_wrap does not help much in understanding
that.
Cheers.
--
Basile STARYNKEVITCH http://s
Hi,
this patch makes us to stream out and stream in the order fields of cgraph
correctly, so -fno-toplevel-reorder works within single compilation unit
with -flto-partition=none.
This is currently needed to build kernel with LTO and it is useful otherwise
(i.e. I made the patch originally for some
Hi, can anyone commit it please?
Richard?
Or may be Richard?
Thanks,
Artem.
On Sat, Oct 1, 2011 at 12:21 AM, Artem Shinkarov
wrote:
> Sorry for that, the vector comparison was submitted earlier. In the
> attachment there is a new version of the patch against the latest
> checkout.
>
> Richar
On 30 September 2011 14:21, Ramana Radhakrishnan
wrote:
> Hi Dave,
>
>
> The nit-picky bit - There are still a number of formatting issues with
> your patch . Could you run your patch through
> contrib/check_GNU_style.sh and correct these. These are typically
> around problems with the number of s
The code looks good, though you are still missing some spaces before
'('. The main thing left is some testcases.
Jason
On Sep 30, 2011, at 5:19 PM, Joseph S. Myers wrote:
> On Fri, 30 Sep 2011, Tristan Gingold wrote:
>
>> If you prefer a target hook, I'm fine with that. I will write such a patch.
>>
>> I don't think it must be restricted to system headers, as it is possible
>> that the user 'imports' such a f
On 30 September 2011 18:01, H.J. Lu wrote:
> You may want to look a look at:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583
>
> ARM may have the same problem.
OK - although to be honest this patch only stretches the same
structures to 64bit - any major changes in semantics are a separate i
On Mon, Oct 03, 2011 at 03:16:11PM +0200, Tristan Gingold wrote:
>
> On Sep 30, 2011, at 5:19 PM, Joseph S. Myers wrote:
>
> Is it ok with this option name (-fdecc-extensions) or do you prefer a more
> generic option name,
> such as -fallow-unnamed-variadic-functions ?
My preference is to avoi
On 10/03/11 10:23, Richard Sandiford wrote:
> Bernd Schmidt writes:
>> On 09/14/11 11:03, Richard Sandiford wrote:
>>> ...I didn't see from an admittedly quick read of the patch how you
>>> handle memory disambiguation between iterations. If a loop includes:
>>>
>>> lb $3,($4)
>>> sb $5
On 3 October 2011 09:35, Andrew Haley wrote:
> On 09/30/2011 08:54 PM, Joseph S. Myers wrote:
>> On Fri, 30 Sep 2011, Ramana Radhakrishnan wrote:
>>
>>> On 26 July 2011 10:01, Dr. David Alan Gilbert
>>> wrote:
+
+extern unsigned int __write(int fd, const void *buf, unsigned int co
Bernd Schmidt writes:
> On 10/03/11 10:23, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> On 09/14/11 11:03, Richard Sandiford wrote:
...I didn't see from an admittedly quick read of the patch how you
handle memory disambiguation between iterations. If a loop includes:
On 10/03/11 16:21, Richard Sandiford wrote:
> so inter-iteration dependencies aren't a problem. Whereas I thought your
> modulo instruction did:
>
> A1
> B1 A2
> C1 B2 A3
> D1 C2 B3
> D2 C3
> D3
>
> so if D1 writes to memory that A2 (but not A1) _might_ load, then t
Basile Starynkevitch writes:
> What about -fallow-fully-variadic-functions or
> -fallow-very-variadic-functions ?
-fallow-parameterless-variadic-functions
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for so
On 10/03/11 16:21, Richard Sandiford wrote:
> I'm not sure I follow. Unrolling a loop {A, B, C, D} gives:
>
> A1
> B1
> C1
> D1
> A2
> B2
> C2
> D2
> A3
> B3
> C3
> D3
>
> so inter-iteration dependencies aren't a problem.
Expanding on
2011/10/3 Ozkan Sezer :
> PING?
>
> On Thu, Sep 22, 2011 at 2:28 PM, Ozkan Sezer wrote:
>> Hi:
>>
>> Unless I'm missing something, the mingw CPP_SPEC changes introduced in
>> r171833 have a typo: -D_REENTRANCE should read -D_REENTRANT . Patchlet
>> below. Please review, and apply if it's OK.
>>
>
On Mon, Oct 3, 2011 at 5:56 PM, Kai Tietz wrote:
> 2011/10/3 Ozkan Sezer :
>> PING?
>>
>> On Thu, Sep 22, 2011 at 2:28 PM, Ozkan Sezer wrote:
>>> Hi:
>>>
>>> Unless I'm missing something, the mingw CPP_SPEC changes introduced in
>>> r171833 have a typo: -D_REENTRANCE should read -D_REENTRANT . Pa
This series of patches changes the streamer cache so we can:
1- Detect when certain tree nodes have changed during parsing. This
is useful when generating a PPH image after reading a set of
images included by it. During parsing, a DECL may change from a
forward declaration to a full de
On 10/03/2011 05:14 AM, Artem Shinkarov wrote:
> Hi, can anyone commit it please?
>
> Richard?
> Or may be Richard?
Committed.
r~
This patch re-factors pph_start_record so we can separate the decision
of what marker to use from the emission of the marker.
This is used by pph_out_start_tree_record to decide if a new marker
will be needed. In this patch, it will only display debugging info.
The actual change comes in a subse
(Sorry, repost - I'd meant to cc Mike and Rainer into the
conversation, but forgot to
add them).
On 3 October 2011 13:53, David Gilbert wrote:
> On 30 September 2011 14:21, Ramana Radhakrishnan
> wrote:
>> Hi Dave,
>>
>>
>> The nit-picky bit - There are still a number of formatting issues with
>
This patch introduces actual handling of mutated records.
When the reader finds a PPH_RECORD_START_MUTATED record, it knows that
the tree it is about to read does not need to be allocated. It can be
found in the cache for an external PPH file. It reads the external
location of the tree, grabs it
Somewhat unrelated to state mutation, but I needed these changes while
debugging the code. This adds more debugging information to
cp_debug_parser.
I will be sending these debugging changes for review for trunk.
Tested on x86_64. Committed to branch.
Diego.
* parser.c (cp_debug_pars
Fixlet to update documentation for pph_cache_insert_at.
Diego.
* pph-streamer.c (pph_cache_insert_at): Fix documentation.
diff --git a/gcc/cp/pph-streamer.c b/gcc/cp/pph-streamer.c
index d0fac57..26bc6cd 100644
--- a/gcc/cp/pph-streamer.c
+++ b/gcc/cp/pph-streamer.c
@@ -402,11 +402,9 @
Bernd Schmidt writes:
> On 10/03/11 16:21, Richard Sandiford wrote:
>> so inter-iteration dependencies aren't a problem. Whereas I thought your
>> modulo instruction did:
>>
>> A1
>> B1 A2
>> C1 B2 A3
>> D1 C2 B3
>> D2 C3
>> D3
>>
>> so if D1 writes to memory that
This test just needed -fpermissive (it's a C program originally).
* g++.dg/pph/p4mean.cc: Remove XFAILs. Add -w -fpermissive flags.
diff --git a/gcc/testsuite/g++.dg/pph/p4mean.cc
b/gcc/testsuite/g++.dg/pph/p4mean.cc
index aa08239..e832ce5 100644
--- a/gcc/testsuite/g++.dg/pph/p4mean.cc
Another fixlet. All the pph cache lookup routines accept NULL index
pointers when the caller does not care for them. So should
pph_get_marker_for.
* pph-streamer-in.c (pph_read_namespace_tree): Initialize EXPR.
* pph-streamer-out.c (pph_get_marker_for): Handle NULL values
Hi,
noticed while working on finally defaulting pair' move constructor (the
way to go, proposed by Daniel, seems to be using
std::is_constructible instead of std::is_convertible
for constraining. Testing that uncovered a number of interesting latent
issues at various levels ;)
Tested x86_64
On Mon, Oct 3, 2011 at 8:16 AM, Tristan Gingold wrote:
>
> On Sep 30, 2011, at 5:19 PM, Joseph S. Myers wrote:
>
>> On Fri, 30 Sep 2011, Tristan Gingold wrote:
>>
>>> If you prefer a target hook, I'm fine with that. I will write such a patch.
>>>
>>> I don't think it must be restricted to system
This final patch adds support for type tagging cache entries (and file
records as well).
This resolves the ICEs we were getting in x6dynarray4.cc and
x7dynarray5.cc. The parser was replacing a LANG_DECL pointer (that
had been freed during decl merging) with a CALL_EXPR.
The patch is somewhat lar
On 3 October 2011 02:55, Michael Spertus wrote:
> Index: gcc/c-family/c-common.h
> ===
> --- gcc/c-family/c-common.h (revision 178892)
> +++ gcc/c-family/c-common.h (working copy)
> @@ -139,7 +139,8 @@
> RID_IS_LITERAL_TYPE,
The C6XABI defined persoality routines ID 3 and 4 use a single 24-bit block
word of unwinding data. Patch below makes sure this is preserved, rather than
treating it as a set of unwinding opcode bytes.
I seem to have lost this bit of code when I merged the ARM and c6x
implementations.
Applied
On Mon, 3 Oct 2011, Andrew Haley wrote:
> On 09/30/2011 08:54 PM, Joseph S. Myers wrote:
> > On Fri, 30 Sep 2011, Ramana Radhakrishnan wrote:
> >
> >> On 26 July 2011 10:01, Dr. David Alan Gilbert
> >> wrote:
> >>>
> >>> +
> >>> +extern unsigned int __write(int fd, const void *buf, unsigned int
Patch below makes gcc emit the resuired assembly directives for c6x unwinding
tables, same as ARM and IA64. This fixes most of the unwinding related
failures.
Tested on c6x-elf
Ok?
Paul
2011-10-03 Paul Brook
* config/c6x/c6x.c (c6x_asm_emit_except_personality,
c6x_asm_ini
On Mon, Oct 03, 2011 at 03:55:58PM +, Joseph S. Myers wrote:
> > That would be better, no? Unless __write is part of the glibc API,
> > which AFAIK it isn't.
>
> It's exported at version GLIBC_2.0 (not GLIBC_PRIVATE) under the comment
> "functions used in inline functions or macros", althoug
On 10/03/11 17:26, Richard Sandiford wrote:
> are necessarily equivalent to:
>
> Loop 3:
> A
> B A
> C B A
> D C B A
> A D C B
> B A D C
> C B A D
> D C B A
> D C B
> D C
> D
Sort of. The insns wouldn't rotate like this in a modulo-scheduled loop.
> Is that righ
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 German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.6.1.de.po', has just
On 10/03/11 13:28, Basile Starynkevitch wrote:
> Regarding this shrink-wrapping patch, I would suggest to describe, in a
> comments of one or two sentences, what shkink-wrapping means in the context
> of GCC.
See the documentation part of the patch.
Bernd
On Wed, Sep 28, 2011 at 5:29 AM, Jan Hubicka wrote:
> Hi,
> this patch adds support for V2 plugin API (thanks, Cary) that adds
> LDPR_PREVAILING_DEF_IRONLY_EXP.
> The reoslution is like LDPR_PREVAILING_DEF_IRONLY but the symbol is exported
> out of DSO. It is up to the compiler to optimize it out
Committed to trunk.
gcc/
* config/sparc/sparc.md (bmask_vis): Split into explicit 'di'
and 'si' patterns which describe the GSR changes explicitly in the
RTL using zero_extract.
(bshuffle_vis): Put the GSR use inside of the unspec.
git-svn-id: svn+ssh://gcc.gnu.o
On 10/03/11 17:57, Paul Brook wrote:
> Patch below makes gcc emit the resuired assembly directives for c6x unwinding
> tables, same as ARM and IA64. This fixes most of the unwinding related
> failures.
Most?
> * config/c6x/c6x.c (c6x_asm_emit_except_personality,
> c6x_asm_init_sect
Hi, Richard
There is a problem with the testcases of the patch you have committed
for me. The code in every test-case is doubled. Could you please,
apply the following patch, otherwise it would fail all the tests from
the vector-shuffle-patch would fail.
Also, if it is possible, could you change
On 10/02/2011 10:28 PM, David Miller wrote:
>> (set (reg:DI GSR_REG)
>> (unspec:DI [(match_dup 1) (match_dup 2) (reg:DI GSR_REG)]
>> UNSPEC_BMASK))
>
> Actually, can't we just use a (zero_extend:DI (plus:SI ...)) for the
> 32-bit case? It seems to work fine.
Sure.
>>>
> This caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50601
Hi,
do you use linker with V2 API?
Honza
>
> --
> H.J.
On 10/03/2011 09:43 AM, David Miller wrote:
> (define_insn "bshuffle_vis"
>[(set (match_operand:V64I 0 "register_operand" "=e")
> (unspec:V64I [(match_operand:V64I 1 "register_operand" "e")
> - (match_operand:V64I 2 "register_operand" "e")]
> - UN
On 10/03/2011 09:43 AM, Artem Shinkarov wrote:
> Hi, Richard
>
> There is a problem with the testcases of the patch you have committed
> for me. The code in every test-case is doubled. Could you please,
> apply the following patch, otherwise it would fail all the tests from
> the vector-shuffle-pa
Hi,
I did
cvs update
cvs diff > ~/changes.html.www.patch
It is attached. Is it applying?
Thanks, K
changes.html.www.patch
Description: Binary data
On Mon, Oct 3, 2011 at 6:12 PM, Richard Henderson wrote:
> On 10/03/2011 09:43 AM, Artem Shinkarov wrote:
>> Hi, Richard
>>
>> There is a problem with the testcases of the patch you have committed
>> for me. The code in every test-case is doubled. Could you please,
>> apply the following patch, ot
Bernd Schmidt writes:
>> Reason for asking is that (AIUI) SMS used to use stronger memory
>> disambiguation, but had to pull back to something more conservative
>> for similar reasons.
>
> Pointers? All I could find is a thread where rth seems to be of the same
> opinion as me:
>
> http://gcc.gn
> On 10/03/11 17:57, Paul Brook wrote:
> > Patch below makes gcc emit the resuired assembly directives for c6x
> > unwinding tables, same as ARM and IA64. This fixes most of the
> > unwinding related failures.
>
> Most?
There are a number of failures in g++.dg/torture/stackalign which appear to
From: Richard Henderson
Date: Mon, 03 Oct 2011 10:07:26 -0700
> On 10/03/2011 09:43 AM, David Miller wrote:
>> (define_insn "bshuffle_vis"
>>[(set (match_operand:V64I 0 "register_operand" "=e")
>> (unspec:V64I [(match_operand:V64I 1 "register_operand" "e")
>> - (mat
From: Richard Henderson
Date: Mon, 03 Oct 2011 09:49:37 -0700
> You might have a look at the "Vector Shuffle" thread, where we've been
> trying to provide builtin-level access to this feature. We've not added
> an rtx-level code for this because so far there isn't *that* much in
> common between
On 10/03/11 19:23, Richard Sandiford wrote:
> Bernd Schmidt writes:
>>> Reason for asking is that (AIUI) SMS used to use stronger memory
>>> disambiguation, but had to pull back to something more conservative
>>> for similar reasons.
>>
>> Pointers? All I could find is a thread where rth seems to
On 10/03/2011 10:42 AM, David Miller wrote:
>> You might have a look at the "Vector Shuffle" thread, where we've been
>> trying to provide builtin-level access to this feature. We've not added
>> an rtx-level code for this because so far there isn't *that* much in
>> common between the various cpu
On Mon, Oct 3, 2011 at 10:19 AM, Kirill Yukhin wrote:
> Hi,
> I did
>
> cvs update
> cvs diff > ~/changes.html.www.patch
>
> It is attached. Is it applying?
>
> Thanks, K
>
Please use "cvs diff -up" to generate the patch.
--
H.J.
On Mon, Oct 3, 2011 at 9:52 AM, Jan Hubicka wrote:
>> This caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50601
> Hi,
> do you use linker with V2 API?
>
No.
--
H.J.
Bernd Schmidt writes:
> On 10/03/11 19:23, Richard Sandiford wrote:
>> Bernd Schmidt writes:
Reason for asking is that (AIUI) SMS used to use stronger memory
disambiguation, but had to pull back to something more conservative
for similar reasons.
>>>
>>> Pointers? All I could find
On 10/03/11 20:12, Richard Sandiford wrote:
> But what I'm trying to say is that you're not just doing loop
> unrolling followed by scheduling. You're doing loop unrolling,
> followed by scheduling, followed by an overlapping of the unrolled loop
> iterations. It just felt strange that the overla
Done
K
On Mon, Oct 3, 2011 at 10:09 PM, H.J. Lu wrote:
> On Mon, Oct 3, 2011 at 10:19 AM, Kirill Yukhin
> wrote:
>> Hi,
>> I did
>>
>> cvs update
>> cvs diff > ~/changes.html.www.patch
>>
>> It is attached. Is it applying?
>>
>> Thanks, K
>>
>
> Please use "cvs diff -up" to generate the patch.
On Mon, Oct 3, 2011 at 7:07 PM, Richard Henderson wrote:
> On 10/03/2011 10:42 AM, David Miller wrote:
>>> You might have a look at the "Vector Shuffle" thread, where we've been
>>> trying to provide builtin-level access to this feature. We've not added
>>> an rtx-level code for this because so f
Hi!
std::vector acts roughly as something having a restrict pointer field,
i.e. two different std::vector objects will have the pointers pointing to
a different array, unfortunately unlike e.g. std::valarray we have 3
different pointers pointing into the array instead of 1, and we can't change
it
On Mon, Oct 3, 2011 at 11:23 AM, Kirill Yukhin wrote:
> Done
>
> K
>
> On Mon, Oct 3, 2011 at 10:09 PM, H.J. Lu wrote:
>> On Mon, Oct 3, 2011 at 10:19 AM, Kirill Yukhin
>> wrote:
>>> Hi,
>>> I did
>>>
>>> cvs update
>>> cvs diff > ~/changes.html.www.patch
>>>
>>> It is attached. Is it applying?
On 10/03/2011 11:40 AM, Artem Shinkarov wrote:
> Currently if vec_perm_ok returns false, we do not try to use a new
> vshuffle routine. Would it make sense to implement that? The only
> potential problem I can see is a possible performance degradation.
> This leads us to the second issue.
Implemen
2011-10-03 Jonathan Wakely
* testsuite/20_util/pointer_traits/pointer_to.cc: Define equality
operator and use.
Tested x86_64-linux, committed to trunk.
Index: testsuite/20_util/pointer_traits/pointer_to.cc
===
---
On 9/30/2011 8:19 AM, Joseph S. Myers wrote:
On Fri, 30 Sep 2011, Tristan Gingold wrote:
If you prefer a target hook, I'm fine with that. I will write such a patch.
I don't think it must be restricted to system headers, as it is possible
that the user 'imports' such a function (and define it
On Mon, Oct 3, 2011 at 8:02 PM, Richard Henderson wrote:
> On 10/03/2011 11:40 AM, Artem Shinkarov wrote:
>> Currently if vec_perm_ok returns false, we do not try to use a new
>> vshuffle routine. Would it make sense to implement that? The only
>> potential problem I can see is a possible performa
On Mon, Oct 3, 2011 at 12:01 PM, H.J. Lu wrote:
> On Mon, Oct 3, 2011 at 11:23 AM, Kirill Yukhin
> wrote:
>> Done
>>
>> K
>>
>> On Mon, Oct 3, 2011 at 10:09 PM, H.J. Lu wrote:
>>> On Mon, Oct 3, 2011 at 10:19 AM, Kirill Yukhin
>>> wrote:
Hi,
I did
cvs update
cvs diff
Jakub discovered that -fdump-go-spec crashes when it tries to print an
enum value which does not fit in a signed HOST_WIDE_INT. This patch
fixes the problem. Bootstrapped and tested on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
2011-10-03 Jakub Jelinek
Ian Lance Taylor
On Mon, 3 Oct 2011, Douglas Rupp wrote:
> On 9/30/2011 8:19 AM, Joseph S. Myers wrote:
> > On Fri, 30 Sep 2011, Tristan Gingold wrote:
> >
> > > If you prefer a target hook, I'm fine with that. I will write such a
> > > patch.
> > >
> > > I don't think it must be restricted to system headers, a
On Wed, Sep 28, 2011 at 4:53 PM, Richard Sandiford
wrote:
> Ayal Zaks writes:
Only request is to document that the register moves are
placed/assigned-id's in a specific order.
>>>
>>>I suppose this is the downside of splitting the patches up, sorry,
>>>but the ids are only ordered for t
On 10/3/2011 1:23 PM, Joseph S. Myers wrote:
The language accepted by the compiler in the user's source code (as
opposed to in system headers) shouldn't depend on the target except for
certain well-defined areas such as target attributes and built-in
functions; behaving the same across different
On Mon, Oct 03, 2011 at 01:09:17PM -0700, Ian Lance Taylor wrote:
> Jakub discovered that -fdump-go-spec crashes when it tries to print an
> enum value which does not fit in a signed HOST_WIDE_INT. This patch
> fixes the problem. Bootstrapped and tested on x86_64-unknown-linux-gnu.
> Committed to
Hi all,
here is a patch for a rather long-standing PR. It continues my ongoing
campaign of improving the checks for "procedure characteristics" (cf.
F08 chapter 12.3), which are relevant for dummy procedures, procedure
pointer assignments, overriding of type-bound procedures, etc.
This particular
On Mon, Oct 3, 2011 at 6:12 PM, Richard Henderson wrote:
> On 10/03/2011 09:43 AM, Artem Shinkarov wrote:
>> Hi, Richard
>>
>> There is a problem with the testcases of the patch you have committed
>> for me. The code in every test-case is doubled. Could you please,
>> apply the following patch, ot
i?86-elf and x86_64-elf targets default to
-fasynchronous-unwind-tables, like most other x86 targets, and so
since they build crtend.o they need to build it with
-fno-asynchronous-unwind-tables, like other targets. This patch
accordingly makes them use i386/t-crtstuff.
I'm not set up for full tes
On 10/01/2011 11:40 AM, David Miller wrote:
> +;; Conditional moves are possible via fcmpX --> cmaskX -> bshuffle
Does this comment mean you can fairly efficiently implement the
vcond patterns?
r~
On Fri, Sep 30, 2011 at 4:21 PM, Artem Shinkarov
wrote:
> Sorry for that, the vector comparison was submitted earlier. In the
> attachment there is a new version of the patch against the latest
> checkout.
>
> Richard, can you have a look at the genopinit.c, I am using
> set_direct_optab_handler,
This patch improves address combine for x32 by forcing the memory memory
operand of PLUS operation into register. Tested on Linux/x86-64 with
-mx32. OK for trunk?
Thanks.
H.J.
---
2011-10-03 H.J. Lu
PR target/50603
* config/i386/i386.c (ix86_fixup_binary_operands): Force th
On Sat, Oct 01, 2011 at 02:11:27PM +, Joseph S. Myers wrote:
> On Fri, 30 Sep 2011, Michael Meissner wrote:
>
> > Is this enough of a savings to continue on? I'm of two minds about it, one
> > is
>
> The thing to measure is not so much memory as startup time (how long it
> takes to compile
From: Richard Henderson
Date: Mon, 03 Oct 2011 15:19:00 -0700
> On 10/01/2011 11:40 AM, David Miller wrote:
>> +;; Conditional moves are possible via fcmpX --> cmaskX -> bshuffle
>
> Does this comment mean you can fairly efficiently implement the
> vcond patterns?
That seems to be the case. So
On 10/03/2011 06:43 PM, David Miller wrote:
> What exactly is supposed to happen when, for example, the comparison
> is between two v4hi values and the conditional move is done on
> v2si values? It seems the only requirement is that modes N and M
> be vector modes of the same size.
It's supposed
On Mon, 3 Oct 2011, David Miller wrote:
> * config/sparc/sparc.md (bmask_vis): Split into explicit 'di'
> and 'si' patterns which describe the GSR changes explicitly in the
> RTL using zero_extract.
> (bshuffle_vis): Put the GSR use inside of the unspec.
(Heh, so I guess US
On Fri, 30 Sep 2011, Artem Shinkarov wrote:
> gcc/doc
> * extend.texi: Adjust.
Pretty please document the new pattern names in doc/md.texi as
well. Thanks in advance.
brgds, H-P
> OK. Here is a new diff that hopefully takes into account all of
> Jason's and Benjamin's comments. Benjamin's TR2 build patch is not
> repeated (or tested!) here. Benjamin, I'd really appreciate if you
> wouldn't mind confirming I handled that correctly in tr2/type_traits
> (Including the inclus
> Hey! Here is a preliminary test suite. Just the basics on this one.
> There's a bit of an issue with fundamental types, ICEs, but seems
> fixable.
here's the pre-processed sources for the ICE
-benjamin
ice-reflection-1.ii.bz2
Description: application/bzip
On Mon, Oct 03, 2011 at 03:19:00PM -0700, Richard Henderson wrote:
> On 10/01/2011 11:40 AM, David Miller wrote:
> > +;; Conditional moves are possible via fcmpX --> cmaskX -> bshuffle
>
> Does this comment mean you can fairly efficiently implement the
> vcond patterns?
vcond is actually vcond
On Tue, Oct 4, 2011 at 1:00 AM, H.J. Lu wrote:
> This patch improves address combine for x32 by forcing the memory memory
> operand of PLUS operation into register. Tested on Linux/x86-64 with
> -mx32. OK for trunk?
Does the patch fix
FAIL: gcc.target/i386/pr45670.c scan-assembler-not lea[lq]
Committed to trunk.
gcc/
* config/sparc/sparc.md (fpack16_vis, fpackfix_vis, fpack32_vis): Make
GSR_REG an input operand to UNSPEC instead of a parallel USE.
(faligndata_vis): Likewise and use DI mode.
(alignaddrsi_vis, alignaddrdi_vis, alignaddrlsi_vis, alignaddr
On 10/04/2011 12:14 AM, Joseph S. Myers wrote:
i?86-elf and x86_64-elf targets default to
-fasynchronous-unwind-tables, like most other x86 targets, and so
since they build crtend.o they need to build it with
-fno-asynchronous-unwind-tables, like other targets. This patch
accordingly makes them
95 matches
Mail list logo
