Ping
2012/12/21 Kai Tietz :
> Hello,
>
> this patch fixes the layout of the info_type-s for llp64 target. We
> used here 'long' type instead
> of pointer-scalar-witdth type. That's an issue for llp64 targets.
> I introduced for that the LONGPTR_T helper-macro, which has either
> scalar-size of '
On Wed, Dec 26, 2012 at 9:16 PM, Andi Kleen wrote:
>> Can you please post a real-world example, where using %r15 would break
>> existing code?
>
> I used to run into problems like this when porting code to gcc from icc or VC.
> A lot of hyper optimized inline assembler snippets wants to use all re
On Thu, Dec 27, 2012 at 9:08 AM, Uros Bizjak wrote:
> On Wed, Dec 26, 2012 at 9:16 PM, Andi Kleen wrote:
>>> Can you please post a real-world example, where using %r15 would break
>>> existing code?
>>
>> I used to run into problems like this when porting code to gcc from icc or
>> VC.
>> A lot
* Uros Bizjak:
> +#elif defined(__x86_64__)
> +#define __cpuid(level, a, b, c, d) \
> + __asm__ ("xchg{q}\t{%%}rbx, %q1\n\t" \
> +"cpuid\n\t" \
> +"xchg{q}\t{%%}rbx, %q1\n\t" \
> +: "
On Thu, Dec 27, 2012 at 10:10 AM, Florian Weimer wrote:
> * Uros Bizjak:
>
>> +#elif defined(__x86_64__)
>> +#define __cpuid(level, a, b, c, d) \
>> + __asm__ ("xchg{q}\t{%%}rbx, %q1\n\t" \
>> +"cpuid\n\t" \
>> +
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 148388d..575e03a 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,4 +1,7 @@
-<<< .mine
+2012-12-27 Andreas Schwab
+
+ * target.def (supports_function_versions): Fix typo.
+
2012-12-26 Sriraman Tallam
* doc/tm.texi.in (T
Dear Jerry,
thanks for the patch.However, I wonder about the following:
Will that be backward compatible with binaries compiled with GCC < 4.8
or will that cause problems? I have the feeling that it is okay as the
flag ("cf2") indicating whether "stream=" is present has still the same
type an
On Wed, Dec 26, 2012 at 11:29:42AM -0500, Anthony Green wrote:
> I've committed this patch.
>
> Thanks,
>
> Anthony Green
Anthony,
Did you run make check in libffi on this merge? These changes
appear to have broken the dejagnu testing in libffi...
# make -k check
Password:
Making check in i
Jack Howarth writes:
> Did you run make check in libffi on this merge? These changes
> appear to have broken the dejagnu testing in libffi...
The problem is the wrong definition of load_gcc_lib.
@@ -16,7 +16,7 @@
proc load_gcc_lib { filename } {
global srcdir
-load_file $srcdir/
On Thu, Dec 27, 2012 at 04:06:47PM +0100, Andreas Schwab wrote:
> Jack Howarth writes:
>
> > Did you run make check in libffi on this merge? These changes
> > appear to have broken the dejagnu testing in libffi...
>
> The problem is the wrong definition of load_gcc_lib.
>
> @@ -16,7 +16,7 @
On Sat, Dec 22, 2012 at 12:03 PM, Andreas Schwab wrote:
> Richard Biener writes:
>
>> On Sat, Dec 22, 2012 at 10:49 AM, Andreas Schwab
>> wrote:
>>> Richard Biener writes:
>>>
(I suppose somehow gmp.h is pulled in configure tests?)
>>>
>>> AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
>>> #includ
On Thu, Dec 27, 2012 at 10:19:57AM -0500, Jack Howarth wrote:
> On Thu, Dec 27, 2012 at 04:06:47PM +0100, Andreas Schwab wrote:
> > Jack Howarth writes:
> >
> > > Did you run make check in libffi on this merge? These changes
> > > appear to have broken the dejagnu testing in libffi...
> >
>
On 12/27/2012 03:12 AM, Tobias Burnus wrote:
Dear Jerry,
thanks for the patch.However, I wonder about the following:
Will that be backward compatible with binaries compiled with GCC < 4.8 or will
that cause problems? I have the feeling that it is okay as the flag ("cf2")
indicating whether "str
This patch gets GCC support for native TLS on AIX working and passing
most tests.
The patch shifts the creation of the qualified symbol name from
output_toc() to rs6000_legitimize_tls_address_aix(). I was hoping that
the separate SYMBOL_REF would prevent RTL fwprop from becoming
confused about the
OK.
Jason
On Thu, Dec 27, 2012 at 2:05 AM, Andreas Schwab wrote:
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 148388d..575e03a 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,4 +1,7 @@
> -<<< .mine
> +2012-12-27 Andreas Schwab
> +
> + * target.def (supports_function_versions)
*ping*
http://gcc.gnu.org/ml/fortran/2012-12/msg00167.html
Tobias Burnus:
Fix one of the remaining issues of PR 55763: MOVE_ALLOC with CLASS(*)
either for both arguments or only for TO=.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
Dear all,
See also the discussion in the thread starting at
http://gcc.gnu.org/ml/fortran/2012-12/msg00135.html
a) The Fortran standard only defines LOGICAL(kind=C_Bool) as being
interoperable with C - no other LOGICAL type. That matches GCC: With gcc
(the C compiler) only _Bool is a BOOLEAN
On 27/12/2012, at 1:15 AM, Alexander Ivchenko wrote:
> Hi,
>
> Currently Android dynamic loader does not support indirect functions
> (And I don't think that
> it will someday). But there is no way for us to specify that for gcc,
> and for example, tests like
> gcc.dg/attr-ifunc-* are failing on
On 12/20/12, Jonathan Wakely wrote:
> This patch started when I noticed that it's not possibly to construct
> a shared_ptr from unique_ptr, then I discovered we don't
> use D::pointer if it exists, and there were a number of other
> non-conformance issues with our std::unique_ptr. I ended up
> fi
Hi,
The attached patch fixes this problem by not calling hit_eof if EOF can be a
valid separator.
Regression tested on x86-64.
OK for trunk with test case from PR?
Regards,
Jerry
2012-12-27 Jerry DeLisle
PR libfortran/55818
* io/list_read.c (read_real): Do not call hit_eo
I'm sorry - I didn't notice that it works only for c++ frontend. It
works for me now!
thanks,
Alexander
2012/12/27 Sriraman Tallam :
> On Thu, Dec 27, 2012 at 2:05 AM, Andreas Schwab wrote:
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index 148388d..575e03a 100644
>> --- a/gcc/ChangeLog
>> +
22 matches
Mail list logo
