On 13 May 2014 20:56, Richard Earnshaw wrote:
> On 25/03/14 08:13, Zhenqiang Chen wrote:
>> Hi
>>
>> The patch enables shrink-wrap for apcs frame.
>>
>> Bootstrap and no make check regression in ARM, THUMB1 and THUMB2 modes.
>> No make check regression with "-g/-mapcs/-marm".
>> Build linux-3.14-r
> > So does this remove the last concern around Bernd's patch?
>
> And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used
> by obj-c/c++ as well, but I can't find such use)
Probably but, as previously indicated, I need to do some testing first.
--
Eric Botcazou
On 05/14/2014 10:29 AM, Konstantin Serebryany wrote:
Well, I'd say we should only install headers for components that are
supported by target platform.
maybe yes. It just complicates the patch somewhat.
True... But this seems to be the preferred way in GCC (other runtimes
also list headers ex
> 2014-05-06 Nick Clifton
>
> * except.c (init_eh): Fix computation of builtin setjmp buffer
> size.
That's the same patch as
https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00272.html
and is still incorrect.
--
Eric Botcazou
2014-05-13 23:21 GMT+04:00 Jeff Law :
> On 05/13/14 02:38, Ilya Enkovich wrote:
propagate constant bounds value and remove checks in called function).
>>>
>>>
>>> So from a linking standpoint, presumably you have to mangle the
>>> instrumented
>>> caller/callee in some manner. Right? Or
> Now we just need a __builtin_setjmp style of maintainer to review…
Let's just do what I suggested in
https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00286.html
--
Eric Botcazou
On Wed, May 14, 2014 at 11:47 AM, Yury Gribov wrote:
> On 05/14/2014 10:29 AM, Konstantin Serebryany wrote:
>>>
>>> Well, I'd say we should only install headers for components that are
>>> supported by target platform.
>>
>> maybe yes. It just complicates the patch somewhat.
>
>
> True... But this
As reported in the PR, the lto-plugin may fail to link if the host
compiler defines __GNUC__, but doesn't accept -static-libgcc (like
recent versions of clang do).
The following patch fixes this by explicitly checking for -static-libgcc
instead of relying on __GNUC__/$GNUC.
Tested by configuring
On 05/14/2014 10:46 AM, Jakub Jelinek wrote:
Ok.
Thanks, submitted in r210413.
-Y
> PR target/61084
> * config/sparc/sparc.md: Fix types of low and high in DI constant
> splitter. Use gen_int_mode in some other splitters.
OK, thanks.
--
Eric Botcazou
Hello,
This ICE comes from the ix86_dependencies_evaluation_hook code assumption
that any scheduling region will be connected. This assumption is not
correct in case of the outer loops pipelining of the selective scheduler as
explained in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901#c3.
Ian Lance Taylor wrote:
> Andrew Burgess wrote:
> > On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
> > > Andrew Burgess wrote:
> > > >if ((AUTO_DEMANGLING || GNU_DEMANGLING))
> > > > {
> > > > success = gnu_special (work, &mangled, &decl);
> > > > + if (!success
Hi Eric,
On Wed, 14 May 2014 09:28:55, Eric Botcazou wrote:
>
>>> So does this remove the last concern around Bernd's patch?
>>
>> And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used
>> by obj-c/c++ as well, but I can't find such use)
>
> Probably but, as previously indicated, I need to d
The following fixes pre/post-inc/dec gimplification of promoted
integer types. There is the issue with the way TYPE_OVERFLOW_UNDEFINED
is related to TYPE_OVERFLOW_WRAPS and the (non-)semantics of
-fno-strict-overflow.
In this case, with -On -fno-strict-overflow for a variable of
type short we ha
On Wed, May 14, 2014 at 10:57 AM, Andrey Belevantsev wrote:
> This ICE comes from the ix86_dependencies_evaluation_hook code assumption
> that any scheduling region will be connected. This assumption is not
> correct in case of the outer loops pipelining of the selective scheduler as
> explained
Hello,
As described in the PR in more details, this ICE is about the scheduler not
being able to initialize its data structures for the new unconditional jump
created when redirecting an edge and simplifying control flow. It so
happens that the new jump is the only unscheduled instruction bei
On Wed, May 14, 2014 at 10:31 AM, Rainer Orth
wrote:
> As reported in the PR, the lto-plugin may fail to link if the host
> compiler defines __GNUC__, but doesn't accept -static-libgcc (like
> recent versions of clang do).
>
> The following patch fixes this by explicitly checking for -static-libgc
Based on the Feedback, Resubmitting the Updated Patch.
[Patch, MicroBlaze] Add break Handler Support
Added Break Handler support to incorporate the hardware and software break. The
Break Handler routine
will be generating the rtbd instruction. At the call point where the software
breaks are gen
On 14/05/2014 10:01 AM, Gary Benson wrote:
> Ian Lance Taylor wrote:
>> Andrew Burgess wrote:
>>> On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
Andrew Burgess wrote:
>if ((AUTO_DEMANGLING || GNU_DEMANGLING))
> {
> success = gnu_special (work, &mangled,
On Tue, May 13, 2014 at 9:27 PM, Florian Weimer wrote:
> Patterns that trigger the optimization and warning can form after inlining,
> and it can be rather difficult to figure out what exactly is causing the
> warning. The inlining context at least provides additional hints, enabling
> developers
On 14.05.2014 13:09, Uros Bizjak wrote:
On Wed, May 14, 2014 at 10:57 AM, Andrey Belevantsev wrote:
This ICE comes from the ix86_dependencies_evaluation_hook code assumption
that any scheduling region will be connected. This assumption is not
correct in case of the outer loops pipelining of t
On Wed, 14 May 2014, Andrey Belevantsev wrote:
> Hello,
>
> As described in the PR in more details, this ICE is about the scheduler not
> being able to initialize its data structures for the new unconditional jump
> created when redirecting an edge and simplifying control flow. It so happens
>
On Tue, May 13, 2014 at 09:27:08PM +0200, Florian Weimer wrote:
> Patterns that trigger the optimization and warning can form after
> inlining, and it can be rather difficult to figure out what exactly
> is causing the warning. The inlining context at least provides
> additional hints, enabling de
Hi David,
On Tue, May 13, 2014 at 11:46:20PM -0400, David Edelsohn wrote:
> Danny may have re-organized the code, but I thought that it originally
> came from Tom Rixx, if not earlier.
OK, I'm not trying to apportion blame. My name is on plenty of dodgy
code in the rs6000 backend too. :)
> I se
> OK for trunk and 4.9.1 branch?
OK if Pascal has no objections to the patch:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00671.html
--
Eric Botcazou
> * gcc-interface/decl.c (gnat_to_gnu_entity): Convert
> integer_one_node to the appropriate type.
> * gcc-interface/trans.c (gnat_to_gnu): Likewise.
> (pos_to_constructor): Likewise.
OK for the sake of consistency, thanks.
--
Eric Botcazou
Eric,
> OK if Pascal has no objections to the patch:
> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00671.html
Looks fine to me and should have no effect for our non Cygwin builds.
--
Pascal Obry
gpg --keyserver keys.gnupg.net --recv-key F949BD3B
On 05/14/2014 11:34 AM, Richard Biener wrote:
On Tue, May 13, 2014 at 9:27 PM, Florian Weimer wrote:
Patterns that trigger the optimization and warning can form after inlining,
and it can be rather difficult to figure out what exactly is causing the
warning. The inlining context at least provi
This fixes call handling.
Committed to the branch.
Richard.
2014-05-14 Richard Biener
* gimple-match-head.c (maybe_push_res_to_seq): Fix res
!= NULL case and add a comment.
(gimple_match_and_simplify): Properly handle virtual
operands when we replace the stmt
This removes a useless local variable in emit_to_new_bb_before coming from a
patch that was later reverted, thus restoring the original code, changes the
type of locations in try_forward_edges to location_t and fixes inconsistent
comments I added to rtl_merge_blocks and cfg_layout_merge_blocks.
Hi,
this makes fold_unary_loc fold NON_LVALUE_EXPR if the argument cannot be a
lvalue (this happens when you're re-fold-building an existing tree) and
changes the first call to fold_convert_const to use arg0 instead of op0, like
the other 2 calls just below (this should not change anything if t
Am 05/13/2014 02:48 PM, schrieb Senthil Kumar Selvaraj:
On Mon, May 12, 2014 at 01:19:37PM +0200, Georg-Johann Lay wrote:
Am 04/18/2014 11:52 AM, schrieb Senthil Kumar Selvaraj:
On Sat, Apr 12, 2014 at 06:36:01PM +0200, Georg-Johann Lay wrote:
Senthil Kumar Selvaraj schrieb:
[...]
2014-04
> Attached is a patch for support of GNU/Hurd in gnat-4.9. This patch has
> been used and updated in Debian since gnat-4.6, and is currently used to
> build gnat-4.9. Now when the body file s-osinte-posix.adb in gcc-4.9
> defines tv_nsec in timespec POSIX-correctly as long again, we think it
> is t
Georg-Johann Lay writes:
> Or what about simply that, which works for me:
>
>
> Index: config/avr/avr.h
> ===
> --- config/avr/avr.h(revision 210276)
> +++ config/avr/avr.h(working copy)
> @@ -512,7 +512,11 @@ extern const ch
This handles $subject which allows us to simplify the return expression
all the way to w for the following testcase (going via
pow (x, -0.5) * x -> pow (x, 0.5) -> sqrt (w * w) -> w)
double test4 (double w)
{
double x = w * w;
double y = __builtin_pow (x, -0.5);
return y * x;
}
Committed t
https://gcc.gnu.org/r210418
Applied this patch in order to fixed build warnings like these
gcc/reginfo.c:115:5: warning: narrowing conversion of ‘-1073741824’ from ‘int’
to ‘const unsigned int’ inside { } is ill-formed in C++11 [-Wnarrowing]
gcc/reginfo.c:115:5: warning: narrowing conversion of
Hi DJ,
>> "long double" should always be 64 bits, which means that libgcc must
>> always have DFmode helpers.
Please find below a modified patch which sets the long double to 64 bits.
This will use default settings for DFmode and libgcc long double types.
I have also posted the binutils part of
On Tue, May 13, 2014 at 06:11:15PM +, Joseph S. Myers wrote:
> > + tree min = TYPE_MIN_VALUE (type);
> > + tree max = TYPE_MAX_VALUE (type);
> > + /* Add/subtract 1.0 so we can avoid truncating the value of EXPR. */
> > + min = fold_build2 (MINUS_EXPR, expr_type,
> > +build
On 05/14/2014 11:56 AM, Jakub Jelinek wrote:
On Tue, May 13, 2014 at 09:27:08PM +0200, Florian Weimer wrote:
Patterns that trigger the optimization and warning can form after
inlining, and it can be rather difficult to figure out what exactly
is causing the warning. The inlining context at leas
It seems like "shuffle of 3 loads is not supported by target" is the root cause.
The permutation like 0, 3, 6, 9, c, is not supported by the target.
Hi Richard,
Are you working on the solution to fix the breakage? I'm about
to look into this and wanted to find out how far we got with this.
Regards,
Robert
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 10 May 2014 19:44
> To: Matthew Fortune
Hi Eric,
2014-05-06 Nick Clifton
* except.c (init_eh): Fix computation of builtin setjmp buffer
size.
That's the same patch as
https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00272.html
and is still incorrect.
Ah - you are worried about the case where STACK_SAVEAREA_MODE
In final testing I noticed that vtrnf32_1.c, vtrns32_1.c and vtrnu32_1.c were
failing the scan-assembler-times test: in such two-element cases, TRN, UZP and
ZIP are all equivalent and equally valid, and the ARM backend
(arm_expand_vec_perm_const_1) outputs UZP. Hence, I've pushed the attached
p
Make the machinery in bits/parse_number.h unsigned long long.
I had actually noticed this a while back but we were in stage 4. Then I
forgot.. :-/
Built and tested on x84_64-linux.
OK?
2014-05-14 Ed Smith-Rowland <3dw...@verizon.net>
libstdc++/61166 overflow when parse number in s
Hi,
Due to differences in how the ARM C Language Extensions and gcc's vector
extensions deal with indices within vectors, the __builtin_shuffle masks used to
implement the ZIP, UZP and TRN Neon Intrinsics in arm_neon.h are correct only
for little-endian. (The problem on bigendian has recently
2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland <3dw...@verizon.net>:
> Make the machinery in bits/parse_number.h unsigned long long.
> I had actually noticed this a while back but we were in stage 4. Then I
> forgot.. :-/
>
> Built and tested on x84_64-linux.
>
> OK?
I understand the reason why the c
This makes FRE/PRE substitute values into all uses instead of leaving
copies and initializations from constants in the IL which requires
a copyprop pass to clean up things (which we usually place directly
after FRE/PRE).
This should open the possibility to remove some of the passes,
respectively
On 14 May 2014 14:59, Daniel Krügler wrote:
> 2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland <3dw...@verizon.net>:
>> Make the machinery in bits/parse_number.h unsigned long long.
>> I had actually noticed this a while back but we were in stage 4. Then I
>> forgot.. :-/
>>
>> Built and tested on x84_6
On 12 May 2014 22:24, Joseph S. Myers wrote:
> On Mon, 12 May 2014, Manuel López-Ibáñez wrote:
>
>> I will be very surprised if the common defaults are overriding a FE
>> default and it is not a bug in the FE.
>
> Well, I think that needs justification, not just "very surprised".
> Identify (presu
Hi Peter,
> I'll note that the patch includes documentation for the new keyword
> along with a few others I noticed that were missing, which I've
> included below for posterity.
fine, thanks for doing this.
Rainer
--
-
Andrew Burgess wrote:
> On 14/05/2014 10:01 AM, Gary Benson wrote:
> > Ian Lance Taylor wrote:
> > > Andrew Burgess wrote:
> > > > On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
> > > > > Andrew Burgess wrote:
> > > > > >if ((AUTO_DEMANGLING || GNU_DEMANGLING))
> > > > > > {
> > >
On 05/14/2014 09:59 AM, Daniel Krügler wrote:
2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland <3dw...@verizon.net>:
Make the machinery in bits/parse_number.h unsigned long long.
I had actually noticed this a while back but we were in stage 4. Then I
forgot.. :-/
Built and tested on x84_64-linux.
O
libcpp makes extensive use of the C preprocessor. Whilst this has a
pleasingly self-referential quality, I find the code hard-to-read;
implementing source location support in my JIT branch was much harder than
I hoped it would be.
In an attempt at making the code easier to follow, the following p
On 14 May 2014 15:25, Ed Smith-Rowland wrote:
> But in keeping with, say, our extension type traits and such maybe i should
> uglify value as well.
No, just derive from std::integral_constant and you get value "for free".
You already use integral_constant in that file, so the name "value" is
alre
On 14 May 2014 15:36, Jonathan Wakely wrote:
> On 14 May 2014 15:25, Ed Smith-Rowland wrote:
>> But in keeping with, say, our extension type traits and such maybe i should
>> uglify value as well.
>
> No, just derive from std::integral_constant and you get value "for free".
>
> You already use inte
Hi all,
Pinging again about the patch below. The lack of this patch is
essentially a blocker to using gcc+python+openmp together, which is a
shame, since python is increasingly important in numerical computing,
openmp is pretty useful, and gcc is the only openmp implementation
that does not suppor
On Wed, May 14, 2014 at 1:18 AM, Ilya Enkovich wrote:
> 2014-05-13 23:21 GMT+04:00 Jeff Law :
>> On 05/13/14 02:38, Ilya Enkovich wrote:
>
> propagate constant bounds value and remove checks in called function).
So from a linking standpoint, presumably you have to mangle the
On 14/05/14 15:41 +0100, Jonathan Wakely wrote:
On 14 May 2014 15:36, Jonathan Wakely wrote:
On 14 May 2014 15:25, Ed Smith-Rowland wrote:
But in keeping with, say, our extension type traits and such maybe i should
uglify value as well.
No, just derive from std::integral_constant and you get
Moving the location of INSN_UID broke the handling of -fdump-unnumbered.
I tested that it fixes the sparc-sun-solaris2.11 failures reported
by Rainer. Applied as obvious.
Thanks,
Richard
gcc/
PR debug/61188
* print-rtl.c (print_rtx): Suppress uids if flag_dump_unnumbered.
Index
On Fri, 2014-05-09 at 12:51 -0600, Jeff Law wrote:
> On 04/21/14 10:56, David Malcolm wrote:
> > gcc/
> > * gimple-iterator.h (struct gimple_phi_iterator): New subclass of
> > gimple_stmt_iterator with identical layout, but adding...
> > (gimple_phi_iterator::phi): ...new method, equiva
On 05/14/14 09:28, David Malcolm wrote:
Thanks.
I'm working my way through the patches, converting them to the latest
approach, where "gimple_phi" becomes "gphi *".
Given that renaming, it occurred to me that the new class
"gimple_phi_iterator" would be better named as
"gphi_iterator" (consist
Am 12.05.2014 19:30, schrieb Joseph S. Myers:
> On Mon, 12 May 2014, Matthias Klose wrote:
>
>> I didn't look close enough to the gfortran test results. PR driver/61126 is
>> a
>> fix for the regression introduced with the fix for the above issue. With
>> this
>> patch proposed by Manuel, gfor
On 05/14/14 04:40, Eric Botcazou wrote:
Hi,
this makes fold_unary_loc fold NON_LVALUE_EXPR if the argument cannot be a
lvalue (this happens when you're re-fold-building an existing tree) and
changes the first call to fold_convert_const to use arg0 instead of op0, like
the other 2 calls just belo
Hi,
I was having a look to a couple of issues in this area, and wondered if
we want to do something like the below? In case, I would also go with
the first init.c hunk and the mangle.c hunk, I don't think the
additional check can hurt?!?
Thanks,
Paolo.
/
... the draft ;)
///
Index: call.c
===
--- call.c (revision 210424)
+++ call.c (working copy)
@@ -6071,8 +6071,7 @@ convert_like_real (conversion *convs, tree expr, t
constructors, but actually tr
On Wed, 14 May 2014, Jakub Jelinek wrote:
> So what do you see as the way to handle this properly?
> I mean, for REAL_MODE_FORMAT (TYPE_MODE (expr_type))->b == 2 supposedly to
> avoid issues with
> rounding of the max we could just
> REAL_VALUE_TYPE maxval = dconst1;
> SET_REAL_EXP (&maxval,
On 05/13/14 02:13, Marek Polacek wrote:
On Tue, May 13, 2014 at 04:08:21PM +0800, Zhenqiang Chen wrote:
On 13 May 2014 15:55, Marek Polacek wrote:
On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote:
Thanks. Committed the patch @r210351 with changes:
(1) Create shrink-wrap.h.
(2) M
On 05/13/14 03:49, Zhenqiang Chen wrote:
On 9 May 2014 14:08, Jeff Law wrote:
On 05/08/14 02:07, Zhenqiang Chen wrote:
Hi,
The patch splits the live_edge for move_insn_for_shrink_wrap to sink
the copy out of the entry block.
Bootstrap and no make check regression on X86-64 and ARM.
OK for
On 05/12/14 15:36, David Malcolm wrote:
[ ... Big Snip ... ]
This series of 3 patches is approved.
Jeff
On 05/13/14 04:04, Zhenqiang Chen wrote:
After reading the code in regcprop.c, I think I should reuse the
copyprop_hardreg_forward_1. So rewrite the patch, which is much simple
and should handle HAVE_cc0. But not sure we'd handle DEBUG_INSN or
not.
2014-05-13 Zhenqiang Chen
* regcpr
On 05/13/14 14:11, Sandra Loosemore wrote:
This patch is a follow-up to this thread from a few years ago:
https://gcc.gnu.org/ml/gcc/2011-01/msg00093.html
https://gcc.gnu.org/ml/gcc/2011-01/msg00158.html
As noted there, the current definition of ADJUST_REG_ALLOC_ORDER is
obsolete:
(1) This hoo
On 05/09/14 15:14, David Malcolm wrote:
GCC's code is full of references to options like:
static bool
gate_vrp (void)
{
return flag_tree_vrp != 0;
}
where "flag_tree_vrp" is actually an autogenerated macro to:
global_options.x_flag_tree_vrp
This is deeply confusing to a ne
The name suggests that it would be true for any direct initialization,
which is wrong; see TARGET_EXPR_DIRECT_INIT_P (and the similarly wrongly
named DIRECT_INIT_EXPR_P).
Call your macro DIRECT_LIST_INIT_P and it's OK.
Jason
On 05/01/14 15:52, Marc Glisse wrote:
Hello,
here is the latest version. Reviewers seemed happy with different
versions, so I went for the simplest one. We only give up on the
transformation if we are optimizing for speed, the short-cut has
probability >50% and the operation the branch is avoidi
Hi,
On 05/14/2014 08:34 PM, Jason Merrill wrote:
The name suggests that it would be true for any direct initialization,
which is wrong; see TARGET_EXPR_DIRECT_INIT_P (and the similarly
wrongly named DIRECT_INIT_EXPR_P).
Call your macro DIRECT_LIST_INIT_P and it's OK.
A good, thanks. I was a
Jeff Law writes:
> On 05/13/14 14:11, Sandra Loosemore wrote:
>> This patch is a follow-up to this thread from a few years ago:
>>
>> https://gcc.gnu.org/ml/gcc/2011-01/msg00093.html
>> https://gcc.gnu.org/ml/gcc/2011-01/msg00158.html
>>
>> As noted there, the current definition of ADJUST_REG_ALLO
On 04/16/14 05:00, Ilya Enkovich wrote:
Hi,
This patch restarts the series for introducing Pointer Bounds Checker
instrumentation and supporting Intel Memory Protection Extension (MPX)
technology. Detailed description is on GCC Wiki page:
http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20
Failing to rethrow a __forced_unwind exception is very bad.
This patch ensures we rethrow them in async tasks, and makes the
shared state ready with a broken_promise so that waiting threads
don't block forever. That seems reasonable to me, does anyone have any
better ideas?
Tested x86_64-linux,
Can I checkin this testcase fix?
Thanks,
Wei.
On Tue, May 13, 2014 at 1:39 AM, Rainer Orth
wrote:
> Wei Mi writes:
>
>> Thanks for trying the testcase. rtl scanning will be slightly better
>> than assembly scanning. So how about this one?
>
> This one works fine for me.
>
> Thanks.
> R
On 05/14/2014 12:49 PM, Richard Sandiford wrote:
Jeff Law writes:
On 05/13/14 14:11, Sandra Loosemore wrote:
2014-05-13 Catherine Moore
Sandra Loosemore
gcc/
* config/mips/mips.c (mips_order_regs_for_local_alloc): Delete.
* config/mips/mips.h (ADJUST_REG_ALLOC
On Wed, May 14, 2014 at 5:56 AM, Alan Modra wrote:
>> I seem to remember problems in the past with late creation of TOC
>> entries for constants causing problems, so it was easier to fall back
>> to materializing all integer constants inline. I don't remember the
>> PRs, but I think there were is
On Wed, 14 May 2014, Manuel López-Ibáñez wrote:
> Am I missing something?
No, that seems sufficient (together with the observation that the target
handlers remain called after the others, so while there may be such bugs
involving them those bugs are irrelevant to this patch). The patch is OK
I've committed this patch to trunk to fix a cut-and-paste error in the
Nios II backend that we've known about for a while, but we lost track of
getting it fixed. Now mainline nios2 builds have started to fail
because recent changes to rtl innards have added some extra
error-checking that was
This patch partially reverts a change in how a bare -g option was parsed
in a previous commit. Originally, -g would set the debug level to 2
only if debug was off. The previous commit changed that so that -g
would set the debug level to 2 unconditionally. This patch changes
it so that -g sets th
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
http://translationproject.org/latest/gcc/zh_CN.po
(This file, 'gcc-4.9-b2
On 05/14/2014 02:36 PM, Cary Coutant wrote:
> PR debug/61013
> * opts.c (common_handle_option): Don't special-case "-g".
> (set_debug_level): Default to at least level 2 with "-g".
Ok. Thanks,
r~
>> PR debug/61013
>> * opts.c (common_handle_option): Don't special-case "-g".
>> (set_debug_level): Default to at least level 2 with "-g".
>
> Ok. Thanks,
Forgot to ask -- OK to backport to the 4.9 branch?
-cary
On 05/14/2014 02:47 PM, Cary Coutant wrote:
>>> PR debug/61013
>>> * opts.c (common_handle_option): Don't special-case "-g".
>>> (set_debug_level): Default to at least level 2 with "-g".
>>
>> Ok. Thanks,
>
> Forgot to ask -- OK to backport to the 4.9 branch?
Yes please.
r~
Hi,
a common malloc() pattern is "malloc(num_foo * sizeof(foo_t)", that
is, create space for an array of type foo_t with num_foo elements.
There is a slight danger here in that the multiplication can overflow
and wrap around, and then the caller thinks it has a larger array than
what malloc has ac
> 2014-03-20 Eric Botcazou
>
> * config/sparc/sparc.c (sparc_do_work_around_errata): Implement work
> around for store forwarding issue in the FPU on the UT699.
> * config/sparc/sparc.md (in_branch_delay): Return false for single FP
> loads and operations if -mfix-ut699
The toolchain would like PT_GNU_STACK in our objects for all
architectures to make it explicit whether we are requesting an
executable stack or not.
2014-05-14 Kyle McMartin
* config/aarch64/aarch64-linux.h (TARGET_ASM_FILE_END): define
to file_end_indicate_exec_stack for .note
I found a bug in the new std::get(tuple&&) function
where it didn't compile when trying to access reference member.
The rest of this patch simplifies the code in by:
- removing the redundant __add_ref etc. helpers.
- defining a __tuple_element_t alias template.
- removing duplication in the tup
Adds a new __delay_cycles() builtin to the msp430 backend. Committed.
* config/msp430/msp430.c (msp430_builtin): Add
MSP430_BUILTIN_DELAY_CYCLES.
(msp430_init_builtins): Register void __delay_cycles(long long).
(msp430_builtin_decl): Add it.
(cg_magic_cons
On Mon, 2014-03-03 at 09:24 -0800, Richard Henderson wrote:
> On 03/03/2014 04:48 AM, Torvald Riegel wrote:
> > Should I add myself as maintainer for libitm?
>
> Yes.
Committed as r210448.
commit 4da9024845f11053b56aa1318469029b044ff6d1
Author: Torvald Riegel
Date: Thu May 15 00:31:03 2014 +
Hi Andi,
I'll work on putting together some good documentation before sending
this and follow-on support to trunk. As David mentions, the plan for
the subsequent patch to add the hooks that enable users to trigger
gcc's value profiling on particular variables. This first patch simply
allows users
Hello,
libgfortran was happily assuming that STD{IN,OUT,ERR}_FILENO were open
and no error checking was performed on the fstat() call when building
the unit structure for those units. This caused valgrind to complain
when running under MPICH2, which closes stdin for all ranks but rank 0
before lau
Hi All,
AAarch64 back-end defines GENERAL_REGS and CORE_REGS with the same set
of register. Is there any reason why we need this?
target hooks like aarch64_register_move_cost doesnt handle CORE_REGS.
In addition, IRA cost calculation also has logics like make common class
biggest of best and al
Fix grammar error for comments above
process_bb_node_for_hard_reg_moves
Signed-off-by: Zhouyi Zhou
---
gcc/ira-costs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c
index 648806b..fbfb070 100644
--- a/gcc/ira-costs.c
+++ b/gcc/ira-cos
Richard,
Your SYMBOL_REF_FLAGS RTX patches broke bootstrap on AIX.
- David
/nasfarm/edelsohn/src/src/libgcc/libgcc2.c: In function '__eprintf':
/nasfarm/edelsohn/src/src/libgcc/libgcc2.c:2126:1: internal compiler error: RTL
flag check: SYMBOL_REF_FLAGS used with unexpected rtx code 'const' in
rs
I have a release on file with the FSF, but don't have SVN write access.
Problem description:
The existing docs have an @xref in the middle of a sentence, resulting
in weird capitalization and sentence structure:
"This pragma allows the user to set the visibility for multiple
declarations with
1 - 100 of 109 matches
Mail list logo
