Hi,
As comments at PR65767 and PR65718, we should use namespace other than std
to avoid duplicated definition problem on arm-none-eabi. This patch fixes
the issue. It is an obvious change, but I will wait for approval because of
GCC5 branch.
Is it OK?
gcc/testsuite/ChangeLog
2015-04-20 Bin Che
On 04/15/2015 03:13 AM, Ramana Radhakrishnan wrote:
On Thu, Mar 5, 2015 at 1:34 PM, Xingxing Pan wrote:
Hi,
The expanding of widen-sum pattern always fails. The vectorizer expects the
operands to have the same size, while the current implementation of
widen-sum pattern dose not conform to this
Gentle reminder!
- Thanks and regards,
Sameera D.
On Monday 30 March 2015 04:58 PM, sameera wrote:
Hi!
Sorry for delay in sending this patch for review.
Please find attached updated patch.
In P5600, 2 consecutive loads/stores of same type which access contiguous
memory locations are bonded
At Fri, 17 Apr 2015 10:53:51 -0600,
Jeff Law wrote:
>
> On 03/05/2015 09:50 AM, Yoshinori Sato wrote:
> > Add h8300-*-linux target for h8300 linux kernel and userland.
> >
> > h8300-*-elf is some difference of standard elf.
> > h8300-*-linux is compatible of standard elf rules.
> >
> > Thanks.
>
On 04/19/2015 03:03 PM, Adam Butcher wrote:
I think I need to resolve a member call within a generic lambda as if it
were not in template context to determine whether it unambiguously
resolves to a static member function. If it does, then no capture
required. Otherwise, 'this' should be capture
On 04/19/2015 07:45 PM, Patrick Palka wrote:
stdarg_p() apparently returns false for a variadic function that has no
concrete parameters, e.g. "void foo (...);". This patch fixes this
issue by removing the predicate's seemingly bogus "n != NULL_TREE" test.
What does this do with K&R non-protot
This patch removes bogus debug info left around by shrink-wrapping,
which on some powerpc targets with just the right register allocation
led to assembly errors.
Bootstrapped and regression tested powerpc64-linux and x86_64-linux.
I did see some regressions, but completely unrelated to this patch.
The attached patch resolves the failures in a number of address
sanitizer tests on powerpc64*-*-*-* discussed in bug 65479 (the
failures in c-c++-common/asan/swapcontext-test-1.c reported in
pr65643 remain unresolved).
The patch has been tested on powerpc64*-*-*-* and x86_64 with
no regressions.
On Wed, 18 Feb 2015, Marek Polacek wrote:
> This is a revised version. I reworded the paragraph dealing with
> __STDC_VERSION__, made some clarifications wrt %a, and added some
> text wrt cpp -P issue.
I made some minor changes on top of this:
- Use a shorter URL for a PR reference.
- Avoid a "he
The followingpatch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805
The problem occurred when SP was changed between the original insn and
rematerialized one and the rematerialized insn contained a reg which
will be substituted by SP. In this case difference between sp offset
and t
stdarg_p() apparently returns false for a variadic function that has no
concrete parameters, e.g. "void foo (...);". This patch fixes this
issue by removing the predicate's seemingly bogus "n != NULL_TREE" test.
(Zero-parameter functions like "void bar (void);" will always have a
void_type_node s
With the patch bootstrapping x86_64-apple-darwin14 was broken due to a typo:
../../work/gcc/config/i386/i386.c: In function 'void
ix86_expand_move(machine_mode, rtx_def**)':
../../work/gcc/config/i386/i386.c:17296:32: error: expected ',' or ';' before
')' token
? op0 : gen_reg_rtx (Pmode));
Hi all,
the attached patch makes it possible to compile and run the failing
avx512* testcases on FreeBSD (amd64).
See the failing testcases:
https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02272.html
The header values.h mentions that this interface is obsolete and one
should use and/or i
On 2015-04-18 18:53, Adam Butcher wrote:
Test like this?
/* { dg-do run { target c++14 } } */
/* { dg-final { scan-assembler-not "..." } } */
struct X
{
int f (int, double) { return 255; }
static int f (int, int) { return 65535; }
auto m1 ()
{
return [=] (auto a) {
return
Hello!
Attached patch removes reload_in_progress checks for x86 (LRA enabled)
target. AFAICS, reload_in_progress is never set during the
compilation, a watchpoint on this variable didn't trigger for a couple
of complex compilations.
2015-04-19 Uros Bizjak
* config/i386/i386.c (set_pic_reg
On Sun, 19 Apr 2015, Ed Smith-Rowland wrote:
I'll need someone to apply this...
Done. (Good timing before the GCC 5.1 release.)
Gerald
2015-02-11 18:18 GMT+00:00 Jiong Wang :
>
> 2015-02-11 Jiong Wang
>
> gcc/
> * loop-invariant.c (find_defs): Enable DF_DU_CHAIN build.
> (vfp_const_iv): New hash table.
> (expensive_addr_check_p): New boolean.
> (init_inv_motion_data): Initialize new variables.
> (free_inv_motion_data)
Hello world,
here is the first installation of the matmul inlining patch.
This patch calculates c=MATMUL(a,b) using DO loops where there is no
dependency between a and c/b and c loops, taking care of realloc on
assignment and bounds checking (using the same error messages that the
library does),
On Sun, Apr 19, 2015 at 10:54:57AM +0300, Yury Gribov wrote:
> On 04/17/2015 08:29 PM, Andi Kleen wrote:
> >Yury Gribov writes:
> >>+
> >>+static bool
> >>+section_sanitized_p (const char *sec)
> >>+{
> >>+ if (!sanitized_sections)
> >>+return false;
> >>+ size_t len = strlen (sec);
> >>+ c
I accidentally added an extra column to the C++14 language stats by
duplicating a column for the SD-6 feature test macros.
This one-liner fixes it.
I'll need someone to apply this...
Sorry.
Ed
? class_key.txt
? help
? patch
? patch_cxx14
? patch_cxx14_2
? patch_cxx14_3
? patch_cxx1y
? patch_
Hello,
while working on pr65792, I noticed that gfc_trans_scalar_assign's
l_is_temp and dealloc flags are used only once, and at the same place.
This patch merges them together.
The calls are changed from
gfc_trans_scalar_assign (...blah..., foo, x, bar);
to
gfc_trans_scalar_assign
Hello,
Le 15/04/2015 20:03, Andre Vehreschild a écrit :
> by accident I patched this pr. For short, when a structure constructor for a
> structure with an allocatable component or a function returning a type with an
> allocatable component is passed as actual argument to a function, then
> gfortr
> Snip
> Both patches have been regression tested on trunk on x86_64-linux.
>
> OK for trunk [first patch]?
> OK for 4.9 and 5 (after the 5.1 release) [second patch]?
>
> Mikael
>
> PS: Dominiq reported that the variant of this patch posted on the PR was
> also fixing PR49324. I couldn't confirm as
On 04/17/2015 08:29 PM, Andi Kleen wrote:
Yury Gribov writes:
+
+static bool
+section_sanitized_p (const char *sec)
+{
+ if (!sanitized_sections)
+return false;
+ size_t len = strlen (sec);
+ const char *p = sanitized_sections;
+ while ((p = strstr (p, sec)))
+{
+ if ((p == san
24 matches
Mail list logo
