On Fri, Jan 10, 2014 at 11:29 PM, H.J. Lu wrote:
> Hi,
>
> This patch adds PROCESSOR_INTEL, which is almost identical to
> PROCESSOR_SILVERMONT, except that __tune_slm__/__tune_silvermont__
> aren't defined for -mtune=intel. OK for trunk?
No, we have said that -mtune=intel is used to tune for *c
On Sat, Jan 11, 2014 at 2:42 PM, Bin.Cheng wrote:
> On Wed, Dec 11, 2013 at 4:18 AM, Jeff Law wrote:
>> On 12/10/13 00:01, bin.cheng wrote:
>>>
>>> Emm, some kind of. See the cost of iv candidate set consists of several
>>> parts, the representation cost in cost pair; the register pressure cost
On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote:
> > I reduced the case and attached ivopt dumps with/without the patch.
> > It seems the patch is doing right thing and choosing better
> > candidates, most likely it reveals an existing bug.
> > I am looking into this issue, in the meantim
On Sat, Jan 11, 2014 at 5:07 PM, Jakub Jelinek wrote:
> On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote:
>> > I reduced the case and attached ivopt dumps with/without the patch.
>> > It seems the patch is doing right thing and choosing better
>> > candidates, most likely it reveals an ex
Le 09/01/2014 14:33, Janus Weil a écrit :
> After noticing that the bug is actually a regression (see PR 57042):
> Ok to backport to 4.7 and 4.8?
>
Sure!
Mikael
Le 09/01/2014 16:30, Janus Weil a écrit :
> Hi all,
>
> the attached patch started out as an ICE-on-invalid regression fix,
> but after the ICE had been fixed recently by other means, it was
> degraded to a mere error-recovery improvement. It removes some rather
> 'hackish' code that was added b
On Fri, Jan 10, 2014 at 5:24 PM, Jakub Jelinek wrote:
> On Fri, Jan 10, 2014 at 07:20:38PM +0300, Kirill Yukhin wrote:
>> @@ -28920,6 +28927,7 @@ static const struct builtin_description
>> bdesc_special_args[] =
>>{ OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_movntv16sf,
>> "__builtin_ia32_mov
Le 04/01/2014 16:35, Janus Weil a écrit :
> Hi Mikael,
>
>> this patch fixes PR58007, where the compiler was not able to relate a
>> component pointer to any loaded derived type symbol.
>> The problem came from an optimization avoiding loading again a symbol
>> which had already been loaded, skip
On 01/09/2014 11:49 PM, Jonathan Wakely wrote:
On 9 January 2014 21:55, François Dumont wrote:
All unordered_* tests run under Linux x86_64.
Please make sure you run the entire testsuite, not just the parts that
seem relevant.
Done and no failure, ok to commit ?
François
On Wed, Dec 25, 2013 at 12:41 PM, H.J. Lu wrote:
> Hi,
>
> In libitm, x86_sse.cc must be compiled with -msse and x86_avx.cc must
> be compiled with -mavx. We need to make sure that -msse/-mavx is
> appended at the end of compiler options. This patch appends -msse/-mavx
> to CXXFLAGS, instead of
The attached patch fixes both these bugs, combining Steve's patch and mine.
Recent fixes of memory leaks placed the free_line before the generation of the
error messages rather than after, The item_count which identifies the read list
item involved with the error was getting cleared, resulting in
After Jakub changed i?386/x86_64 to use SWITCHABLE_TARGET, he asked me to
look at changing rs6000 too. Here's the rs6000 patch, which is basically
identical to the i386.[hc] change Jakub made. This passed bootstrap and
regtesting on powerpc64-linux with no regressions. Ok for mainline?
Peter
On Thu, 2014-01-09 at 10:36 +0100, Bernd Edlinger wrote:
> On Thu, 9 Jan 2014 10:28:43, Jakub Jelinek wrote:
> > Yeah, if i386 is changed into SWITCHABLE_TARGET, then I'd strongly encourage
> > rs6000 and nios folks to follow the suit.
>
> Ok for me. Hope they read this thread...
The rs600 patch
My apologies please. I forgot to mention Dominiq for his superb assistance with
this patch and testing. Many thanks!
On 01/11/2014 09:13 AM, Jerry DeLisle wrote:
> The attached patch fixes both these bugs, combining Steve's patch and mine.
> Recent fixes of memory leaks placed the free_line befor
On Sat, Jan 11, 2014 at 12:16 PM, Peter Bergner wrote:
> After Jakub changed i?386/x86_64 to use SWITCHABLE_TARGET, he asked me to
> look at changing rs6000 too. Here's the rs6000 patch, which is basically
> identical to the i386.[hc] change Jakub made. This passed bootstrap and
> regtesting on
On Sat, Jan 11, 2014 at 09:27:44AM -0800, Jerry DeLisle wrote:
> My apologies please. I forgot to mention Dominiq for his
> superb assistance with this patch and testing. Many thanks!
>
Add Dominiq to the ChangeLog entry. I think the patch
is OK.
--
Steve
This patch adds builtins to load and store the PowerPC floating point
status and control register.
* config/rs6000/rs6000.c (rs6000_expand_mtfsf_builtin): New.
(rs6000_expand_builtin): Handle mffs and mtfsf.
(rs6000_init_builtins): Define mffs and mtfsf.
* config/rs
On 31 October 2013 16:46, Tom Tromey wrote:
>> "Matthias" == Matthias Klose writes:
>
> Matthias> Starting with gdb 7.6, gdb can be linked with both Python 2.x
> Matthias> and Python 3.x. Therefore the pretty printers should be
> Matthias> compatible with both Python versions.
>
> Thanks for
2014/1/11 Mikael Morin :
> Le 09/01/2014 14:33, Janus Weil a écrit :
>> After noticing that the bug is actually a regression (see PR 57042):
>> Ok to backport to 4.7 and 4.8?
>>
> Sure!
Thanks. Committed to 4.8 as r206556. Will do 4.7 soon.
Cheers,
Janus
Hi,
>>> this patch fixes PR58007, where the compiler was not able to relate a
>>> component pointer to any loaded derived type symbol.
>>> The problem came from an optimization avoiding loading again a symbol
>>> which had already been loaded, skipping by the way the association of
>>> component p
Hi,
aarch64_build_constant incorrectly truncates the immediate when
constants are generated with MOVN. This causes coinor-osi tests to fail
(tracked also in https://bugs.launchpad.net/gcc-linaro/+bug/1263576)
Attached patch fixes this. Also attaching a reduced testcase that
reproduces this. Teste
21 matches
Mail list logo