On Mon, 13 Jan 2014, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR and on IRC, this testcase is very fragile, counting
> additions with vect_ named SSA_NAME on lhs works only for some tunings,
> for other tunings reassoc width etc. affect it and we can e.g. have
> anonymous SSA_NAMEs on t
On Mon, 13 Jan 2014, Cong Hou wrote:
> I noticed that LIM could not hoist vector invariant, and that is why
> my first implementation tries to hoist them all.
Yes, I filed PR59786 for this. I'll see if I can come up with
a fix suitable for stage3.
> In addition, there are two disadvantages of h
Hi,
The patch fixes two IT issues:
1) IT block is splitted for A15 (and Cortex-M).
For A15 tune, max cond insns (max_insns_skipped) is 2, which is set as the
maximum allowed insns in an IT block (see thumb2_final_prescan_insn). So IT
which has 3 or 4 instructions, will be splitted. Take the first
Hi,
I've been working for some time on the prototype of the Pointer Bounds
Checker which uses function clones for instrumentation
(http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03327.html). After
several experiments with this approach I want to share my results and
ask for some feedback to make a d
On 14/01/14 09:06, Zhenqiang Chen wrote:
> Hi,
>
> The patch fixes two IT issues:
> 1) IT block is splitted for A15 (and Cortex-M).
>
> For A15 tune, max cond insns (max_insns_skipped) is 2, which is set as the
> maximum allowed insns in an IT block (see thumb2_final_prescan_insn). So IT
> which
I've started a separate topic about flaky tsan tests here:
https://groups.google.com/forum/#!topic/thread-sanitizer/KIok3F_b1oI
--kcc
On Fri, Jan 10, 2014 at 7:20 PM, Jakub Jelinek wrote:
> On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
>> On Fri, Jan 10, 2014 at 10:39 AM, Jaku
> FAIL: g++.dg/tsan/default_options.C -O2 execution test
This one looks plain wrong to me. It should be checked for success
instead of failure.
-Y
On 13/01/14 16:16, Tom de Vries wrote:
> On 10-01-14 12:39, Richard Earnshaw wrote:
>> Consequently, you'll need to add a patch for AArch64 which has two
>> registers clobbered by PLT-based calls.
>>
Thanks for pointing that out. That's r16 and r17, right? I can propose the
>
Uros Bizjak wrote:
> The same tsan failures are reported in one of HJ's testers [2], with message:
Can this be duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 ?
-Y
On 14/01/14 01:49, Andrew Pinski wrote:
> Hi,
> While writing a scheduler for Cavium's aarch64 processor (Thunder),
> I found there was no way currently to change the issue rate in
> back-end. This patch adds a field (issue_rate) to tune_params and
> creates a new function that the middle-end ca
While experimenting with a patch to use conditional returns, I hit a case
where a conditional jump between hot and cold sections was being converted
into a conditional return. The new jump still had the REG_CROSSING_JUMP
and later passes were confused by the combination of that and a return
JUMP_L
On Tue, 14 Jan 2014, Richard Biener wrote:
> On Mon, 13 Jan 2014, Cong Hou wrote:
>
> > I noticed that LIM could not hoist vector invariant, and that is why
> > my first implementation tries to hoist them all.
>
> Yes, I filed PR59786 for this. I'll see if I can come up with
> a fix suitable fo
On Tue, Jan 14, 2014 at 10:15 AM, Ilya Enkovich wrote:
> Hi,
>
> I've been working for some time on the prototype of the Pointer Bounds
> Checker which uses function clones for instrumentation
> (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03327.html). After
> several experiments with this approa
Ping~
Originally posted here:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00185.html
Thanks,
Yufeng
On 01/06/14 12:30, Yufeng Zhang wrote:
This patch fixes the implementation of vcvtmd_s64_f64 and vcvtpd_s64_f64
in arm_neon.h to use llfloor and llceil instead, which are ILP32-friendly.
This
On 6 January 2014 12:30, Yufeng Zhang wrote:
> This patch fixes the implementation of vcvtmd_s64_f64 and vcvtpd_s64_f64 in
> arm_neon.h to use llfloor and llceil instead, which are ILP32-friendly.
>
> This patch will fix the following test failure in the ILP32 mode:
>
> FAIL: gcc.target/aarch64/ve
2014/1/14 Richard Biener :
> On Tue, Jan 14, 2014 at 10:15 AM, Ilya Enkovich
> wrote:
>> Hi,
>>
>> I've been working for some time on the prototype of the Pointer Bounds
>> Checker which uses function clones for instrumentation
>> (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03327.html). After
>
On Tue, Jan 14, 2014 at 10:01:06AM +0100, Richard Biener wrote:
> Jakub, adding the new flag is ok with me.
So like this?
2014-01-14 Jakub Jelinek
* tree-vectorizer.h (struct _loop_vec_info): Add no_data_dependencies
field.
(LOOP_VINFO_NO_DATA_DEPENDENCIES): Define.
On Tue, 14 Jan 2014, Jakub Jelinek wrote:
> On Tue, Jan 14, 2014 at 10:01:06AM +0100, Richard Biener wrote:
> > Jakub, adding the new flag is ok with me.
>
> So like this?
Ok if it passes testing.
Thanks,
Richard.
> 2014-01-14 Jakub Jelinek
>
> * tree-vectorizer.h (struct _loop_vec_i
This fixes the slowness seen in LCM compute_available accounted
to RTL cprop. Currently the dataflow problem uses a "random"
basic-block order to seed the initial worklist (it wants to
visit predecessors before successors) - the following patch
makes it use inverted postorder (similar to tree PRE
Hi all,
I'm looking into PR 54168 where we end up generating an unnecessary extend
operation on arm.
Given code:
struct b2Body {
unsigned short flags;
int type;
};
static _Bool IsAwake(struct b2Body *b)
{
return (b->flags & 2) == 2;
}
int foo(struct b2Body *bA, struct b2Body *
On Tue, Jan 14, 2014 at 1:47 PM, Ilya Enkovich wrote:
> 2014/1/14 Richard Biener :
>> On Tue, Jan 14, 2014 at 10:15 AM, Ilya Enkovich
>> wrote:
>>> Hi,
>>>
>>> I've been working for some time on the prototype of the Pointer Bounds
>>> Checker which uses function clones for instrumentation
>>> (h
On Tue, Jan 14, 2014 at 3:03 PM, Kyrill Tkachov wrote:
> Hi all,
>
> I'm looking into PR 54168 where we end up generating an unnecessary extend
> operation on arm.
>
> Given code:
>
> struct b2Body {
> unsigned short flags;
> int type;
> };
>
> static _Bool IsAwake(struct b2Body *b)
> {
>
Hi,
There are several problems with i386 MMX/SSE/AVX ABI change detection:
1. MMX/SSE return value isn't checked for -m32 since revision 83533:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=83533
which added ix86_struct_value_rtx. Since MMX/SSE condition is always
false, the MMX/SSE re
Moving to gcc, I accidentally sent it to gcc-patches previously...
On 14/01/14 14:09, Richard Biener wrote:
On Tue, Jan 14, 2014 at 3:03 PM, Kyrill Tkachov wrote:
Hi all,
I'm looking into PR 54168 where we end up generating an unnecessary extend
operation on arm.
Given code:
struct b2Body {
On Tue, Jan 14, 2014 at 3:21 PM, Kyrill Tkachov wrote:
> Moving to gcc, I accidentally sent it to gcc-patches previously...
>
>
> On 14/01/14 14:09, Richard Biener wrote:
>>
>> On Tue, Jan 14, 2014 at 3:03 PM, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>> I'm looking into PR 54168 where we end
On 01/14/14 06:42, Richard Biener wrote:
This fixes the slowness seen in LCM compute_available accounted
to RTL cprop. Currently the dataflow problem uses a "random"
basic-block order to seed the initial worklist (it wants to
visit predecessors before successors) - the following patch
makes it
On Tue, Jan 14, 2014 at 02:21:52PM +, Kyrill Tkachov wrote:
> If I look at the dump before forwprop, the number of statements is
> exactly the same, so it's not any shorter in that sense.
>
>
> IsAwake (struct b2Body * b)
> {
> short unsigned int _3;
> int _4;
> int _5;
> _Bool _6;
>
On 01/14/14 03:37, Richard Sandiford wrote:
While experimenting with a patch to use conditional returns, I hit a case
where a conditional jump between hot and cold sections was being converted
into a conditional return. The new jump still had the REG_CROSSING_JUMP
and later passes were confused
On 14/01/14 14:25, Richard Biener wrote:
> On Tue, Jan 14, 2014 at 3:21 PM, Kyrill Tkachov
> wrote:
>> Moving to gcc, I accidentally sent it to gcc-patches previously...
>>
>>
>> On 14/01/14 14:09, Richard Biener wrote:
>>>
>>> On Tue, Jan 14, 2014 at 3:03 PM, Kyrill Tkachov
>>> wrote:
2014/1/14 Richard Biener :
> On Tue, Jan 14, 2014 at 1:47 PM, Ilya Enkovich wrote:
>> 2014/1/14 Richard Biener :
>>> On Tue, Jan 14, 2014 at 10:15 AM, Ilya Enkovich
>>> wrote:
Hi,
I've been working for some time on the prototype of the Pointer Bounds
Checker which uses functi
The C++ part is OK.
Jason
On 9 January 2014 21:55, François Dumont wrote:
> Hi
>
> Here is a patch for this small problem with clang. It is not a blocking
> issue for the 4.9 release but at the same time it is a rather safe fix so
> just tell me if I can commit it.
>
> All unordered_* tests run under Linux x86_64. I
On 14/01/14 14:32, Jakub Jelinek wrote:
> Anyway, the above is really a simple case, and I'd call it a
> backend bug if it isn't able to generate good code out of that.
Exactly which back-end pass are you expecting to simplify
(set (subreg:SI (reg:HI 1) 0) (and:SI (subreg:SI (reg:HI 0) 0)
(const_
This resolves a bootstrap issue found after reducing the size of the maximal
wide_int; the real code really does want a slightly larger type so we create on
just for real.
Ok?
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 81bb407..f4ffdb0 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@
Hi!
Here is a patch series that adds initial support for OpenACC data
clauses. It is not yet complete, but I thought I might as well already
now strive to get this integrated upstream instead of "hoarding" the
patches locally.
Would it be a good idea to also commit to trunk the (portions of the)
From: Thomas Schwinge
gcc/c/
* c-parser.c (c_parser_oacc_all_clauses): New function.
(c_parser_oacc_parallel): Use it.
* c-typeck.c (c_finish_omp_clauses): Update comment. Remove
duplicated variable initialization.
---
gcc/c/c-parser.c | 59 ++
From: Thomas Schwinge
gcc/c-family/
* c-pragma.h (pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_COPY,
PRAGMA_OMP_CLAUSE_COPYOUT, PRAGMA_OMP_CLAUSE_CREATE,
PRAGMA_OMP_CLAUSE_DELETE, PRAGMA_OMP_CLAUSE_DEVICEPTR,
PRAGMA_OMP_CLAUSE_PRESENT, PRAGMA_OMP_CLAUSE_PRESEN
From: Thomas Schwinge
gcc/
* tree-core.h (omp_clause_map_kind): Make the identifiers' bit
patterns more obvious. Add comments.
* omp-low.c (lower_oacc_parallel, lower_omp_target): Test for
omp_clause_map_kind flags set instead of for values.
---
gcc/omp-l
From: Thomas Schwinge
gcc/c/
* c-parser.c (OACC_PARALLEL_CLAUSE_MASK): Add
PRAGMA_OMP_CLAUSE_COPY, PRAGMA_OMP_CLAUSE_COPYIN,
PRAGMA_OMP_CLAUSE_COPYOUT, PRAGMA_OMP_CLAUSE_CREATE,
PRAGMA_OMP_CLAUSE_DEVICEPTR, PRAGMA_OMP_CLAUSE_PRESENT,
PRAGMA_OMP_CLAU
From: Thomas Schwinge
gcc/
* tree-core.h (omp_clause_map_kind): Add OMP_CLAUSE_MAP_FORCE,
OMP_CLAUSE_MAP_FORCE_ALLOC, OMP_CLAUSE_MAP_FORCE_TO,
OMP_CLAUSE_MAP_FORCE_FROM, OMP_CLAUSE_MAP_FORCE_TOFROM,
OMP_CLAUSE_MAP_FORCE_PRESENT, OMP_CLAUSE_MAP_FORCE_DEALLOC
From: Thomas Schwinge
gcc/
* gimplify.c (gimplify_call_expr, gimplify_modify_expr)
(omp_firstprivatize_variable, omp_notice_threadprivate_variable)
(omp_notice_variable, gimplify_adjust_omp_clauses)
(gimplify_omp_workshare): Treat ORT_TARGET as a flag, not
On 14/01/14 14:49, Richard Earnshaw wrote:
> On 14/01/14 14:32, Jakub Jelinek wrote:
>> Anyway, the above is really a simple case, and I'd call it a
>> backend bug if it isn't able to generate good code out of that.
>
> Exactly which back-end pass are you expecting to simplify
>
> (set (subreg:SI
Hi Sterling,
The xtensa backend uses register windows, and we need to define
LOCAL_REGNO for it.
The dataflow may not be accurate with this macro. This patch
passed the cases in testsuite/gcc.c-torture/execute dir.
Please apply it if OK for trunk. Thanks.
Index: gcc/ChangeLog
Hi,
This patch turns off the vec_perm patterns for aarch64_be, this should
resolve
the issue highlighted here
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00321.html
With this patch applied, the test case provided in that link compiles
without an ICE.
However, the Big-Endian port is still i
Hi Sterling,
I found that we can avoid emitting excessive literal loading
instructions with with section anchors.
This patch also passed the cases in testsuite/gcc.c-torture/execute/ dir.
Please apply it if OK for trunk.
Index: gcc/ChangeLog
Mike Stump writes:
> diff --git a/gcc/expmed.c b/gcc/expmed.c
> index ce063eb..720d8c1 100644
> --- a/gcc/expmed.c
> +++ b/gcc/expmed.c
> @@ -4963,6 +4963,7 @@ make_tree (tree type, rtx x)
>return t;
>
> case CONST_DOUBLE:
> + gcc_assert (HOST_BITS_PER_WIDE_INT * 2 <= MAX_BITSI
> On Jan 14, 2014, at 7:19 AM, Alex Velenko wrote:
>
> Hi,
>
> This patch turns off the vec_perm patterns for aarch64_be, this should resolve
> the issue highlighted here
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00321.html
> With this patch applied, the test case provided in that link
On Tue, Jan 14, 2014 at 02:49:30PM +, Richard Earnshaw wrote:
> On 14/01/14 14:32, Jakub Jelinek wrote:
> > Anyway, the above is really a simple case, and I'd call it a
> > backend bug if it isn't able to generate good code out of that.
>
> Exactly which back-end pass are you expecting to simp
On Sun, Jan 12, 2014 at 10:02 PM, Kirill Yukhin wrote:
> Hello,
> On 11 Jan 12:42, Uros Bizjak wrote:
>> On Fri, Jan 10, 2014 at 5:24 PM, Jakub Jelinek wrote:
>> > This means you should ensure aligned_mem will be set for
>> > CODE_FOR_avx512f_movntdqa in ix86_expand_special_args_builtin.
> Fixed.
On Tue, Jan 14, 2014 at 3:18 PM, H.J. Lu wrote:
> There are several problems with i386 MMX/SSE/AVX ABI change detection:
>
> 1. MMX/SSE return value isn't checked for -m32 since revision 83533:
>
> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=83533
>
> which added ix86_struct_value_rtx.
Hi Guys,
Several PRs (28865, 57180 and 59719) have reported that the assembler
directives emitted by gcc to describe a structure with a variable
length field occupy too much space. That is a serious problem for
targets which use section anchors as they rely upon objects in the
data area
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787
The problem of LRA looping was in that address with soft frame pointer
was rejected as valid constraint in iwmmxt_amd_movdi insn.
Ok to commit?
2014-01-14 Vladimir Makarov
PR target/59787
* confi
On Tue, Jan 14, 2014 at 7:20 AM, Felix Yang wrote:
> Hi Sterling,
>
> I found that we can avoid emitting excessive literal loading
> instructions with with section anchors.
> This patch also passed the cases in testsuite/gcc.c-torture/execute/ dir.
> Please apply it if OK for trunk.
Hi Feli
Hi!
In the buildrobot's logs for building with config-list.mk, I noticed
this warning:
g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-
On Tue, Jan 14, 2014 at 7:14 AM, Felix Yang wrote:
> Hi Sterling,
>
> The xtensa backend uses register windows, and we need to define
> LOCAL_REGNO for it.
Hi Felix,
How does this change the produced code? In particular, please identify
a problem this patch is solving. I know that the docume
On Fri, Jan 03, 2014 at 05:04:39PM +0100, Uros Bizjak wrote:
> On a second thought, the crossing of 16-byte boundaries is mentioned
> for the data *access* (the instruction itself) if it is not naturally
> aligned (please see example 3-40 and fig 3-2), which is *NOT* in our
> case.
>
> So, we don'
The mainline fix for PR58139 which is a wrong code gen bug was
submitted here:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00910.html
and approved for mainline and 4.8 (after a few weeks) here:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00134.html
However, my fix exposed a latent x86
Hi Vladimir,
I have test your patch with the following configurations, , and it
indeed eliminates the ICE.
--target=arm-none-linux-gnueabihf
--with-arch=armv7-a
--with-fpu=vfpv3-d16
--with-float=softfp
Thank you!
Kind regards,
Renlin Li
On 14/01/14 16:48, Vladimir Makarov wrote:
The fol
On 01/13/2014 09:48 PM, Marek Polacek wrote:
+bool
+pointer_to_zero_sized_aggr_p (tree t)
+{
+ t = strip_pointer_operator (t);
+ if (RECORD_OR_UNION_TYPE_P (t)
+ && TYPE_SIZE (t)
+ && integer_zerop (TYPE_SIZE (t)))
+return true;
+ return false;
+}
I think you can just return th
On 14/01/14 16:48, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787
>
> The problem of LRA looping was in that address with soft frame pointer
> was rejected as valid constraint in iwmmxt_amd_movdi insn.
>
> Ok to commit?
>
> 2014-01-
On 14/01/14 16:48, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787
>
> The problem of LRA looping was in that address with soft frame pointer
> was rejected as valid constraint in iwmmxt_amd_movdi insn.
>
> Ok to commit?
>
> 2014-01-
On Tue, Jan 14, 2014 at 6:09 PM, Jakub Jelinek wrote:
>> On a second thought, the crossing of 16-byte boundaries is mentioned
>> for the data *access* (the instruction itself) if it is not naturally
>> aligned (please see example 3-40 and fig 3-2), which is *NOT* in our
>> case.
>>
>> So, we don'
> A quick grep of the arm backend shows 11 instances of reload_in_progress:
>
> arm.c: && !(reload_in_progress || reload_completed)
> arm.c: if (! (reload_in_progress || reload_completed)
> arm.c: if (! (reload_in_progress || reload_completed)
> arm.c: if (! (reload_in_progress || reload_co
On Tue, Jan 14, 2014 at 10:37 AM, Uros Bizjak wrote:
> On Tue, Jan 14, 2014 at 6:09 PM, Jakub Jelinek wrote:
>
>>> On a second thought, the crossing of 16-byte boundaries is mentioned
>>> for the data *access* (the instruction itself) if it is not naturally
>>> aligned (please see example 3-40 an
On 01/14/2014 01:41 PM, Yvan Roux wrote:
>> A quick grep of the arm backend shows 11 instances of reload_in_progress:
>>
>> arm.c: && !(reload_in_progress || reload_completed)
>> arm.c: if (! (reload_in_progress || reload_completed)
>> arm.c: if (! (reload_in_progress || reload_completed)
>>
On 01/14/2014 12:22 PM, Peter Bergner wrote:
> The mainline fix for PR58139 which is a wrong code gen bug was
> submitted here:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00910.html
>
> and approved for mainline and 4.8 (after a few weeks) here:
>
> http://gcc.gnu.org/ml/gcc-patches/2
On Tue, Jan 14, 2014 at 07:37:33PM +0100, Uros Bizjak wrote:
> OK, let's play safe. I'll revert these two changes (modulo size of
> nocona prefetch block).
Thanks.
> > opt we never return a smaller number from ix86_data_alignment than
> > we did in 4.8 and earlier, because otherwise if you have 4
Thanks for the hint Vladimir, I'll pass some validation on arm.c and
arm.md/aarch64.md separately.
On 14 January 2014 20:09, Vladimir Makarov wrote:
> On 01/14/2014 01:41 PM, Yvan Roux wrote:
>>> A quick grep of the arm backend shows 11 instances of reload_in_progress:
>>>
>>> arm.c: && !(re
On 12/05/2013 07:47 PM, Tom de Vries wrote:
> On 14-03-13 10:34, Tom de Vries wrote:
>>> I thought about implementing your optimization for LRA by myself.
>>> But it
>>> >is ok if you decide to work on it. At least, I am not going to start
>>> >this work for a month.
>>I'm also currently look
On Thu, Jan 9, 2014 at 6:56 AM, Jan Hubicka wrote:
>> As suggested by Honza, avoid bloating libgcov from gcc_assert by using
>> a new macro gcov_nonruntime_assert in gcov-io.c that is only mapped to
>> gcc_assert when not in libgcov.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok fo
On Mon, Jan 13, 2014 at 6:37 PM, Bill Schmidt
wrote:
> This patch provides for interpreting parity of element numbers for the
> Altivec vec_mule and vec_mulo intrinsics as big-endian (left to right in
> a vector register) when targeting a little endian machine and specifying
> -maltivec=be. New t
This patch fixes a problem where the attribute no_instrument_function
was being ignored and profile code was emitted. Testcase
gcc.target/powerpc/ppc64-abi-2.c exposed the issue.
Bootstrap/regtest with no new regressions, ok for trunk?
-Pat
2014-01-13 Pat Haugen
* config/rs6000/r
On Mon, 13 Jan 2014, Jakub Jelinek wrote:
> This patch fixes the following testcase by preevaluating rhs if it has
> (can have) side-effects in lhs op= rhs expressions. Bootstrapped/regtested
> on x86_64-linux and i686-linux, ok for trunk?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 13 Jan 2014, Marek Polacek wrote:
> +/* Return true if T is a pointer to a zero-sized struct/union. */
> +
> +bool
> +pointer_to_zero_sized_aggr_p (tree t)
> +{
> + t = strip_pointer_operator (t);
> + if (RECORD_OR_UNION_TYPE_P (t)
> + && TYPE_SIZE (t)
> + && integer_zerop (TY
On Tue, Jan 14, 2014 at 3:42 PM, Pat Haugen wrote:
> This patch fixes a problem where the attribute no_instrument_function was
> being ignored and profile code was emitted. Testcase
> gcc.target/powerpc/ppc64-abi-2.c exposed the issue.
>
> Bootstrap/regtest with no new regressions, ok for trunk?
>
This patch from Chris Manghane adds a Backend_function_type: a function
type that is implemented as a function pointer rather than as the
pointer to a struct that is the implementation of a Go function. This
will be used in other backend conversions. Bootstrapped and ran Go
testsuite on x86_64-un
While writing the Thunder tunings, I got an internal compiler error
while building glibc. The reduced testcase is:
typedef unsigned int size_t;
typedef unsigned int wchar_t;
extern __thread int __libc_errno;
extern __thread int * t;
int _IO_vfprintf_internal (char *string, char *workend
This Go frontend patch from Chris Manghane uses the backend interface
for interface info and field expressions. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2014-01-14 Chris Manghane
* go-gcc.cc (Gcc_backend::compound_expression): New fu
This patch fixes what appears to have been a long standing failure in
the conversion of tree-vect-generic.c:build_replicated_const. This
failure caused several regressions on the branch.
Committed as revision 206616
Index: gcc/tree-vect-generic.c
On Tue, Jan 14, 2014 at 06:18:22AM -0800, H.J. Lu wrote:
> 2014-01-14 H.J. Lu
>
> PR target/59794
> * config/i386/i386.c (type_natural_mode): Add a bool parameter
> to indicate if type is used for function return value. Warn
> ABI change if the vector mode isn't availab
80 matches
Mail list logo
