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
>> +
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
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
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
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
*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
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)
OK.
Jason
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
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
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 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 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 @
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 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
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
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
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" \
>> +
* 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 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
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
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 '
22 matches
Mail list logo
