On Wed, Mar 23, 2011 at 07:15, Jerry DeLisle wrote:
> On 03/22/2011 06:19 AM, Janne Blomqvist wrote:
>>
>> On Tue, Mar 22, 2011 at 03:15, Jerry DeLisle
>> wrote:
>>>
>>> Ping
>>>
>>> On 03/19/2011 09:46 PM, Jerry DeLisle wrote:
Hi,
The attached patch re-implements read_x using
On 03/22/2011 06:19 AM, Janne Blomqvist wrote:
On Tue, Mar 22, 2011 at 03:15, Jerry DeLisle wrote:
Ping
On 03/19/2011 09:46 PM, Jerry DeLisle wrote:
Hi,
The attached patch re-implements read_x using fbuf_getc. Self explanatory.
I suspect this doesn't actually fix the issue with reading fr
On Tue, Mar 22, 2011 at 9:52 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>>> This suggests that, at least, when sizeof(_Unwind_Word) > sizeof(void*),
>>> we need to extend _Unwind_Context with a new array at the end, and use
>>> that new array when by_value[REG] is true.
>>
>> Will there be
"H.J. Lu" writes:
>> This suggests that, at least, when sizeof(_Unwind_Word) > sizeof(void*),
>> we need to extend _Unwind_Context with a new array at the end, and use
>> that new array when by_value[REG] is true.
>
> Will there be a case where 2 copies of unwind-dw2.c are within the same
> proce
On Tue, Mar 22, 2011 at 1:05 PM, Eric Botcazou wrote:
>> It leads 2 problems:
>>
>> 1. Redundant zero-extension at function entry.
>> 2. combine doesn't check zero-extension on hard register and leads to
>> internal compiler error.
>>
>> Is there a way to avoid redundant zero-extension at function
On Tue, Mar 22, 2011 at 3:17 PM, Ian Lance Taylor wrote:
> "Ulrich Weigand" writes:
>
>> Ian Lance Taylor wrote:
>>> Andrew Pinski writes:
>>> > On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
>>> >>
>>> >> Any target on which _Unwind_Word is larger than void * is broken today,
>>> >>
On 03/22/2011 04:13 PM, Nathan Froyd wrote:
> rtx
> emit_call_insn_before_setloc (rtx pattern, rtx before, int loc)
> {
> ...
> if (pattern == NULL_RTX)
> return last;
>
> first = NEXT_INSN (first);
>
> The jump_insn and debug_insn variants have identical behavior to
> call_insn.
AFAIC
On Tue, Mar 22, 2011 at 02:28:30PM -0700, Richard Henderson wrote:
> On 03/21/2011 08:18 PM, Nathan Froyd wrote:
> > +/* Insert PATTERN before BEFORE, setting its INSN_LOCATION to LOC.
> > + MAKE_RAW indicates how to turn PATTERN into a real insn. INSNP
> > + indicates if PATTERN is meant for
Sadly, this lag is even longer than the cray port. Best I can tell,
2001-02-24 Zack Weinberg
(i750a-*-*): Error here if hosting on i750a.
(alpha*-*-winnt*, ix86-*-winnt3*): Remove stanzas entirely.
...
I.e. more than a decade ago the configury was removed.
r~
This fixes three bugs reported against the docs generated from the 4.6.0 RC.
48179 and 48234 are caused by a @section appearing in a different
order compared to the order they apepar in the @menu, so the order of
sections in the TOC and the Next/Previous navigation links do not
match the section n
"Ulrich Weigand" writes:
> Ian Lance Taylor wrote:
>> Andrew Pinski writes:
>> > On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
>> >>
>> >> Any target on which _Unwind_Word is larger than void * is broken today,
>> >> so I don't think we need to care about that case.
>> >
>> > So a MI
On 03/21/2011 03:26 AM, Andreas Krebbel wrote:
> + (XINT (rtl, 1) >= 0 && XINT (rtl, 1) < NUM_UNSPEC_VALUES)
> + ? unspec_strings[XINT (rtl, 1)] : "unkown",
> + XINT (rtl, 1));
The parentheses ought to be enclosing the entire ternary expression
for clarity. Als
On 03/21/2011 08:18 PM, Nathan Froyd wrote:
> +/* Insert PATTERN before BEFORE, setting its INSN_LOCATION to LOC.
> + MAKE_RAW indicates how to turn PATTERN into a real insn. INSNP
> + indicates if PATTERN is meant for an INSN as opposed to a JUMP_INSN,
> + CALL_INSN, etc. */
> +
> +static
On 03/21/2011 08:18 PM, Nathan Froyd wrote:
> This patch deals with the *_noloc family of functions. emit_pattern
> seemed like a good prefix, even though AIUI these functions can receive
> toplevel rtxes.
>
> * emit-rtl.c (emit_pattern_before_noloc): New function.
> (emit_insn_before
Given the views expressed by target maintainers I've applied this patch to
document the ARM and MIPS config-ml.in options as obsolete (with the
expectation that they will be removed later in the 4.7 release cycle).
I'd still encourage maintainers for the other targets with such options in
conf
> It leads 2 problems:
>
> 1. Redundant zero-extension at function entry.
> 2. combine doesn't check zero-extension on hard register and leads to
> internal compiler error.
>
> Is there a way to avoid redundant zero-extension at function entry to
> solve both problems?
Eliminating the redundant ex
> Like in the attached patch.
Sandra expressed an interest for it so I've installed it on the mainline after
bootstrapping and regtesting on x86_64-suse-linux.
2011-03-22 Eric Botcazou
* combine.c (simplify_set): Try harder to find the best CC mode when
simplifying a nested
This was approved on IRC so I've now committed it (including committing
the relevant bits to src).
--
Joseph S. Myers
jos...@codesourcery.com
2011/3/22 Richard Henderson :
> On 03/22/2011 11:01 AM, Denis Chertykov wrote:
>> Seems strange, I have a many messages from patch:
>> patching file avr-protos.h
>> patching file avr.md
>> Hunk #1 succeeded at 2646 (offset -1 lines).
>> Hunk #2 succeeded at 3234 (offset -9 lines).
>> patching file
Ian Lance Taylor wrote:
> Andrew Pinski writes:
> > On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
> >>
> >> Any target on which _Unwind_Word is larger than void * is broken today,
> >> so I don't think we need to care about that case.
> >
> > So a MIPS N32 is broken? Lots of people us
Andrew Pinski writes:
> On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
>>
>> Any target on which _Unwind_Word is larger than void * is broken today,
>> so I don't think we need to care about that case.
>
> So a MIPS N32 is broken? Lots of people use that target already and
> nothing l
> Date: Tue, 22 Mar 2011 19:31:58 +0100
> From: Kai Tietz
> Cc: gdb-patc...@sourceware.org, Dave Korn ,
> GCC Patches , Binutils
>
> > IS_ABSOLUTE_PATH already allows that when HAVE_DOS_BASED_FILE_SYSTEM is
> > true.
>
> Hmm, interesting. I look in more detail. As for DOSish file-syste
On Mar 22, 2011, at 2:11 AM, Nick Clifton wrote:
> Please may I apply the patch below to add the MN10300 target, and its
> AM33/AM34 variation, to the list of targets which do not currently
> support profiling ?
I think the target maintainers make for a better reviewer in this case, if not
obv
On 03/22/2011 11:01 AM, Denis Chertykov wrote:
> Seems strange, I have a many messages from patch:
> patching file avr-protos.h
> patching file avr.md
> Hunk #1 succeeded at 2646 (offset -1 lines).
> Hunk #2 succeeded at 3234 (offset -9 lines).
> patching file avr.c
> Hunk #2 succeeded at 250 with
2011/3/22 Pedro Alves :
> On Tuesday 22 March 2011 18:11:28, Kai Tietz wrote:
>> Ok, thanks for explaining it. I am just a bit concerned here about the
>> ABSOLUTE path detection. As then for cygwin this will be for UNIXish
>> path never true. So it might be necessary here for cygwin case to
>> a
On Tuesday 22 March 2011 18:11:28, Kai Tietz wrote:
> Ok, thanks for explaining it. I am just a bit concerned here about the
> ABSOLUTE path detection. As then for cygwin this will be for UNIXish
> path never true. So it might be necessary here for cygwin case to
> allow \|/ and ':/ for absolute
2011/3/22 Dave Korn :
> On 22/03/2011 11:00, Kai Tietz wrote:
>
>> I noticed this issue while working on those directory-separator thing
>> for DOSish file-systems, and somehow this looks odd to me. For some
>> reason the filenames.h header assumes for cygwin DOSish file-system,
>> but in fact cygw
2011/3/21 Georg-Johann Lay :
> Denis Chertykov schrieb:
>> 2011/3/18 Georg-Johann Lay :
>>
Is it tested for regressions ?
Denis.
>>> I ran tests against svn 170942 (latest 4.7.0 snapshot). Besides
>>> timestamps, the diff looks like this:
>>>
>>> 1435a1436,1437
XPASS: gcc.dg/sib
On 22/03/2011 11:00, Kai Tietz wrote:
> I noticed this issue while working on those directory-separator thing
> for DOSish file-systems, and somehow this looks odd to me. For some
> reason the filenames.h header assumes for cygwin DOSish file-system,
> but in fact cygwin uses POSIXish file-system.
On 03/22/2011 08:08 AM, Richard Sandiford wrote:
>>> + for (i = 0; i + 1 < nops; i++)
>>> +if (ops[i].commutative < MAX_EXPAND_OPERANDS
>>> + && swap_commutative_operands_with_target
>>> (ops[ops[i].commutative].value,
>>> + ops[i].value,
On Tue, Mar 22, 2011 at 06:41:25PM +0100, Rainer Orth wrote:
> Apart from the lack of wait4, libgo on IRIX 6.5 contained an undefined
> reference to strerror_r. This patch provides a replacement, based on
> gnulib/lib/strerror_r.c, but massively simplified.
gnulib strerror_r.c is GPLv3+ licensed,
Apart from the lack of wait4, libgo on IRIX 6.5 contained an undefined
reference to strerror_r. This patch provides a replacement, based on
gnulib/lib/strerror_r.c, but massively simplified.
This allowed me to link with libgo, and has been tested on
i386-pc-solaris2.11 with the result of the conf
Currently, libgo uses wait4 unconditionally, which is missing on IRIX
6.5. Fortunately, the rusage * arg is used nowhere, so I've decide to
replace wait4 by waitpid, which seems to be considerably more portable.
The following patch does this. Together with the IRIX 6 infrastructure
patch (to be
On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
>
> Any target on which _Unwind_Word is larger than void * is broken today,
> so I don't think we need to care about that case.
So a MIPS N32 is broken? Lots of people use that target already and
nothing like this has showed up yet.
Thank
Jakub Jelinek writes:
> On Tue, Mar 22, 2011 at 04:19:46PM +0100, Ulrich Weigand wrote:
>> Ian Lance Taylor wrote:
>> > "H.J. Lu" writes:
>> >
>> > > Here is the updated patch. It has
>> >
>> > This patch is OK if it bootstraps and passes tests.
>>
>> I thought the _Unwind_Context structure w
Hi Tobias...
I've been a lurker here since I posted a problem with varargs (stdarg,
really) interfaces back on May 31, 2010 ("Variable argument call does
not work on 64-bit gfortran"). You were able to determine that my
problem existed on gfortran 4.1 but was fixed in all of 4.2 through 4.6,
Hi Rainer,
sure, such a change is ok for a target maintainer to apply without
approval.
OK - thanks. (I was not sure if this was the rule, so I thought that it
was best to ask).
I'd like the targets to be kept sorted alphabetically (though this is
rarely done consistently so far).
I hav
On 03/22/2011 09:05 AM, Bernd Schmidt wrote:
> * dwarf2out.c (dwarf2out_frame_debug_expr): Handle POST_MODIFY stores
> through the stack pointer.
Ok, with an update to the function block comment concerning rule 10.
r~
On 03/22/2011 05:01 PM, Richard Henderson wrote:
> On 03/22/2011 05:31 AM, Bernd Schmidt wrote:
>> On 03/21/2011 09:50 PM, Richard Henderson wrote:
>>> Ok to commit?
>>
>> As far as the dwarf2out bits are concerned, yes but please change it to
>> also accept POST_MODIFY - your patch is identical to
On 03/22/2011 10:54 AM, Henderson, Stuart wrote:
> ping.
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00505.html
> Please can you review the attached patch to fix PR 47779.
>
> The register constant names for bfin were clashing with uClibc
> (sys/ucontext.h) when cross compiling. I've simply
On 03/22/2011 05:31 AM, Bernd Schmidt wrote:
> On 03/21/2011 09:50 PM, Richard Henderson wrote:
>> Ok to commit?
>
> As far as the dwarf2out bits are concerned, yes but please change it to
> also accept POST_MODIFY - your patch is identical to some code I need
> for a new target except for the rtx
On Tue, Mar 22, 2011 at 01:27:32PM +0100, Matthias Klose wrote:
> sparc update attached. Maybe John Dave Anglin could update hppa? Trying to get
> updates for mips. Would it be too late for an armeabi baseline file?
Thanks, I've taken your and Uros' update, added the two new exports
from today, r
Approved.
On Tue, Mar 22, 2011 at 10:06 AM, Marius Strobl wrote:
> 2011-03-22 Marius Strobl
>
> * config/sparc/freebsd.h (CPP_CPU64_DEFAULT_SPEC): Replace with...
> (FBSD_TARGET_CPU_CPP_BUILTINS): ...this.
> (TARGET_GNU_TLS, TARGET_SUN_TLS): Define.
On Tue, Mar 22, 2011 at 04:19:46PM +0100, Ulrich Weigand wrote:
> Ian Lance Taylor wrote:
> > "H.J. Lu" writes:
> >
> > > Here is the updated patch. It has
> >
> > This patch is OK if it bootstraps and passes tests.
>
> I thought the _Unwind_Context structure was part of the libgcc ABI
> and sh
On 03/22/2011 05:31 AM, Bernd Schmidt wrote:
> On 03/21/2011 09:50 PM, Richard Henderson wrote:
>> Ok to commit?
>
> As far as the dwarf2out bits are concerned, yes but please change it to
> also accept POST_MODIFY - your patch is identical to some code I need
> for a new target except for the rtx
On Tue, Mar 22, 2011 at 4:17 PM, Bernd Schmidt wrote:
> On targets where -fpic/-fPIC produce an error, we currently fail a large
> number of LTO testcases. These should be using the appropriate
> dg-require-effective-target so that they don't get run. Ok?
Ok.
Thanks,
Richard.
>
> Bernd
>
Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
> > Here is the updated patch. It has
>
> This patch is OK if it bootstraps and passes tests.
I thought the _Unwind_Context structure was part of the libgcc ABI
and should only be changed by appending to the end and/or updating
the version field?
B
Hi,
tested x86_64-darwin, committed to mainline.
Paolo.
///
2011-03-22 Paolo Carlini
* include/bits/shared_ptr.h (operator>, operator<=, operator>=): Add,
per DR 1401.
(operator==, operator!=, operator<): Fix per the letter of DR 1401.
* include/bits/
On targets where -fpic/-fPIC produce an error, we currently fail a large
number of LTO testcases. These should be using the appropriate
dg-require-effective-target so that they don't get run. Ok?
Bernd
* g++.dg/lto/20091002-1_0.C: Use "dg-require-effective-target fpic".
* g++.dg/l
Hi,
the following patch changes the GCC configuration for FreeBSD SPARC
(we only support 64-bit v9 there) so that the target CPU type may
be set via -mcpu instead of limiting to the hardcoded equivalent of
-mcpu=ultrasparc and TLS support is enabled if available. Both changes
are also present in
Hi,
The testcases are copies of corresponding moveable.cc tests, just
using the new class inheriting from std::basic_string resp.
std::basic_string and with -fno-inline.
Is that ok?
Minor nit: no 2010 among the Copyright years.
Paolo.
On Sun, Nov 21, 2010 at 09:52:43PM -0500, Nathan Froyd wrote:
> The patch below finishes off the hookization process for FUNCTION_ARG
> and related macros. It converts the internals documentation to document
> the new hooks, poisons the macros, and shuffles the target hook support
> a bit.
>
> Te
> Here is updated patch with testcases, tested with unpatched libstdc++
> where it failed to link and patched where it succeeded.
> The testcases are copies of corresponding moveable.cc tests, just
> using the new class inheriting from std::basic_string resp.
> std::basic_string and with -fno-inli
On Tue, Mar 22, 2011 at 03:26:21PM +0100, Benjamin Kosnik wrote:
>
> Thanks for reporting this issue Adam. Don't hesitate to file bug
> reports in gcc bugzilla category libstdc++ when you find problems like
> this in the future!
>
> > So, if Benjamin or other libstdc++ maintainers want it fixed f
Thanks for reporting this issue Adam. Don't hesitate to file bug
reports in gcc bugzilla category libstdc++ when you find problems like
this in the future!
> So, if Benjamin or other libstdc++ maintainers want it fixed for
> 4.6, you want a patch like attached, plus some testcases for both
> std:
On Tue, March 22, 2011 1:39 pm, Jakub Jelinek wrote:
> On Tue, Mar 22, 2011 at 01:10:14PM -, Adam Butcher wrote:
>> After a bit of poking around with nm in various objects I determined
>> that the baseline_symbols files define what should be exported. The
>> following grep+sed combo adds the n
Il 22/03/11 15.10, Jakub Jelinek ha scritto:
i.e. from ctors only the complete ctors and not the base ctors.
Probably the testcases use only complete ctors...
And I couldn't find other cases in gnu.ver that would only
export the complete ctor and not the base ctor at the same time,
these two were
On Tue, Mar 22, 2011 at 02:52:47PM +0100, Paolo Carlini wrote:
> >So, if Benjamin or other libstdc++ maintainers want it fixed for
> >4.6, you want a patch like attached, plus some testcases for both
> >std::string and std::wstring.
> Jakub, such a patch would be ok with me, if isn't too late, but,
And again, with the patch ...
On 22/03/11 14:05, Andrew Stubbs wrote:
On 14/03/11 18:17, Richard Earnshaw wrote:
> I think the order should be: not-a8, core-regs, core-regs, only-a8.
Ok, how about this?
I've tested that it still builds spec2k crafty.
Andrew
2011-03-22 Bernd Schmidt
On Tue, 2011-03-22 at 14:05 +, Andrew Stubbs wrote:
> On 14/03/11 18:17, Richard Earnshaw wrote:
> > I think the order should be: not-a8, core-regs, core-regs, only-a8.
>
> Ok, how about this?
>
> I've tested that it still builds spec2k crafty.
>
> Andrew
>
ENOPATCH
R.
On 14/03/11 18:17, Richard Earnshaw wrote:
> I think the order should be: not-a8, core-regs, core-regs, only-a8.
Ok, how about this?
I've tested that it still builds spec2k crafty.
Andrew
Il 22/03/11 14.52, Paolo Carlini ha scritto:
Jakub, such a patch would be ok with me, if isn't too late, but,
frankly I don't see why we are not seeing the issue in the existing
cons/char/moveable.cc, maybe it's something sensitive to inlining
decisions (yes a testcase is welcome!), and then if
Hi,
On Tue, Mar 22, 2011 at 01:10:14PM -, Adam Butcher wrote:
After a bit of poking around with nm in various objects I determined
that the baseline_symbols files define what should be exported. The
following grep+sed combo adds the necessary export for any architecture
that exports the C1
Hi,
After a bit of poking around with nm in various objects I determined
that the baseline_symbols files define what should be exported. The
following grep+sed combo adds the necessary export for any architecture
that exports the C1 constructor symbol.
grep _ZNSsC1EOSs libstdc++-v3/config/ab
On Tue, Mar 22, 2011 at 01:10:14PM -, Adam Butcher wrote:
> After a bit of poking around with nm in various objects I determined
> that the baseline_symbols files define what should be exported. The
> following grep+sed combo adds the necessary export for any architecture
> that exports the C1
On 17 March 2011 16:48, Richard Guenther wrote:
>> + then_datarefs = VEC_alloc (data_reference_p, heap, 1);
>> + else_datarefs = VEC_alloc (data_reference_p, heap, 1);
>> + then_ddrs = VEC_alloc (ddr_p, heap, 1);
>> + else_ddrs = VEC_alloc (ddr_p, heap, 1);
>> + if (!compute_data_dependences
On Tue, Mar 22, 2011 at 03:15, Jerry DeLisle wrote:
> Ping
>
> On 03/19/2011 09:46 PM, Jerry DeLisle wrote:
>>
>> Hi,
>>
>> The attached patch re-implements read_x using fbuf_getc. Self explanatory.
I suspect this doesn't actually fix the issue with reading from a pipe
before we have consumed all
Hi,
I found that with the latest GCC 4.6.0 release candidate, dynamically
linking against libstdc++ fails for client code that expects to move an
object derived from std::string. The move constructor (either
explicitly specified or compiler generated) of such a class fails to
link in the std::str
On Tue, Mar 22, 2011 at 08:32, Nathan Froyd wrote:
> The knowledge that building a CALL_EXPR requires three additional
> arguments is scattered about tree.c; the patch below centralizes that
> knowledge in a common function, build_call_1. This function can also
> take care of setting up the non-a
Boostrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-03-22 Richard Guenther
PR tree-optimization/48228
* tree-vrp.c (vrp_visit_phi_node): Do not stop propagating
for single-arg PHIs.
* gcc.dg/Wstrict-overflow-23.c: New testcase.
The knowledge that building a CALL_EXPR requires three additional
arguments is scattered about tree.c; the patch below centralizes that
knowledge in a common function, build_call_1. This function can also
take care of setting up the non-argument fields of CALL_EXPRs.
Tested on x86_64-unknown-linu
On 03/21/2011 09:50 PM, Richard Henderson wrote:
> Ok to commit?
As far as the dwarf2out bits are concerned, yes but please change it to
also accept POST_MODIFY - your patch is identical to some code I need
for a new target except for the rtx code.
Bernd
There are several places in libgcc where the expression
'sizeof (Wtype) * BITS_PER_UNIT' is used. We have a perfectly good
expression, W_TYPE_SIZE, for this; the patch below replaces the sizeof
expression with W_TYPE_SIZE.
Tested on x86_64-unknown-linux-gnu. I think this counts as obvious, so
I
On Mon, Mar 21, 2011 at 7:56 PM, Michael Meissner
wrote:
> I noticed that dg.gcc/torture/vector-1.c and dg.gcc/torture/vector-2.c were
> failing on 32-bit PowerPC Linux systems. The failure was due to the compiler
> complaining that by default the ABI on 32-bit does not allow passing vector
> ite
> 2011-03-22 Andreas Krebbel
>
> * recog.c (canonicalize_change_group): Use validate_unshare_change.
OK, thanks.
--
Eric Botcazou
On Tue, Mar 22, 2011 at 11:43 AM, Jakub Jelinek wrote:
> On Tue, Mar 22, 2011 at 11:25:28AM +0100, Uros Bizjak wrote:
>> std::numeric_limits<__float128>::max_digits10 long double export
>> should probably match other max_digits10 functions. At least alpha abi
>> check complains on incompatible add
Hello,
I noticed this issue while working on those directory-separator thing
for DOSish file-systems, and somehow this looks odd to me. For some
reason the filenames.h header assumes for cygwin DOSish file-system,
but in fact cygwin uses POSIXish file-system. I assume this definition
was caused by
Hi,
this is a repost of http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01389.html to
fix the annoying gcov filename handling whereby doing
gcov path/to/file.gcda
doesn't work since gcov drops the path and, therefore, doesn't find the file.
Tested on i586-suse-linux, OK for the mainline?
2011
On Tue, Mar 22, 2011 at 11:25:28AM +0100, Uros Bizjak wrote:
> std::numeric_limits<__float128>::max_digits10 long double export
> should probably match other max_digits10 functions. At least alpha abi
> check complains on incompatible added symbol without this patch.
>
> 2011-03-22 Uros Bizjak
2011/3/21 Richard Henderson :
> This is a slightly tidied patch from sometime last month, which was
> buried in a thread about dwarf2 unwind info for gas. This fixes
> some totally incorrect unwind markings in the avr backend, and adds
> support in the dwarf2 middle-end for handling avr's unique p
We forget to check that something is a TYPE before using TYPE_METHODS.
Tested on i586-suse-linux, applied on the mainline as obvious.
2011-03-22 Eric Botcazou
* c-ada-spec.c (dump_ada_template): Skip non-class instances.
--
Eric Botcazou
Index: c-ada-spec.c
===
Hello!
std::numeric_limits<__float128>::max_digits10 long double export
should probably match other max_digits10 functions. At least alpha abi
check complains on incompatible added symbol without this patch.
2011-03-22 Uros Bizjak
* config/os/gnu-linux/ldbl-extra.ver: Export
_
Dear Tobias,
Why did Jakub's patch for PR45304 not fix this? He visited the fix in
your patch upon build_library_function_decl_1 and
gfc_get_intrinsic_lib_fndecl. Should
trans-decl.c(create_function_arglist) have received the same
treatment?
Otherwise it is OK for trunk.
Thanks for the patch.
Hi Nick,
> Please may I apply the patch below to add the MN10300 target, and its
> AM33/AM34 variation, to the list of targets which do not currently
> support profiling ?
sure, such a change is ok for a target maintainer to apply without
approval.
> Index: gcc/testsuite/lib/target-support
On Mon, Mar 21, 2011 at 6:48 PM, Eric Botcazou wrote:
>> > 1) Set TREE_THIS_NOTRAP on the INDIRECT_REF built for VLA decls. This
>> > is correct since stack memory isn't considered as trapping in the IL.
>>
>> This is ok.
>
> Thanks.
>
>> > 2) Improve gimplification of complex conditions in CON
Hi Rainer, Hi Mike,
Please may I apply the patch below to add the MN10300 target, and its
AM33/AM34 variation, to the list of targets which do not currently
support profiling ?
With this patch applied I get several fewer unexpected failures from
the gcc testsuite for my mn10300 toolchai
2011/3/22 Nick Clifton :
> Hi Guys,
>
> I am applying the patch below as an obvious fix. The definition of
> SUBTARGET_OVERRIDE_OPTIONS in the i386/cygming.h header file has a
> trailing backslash at the end of the macro, leading it to include the
> line that follows. Fortunately that line is
Hi Guys,
I am applying the patch below as an obvious fix. The definition of
SUBTARGET_OVERRIDE_OPTIONS in the i386/cygming.h header file has a
trailing backslash at the end of the macro, leading it to include the
line that follows. Fortunately that line is blank, but could change
one d
On Mon, 21 Mar 2011, Diego Novillo wrote:
> On 03/18/2011 10:11 AM, Richard Guenther wrote:
> >
> > This tries to extend the previously posted CCP folding patch by
> > introducing a generic interface for non-tree-building, GIMPLE SSA
> > aware folding. The low-level interface for folding regular
This patch makes sure that there is no vararg if the procedure interface
is known. Before, for functions and subroutines without arguments, no
void_list_node.
(Related, separate and unfixed issue: For procedures without explicit
interface, the interface should be deduced from the usage.)
Bui
> This surprises me, you accept there arbitrary
> offsets and throw them away. If it behaves like i?86 GOTOFF,
> then I'd expect you want to remember the offset and
>
> > +
> > if (GET_CODE (y) == UNSPEC
> > ! && (XINT (y, 1) == UNSPEC_GOTOFF
> > ! || XINT (y, 1) == UNSPEC_PL
Hi,
this is an alternate solution to the problem described in:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00187.html
Although I still prefer the patch above since it would make
validate_change easier to use I understand that it might add
unnecessary unsharing. The unsharing for subsequent chang
On Tue, Mar 22, 2011 at 08:30:47AM +0100, Andreas Krebbel wrote:
> Index: gcc/config/s390/s390.c
> ===
> *** gcc/config/s390/s390.c.orig
> --- gcc/config/s390/s390.c
> *** s390_delegitimize_address (rtx orig_x)
> *** 5019,5
Hi,
the attached patch adds handling for PLT and PLTOFF unspecs for S/390.
With the patch also constant addends to PLTOFF and GOTOFF are
accepted.
This fixes Java bootstrap for s390x.
Applied to mainline.
Bye,
-Andreas-
2011-03-22 Andreas Krebbel
* config/s390/s390.c (s390_delegit
94 matches
Mail list logo
