On Monday 24 December 2012 17:26:47 Leif Ekblad wrote:
> In the case of cpuid, the code is hardly performance sensitive, and
> probably runs only at startup. An alternative solution for the broken code
> here is to move the result from rbx to another register, and to
> save/restore rbx. Currently,
In the case of cpuid, the code is hardly performance sensitive, and probably
runs only at startup. An alternative solution for the broken code here is to
move the result from rbx to another register, and to save/restore rbx.
Currently, this is the only place in libgcc and newlib affected by this
Uros Bizjak writes:
> Hello!
>
> Currently, we use %rbx as REAL_PIC_OFFSET_TABLE_REGNUM on x86_64.
> Since this register gets marked as fixed reg in
> ix86_conditional_register_usage, we get into troubles with insns that
> use %rbx (cmpxchg, cpuid). According to x86_64 psABI, we are free to
> use
On Mon, Dec 24, 2012 at 7:57 AM, Dodji Seketeli wrote:
> Gabriel Dos Reis writes:
>
> G> On Sun, Dec 23, 2012 at 11:04 PM, Jason Merrill wrote:
>>> On 12/21/2012 07:35 AM, Dodji Seketeli wrote:
else if (TREE_TYPE (t)
&& INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))
On Fri, Dec 21, 2012 at 11:07 AM, Jakub Jelinek wrote:
> Do you happen to use spaces or similar problematic characters in the build
> directory path?
> Can you paste some command line from libgomp.log?
Something is definitely broken. When I run the fortran tests by
themselves, it is okay, but in
Hello!
Currently, we use %rbx as REAL_PIC_OFFSET_TABLE_REGNUM on x86_64.
Since this register gets marked as fixed reg in
ix86_conditional_register_usage, we get into troubles with insns that
use %rbx (cmpxchg, cpuid). According to x86_64 psABI, we are free to
use any register, so attached patch ch
Il 21/12/2012 06:17, Alexandre Oliva ha scritto:
> Revision 193063 brought in calls to fraiseexcept() into libquadmath,
> which caused a build regression on Fedora 16 (BLAG 160k actually) x86_64
> while building an i686-linux-gnu native toolchain.
>
> The problem is that glibc has an extern inline
Jason Merrill writes:
> On 12/22/2012 11:03 AM, Dodji Seketeli wrote:
>> [1]: The relacement of the VAR_DECL by its initializer is done by
>> decay_conversion by callig decl_constant_value_safe. That replacement
>> doesn't happen if processing_template_decl is not set. That's why it
>> doesn't
Gabriel Dos Reis writes:
G> On Sun, Dec 23, 2012 at 11:04 PM, Jason Merrill wrote:
>> On 12/21/2012 07:35 AM, Dodji Seketeli wrote:
>>>
>>> else if (TREE_TYPE (t)
>>>&& INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))
>>> - && !TREE_CONSTANT (t))
>>> + && !TREE_CO
Jason Merrill writes:
> On 12/21/2012 07:35 AM, Dodji Seketeli wrote:
>> else if (TREE_TYPE (t)
>> && INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))
>> - && !TREE_CONSTANT (t))
>> + && !TREE_CONSTANT (t)
>> + /* Class template and alias template arguments should be O
... to explain more concretely what I mean, if I *brutally* hack
mainline per the below, then the testcase is accepted.
Paolo.
//
Index: call.c
===
--- call.c (revision 194659)
+++ call.c (working copy)
@@
On 12/24/2012 05:56 AM, Jason Merrill wrote:
On 12/22/2012 06:02 PM, Paolo Carlini wrote:
Well, we still reject it after the patch
My 4.7 and trunk compilers both accept it (with -std=c++11, of course).
I just updated and rebuilt my 4.7 for you (which definitely I didn't
hack over the next da
12 matches
Mail list logo
