On Sat, Nov 8, 2014 at 1:47 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
this patch mechanically extends +-* for integer vectors of size 256 and
512 (the previous patch only handled 128).
Regtested together with the next patch.
2014-11-10 Marc Glisse marc.gli...@inria.fr
On Sat, 8 Nov 2014, Sandra Loosemore wrote:
+ warning_at (EXPR_LOCATION (exp), OPT_Wbitfield_conversion,
+ suggest casting bit-field to its declared type);
I think it would be nice to print this declared type. It can be done
directly in this message, or by adding a note
We had a request from a customer to add a warning to the C front end to
diagnose cases where bit-fields larger than an int are used in shift
expressions; confusingly, the operation is done in the precision of the
bit-field size rather than its declared type. This is a symptom of a larger
This moves the two-conversions-in-a-row foldings from fold_unary to
patterns. This exposed a bug in the genmatch code-gen which failed
to check whether we may follow SSA use-def chains for the outermost
expression operands which is fixed by this patch as well.
I've XFAILed
2014-11-09 Richard Biener rguent...@suse.de
Merge from trunk r217075 through r217260.
Brings back next merge piece.
Tested on powerpc64-suse-linux and committed as obvious.
Andreas.
* gcc.target/powerpc/pr51623.c: Fix implicit declarations.
diff --git a/gcc/testsuite/gcc.target/powerpc/pr51623.c
b/gcc/testsuite/gcc.target/powerpc/pr51623.c
index 2ac118c..0e13463 100644
---
Jack, Dominique,
I think we have two issues here - let's make sure we don't derail dealing with
the first one.
On 8 Nov 2014, at 22:08, Jack Howarth wrote:
That is curious. I wouldn't have thought that the compiler
selection would have had such a radical effect on the linkage flags
At present, I use simplified sshd, ssh and scp (dropbear open source
program) to communicate with microblaze qemu successfully, and let gcc
'make check' have real effect.
It is just testing, at least after almost 10 hours, the log output is
OK. For each ssh login, it will wast 10 - 20 seconds,
Hi Jack,
comments below apply also to the patch for PR63699
On 7 Nov 2014, at 17:13, Jack Howarth wrote:
The attached revised patch eliminates the compilation error...
error: use of undeclared
identifier 'do_not_use_toupper_with_safe_ctype'
on x86_64-apple-darwin14 when
Hello,
|^ of size 256 and 512. Regtested with 6/n.
2014-11-10 Marc Glisse marc.gli...@inria.fr
* config/i386/avx2intrin.h (_mm256_and_si256, _mm256_or_si256,
_mm256_xor_si256): Use vector extensions instead of builtins.
* config/i386/avx512fintrin.h (_mm512_or_si512,
The defaults.h definition of
#define CPLUSPLUS_CPP_SPEC CPP_SPEC
does not do the right thing with the cpp spec picked up from a spec file,
which is now needed for -mmcu processing.
Also, a spec file can't override CPLUSPLUS_CPP_SPEC as such, since
that string is hard-coded into the compiler.
By
Hello,
and == for integer vectors of size 128. I was surprised not to find
_mm_cmplt_epi64 anywhere. Note that I can do the same for size 256, but
not 512, there is no corresponding intrinsic, there are only _mask
versions that return a mask.
For gcc-5, we should stop either after 5/n or
Hi,
r216964 disables bootstrap for libcc1 which exposed 2 things:
1. libcc1 isn't compiled with LTO even when GCC is configured with
--with-build-config=bootstrap-lto. It may be intentional since
libcc1 is disabled for bootstrap.
2. -fPIC isn't used to created libcc1.so, which is OK if libcc1
The following patch solves PR63620. The details can be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
The patch is more than just the problem solution. It adds global live
analysis for pseudos when it is necessary (live info change on a BB
border triggers it). The patch opens a
Iain,
It doesn't look like it will be that simple. If I replace the
proposed patches with a change like...
Index: gcc/system.h
===
--- gcc/system.h(revision 217238)
+++ gcc/system.h(working copy)
@@ -194,6
On 11/09/2014 02:28 AM, Manuel López-Ibáñez wrote:
We had a request from a customer to add a warning to the C front end to
diagnose cases where bit-fields larger than an int are used in shift
expressions; confusingly, the operation is done in the precision of the
bit-field size rather than its
I forgot the 'x' number base specifier in r216034.
Committed as obvious.
2014-11-09 Joern Rennecke joern.renne...@embecosm.com
* config/avr/predicates.md (low_io_address_operand): Fix typo.
Index: config/avr/predicates.md
===
---
Hi Tobias,
I've attached a patch which removes using of CLooG library from
Graphite. Is it fine for trunk?
--
Cheers, Roman Gareev.
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision
On 09.11.2014 18:16, Roman Gareev wrote:
Hi Tobias,
I've attached a patch which removes using of CLooG library from
Graphite. Is it fine for trunk?
The patch looks great. The only piece I think we missed is the
fgraphite-code-generator flag. I would propose to remove it as well in
this
Roman Gareev wrote:
* Makefile.in: Remove the compilation of graphite-clast-to-gimple.o.
* graphite.c: Remove using of CLooG.
* graphite-blocking.c: Likewise.
* graphite-dependences.c: Likewise.
* graphite-poly.c: Likewise.
* graphite-poly.h:
On 09.11.2014 18:35, Tobias Burnus wrote:
Roman Gareev wrote:
* Makefile.in: Remove the compilation of graphite-clast-to-gimple.o.
* graphite.c: Remove using of CLooG.
* graphite-blocking.c: Likewise.
* graphite-dependences.c: Likewise.
* graphite-poly.c: Likewise.
*
Hi,
I checked in this patch to fix buffer overflow in
avx256-unaligned-load-7.c and avx256-unaligned-store-7.c.
H.J.
---
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 0e469f0..e7f0b22 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,10 @@
On Sun, Nov 9, 2014 at 9:56 AM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
I checked in this patch to fix buffer overflow in
avx256-unaligned-load-7.c and avx256-unaligned-store-7.c.
H.J.
---
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 0e469f0..e7f0b22 100644
---
Bootstrapped and tested.
Thanks!
--
Regards,
Tim Shen
commit 1cb5f4e018e52d94e4902bd2424b8d5e75d917c2
Author: timshen tims...@google.com
Date: Sat Nov 8 18:19:56 2014 -0800
PR libstdc++/63775
* include/bits/regex_compiler.h (_Compiler::_M_expression_term,
Hello!
The following patch solves PR63620. The details can be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
The patch is more than just the problem solution. It adds global live
analysis for pseudos when it is necessary (live info change on a BB
border triggers it). The patch
On Sun, Nov 9, 2014 at 8:16 PM, Uros Bizjak ubiz...@gmail.com wrote:
The following patch solves PR63620. The details can be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
The patch is more than just the problem solution. It adds global live
analysis for pseudos when it is
Hi Richard,
On 07.11.14 14:45, Richard Earnshaw wrote:
On 02/11/14 22:11, Andreas Tobler wrote:
Hello all,
this is a patch which brings support for arm*-*-freebsd* to trunk.
The architectures supported are arm-*-*freebsd*, armv6-*-freebsd* and
armv6hf-*-freebsd*.
armv6 stands for ARM_ARCH ==
On Sun, Nov 9, 2014 at 8:47 AM, Vladimir Makarov vmaka...@redhat.com wrote:
The following patch solves PR63620. The details can be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
The patch is more than just the problem solution. It adds global live
analysis for pseudos when it is
Hi,
the subject says it already.
The upcoming FreeBSD ARM target does not have eabi in the target
triplet. But it is EABI based.
Patching these test cases makes them work under arm*-*-freebsd*.
I have not tested them under arm*-*-*eabi*, yet.
If a kind sould could help me out here? Would be
I don't see any regressions in the libjava test suite on
x86_64-apple-darwin14 at r217265 for -m32/-m64 regression testing but
I also have...
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c3
to prevent alias creation on targets that
Ian Taylor i...@golang.org writes:
I don't know what's up with the complex number change. In general the
Go compiler and libraries go to some effort to produce the same
answers on all platforms. We need to understand why we get different
answers on s390 (you may understand the differences,
Well - the best way would be to expose the target specifics to GIMPLE
at some point in the optimization pipeline. My guess would be that it's
appropriate after loop optimizations (but maybe before induction variable
optimization).
That is, have a pass that applies register promotion to
Hello,
Attached is a patch which adds xmethods for the associative containers
(set, map, multiset and multimap) and their unordered versions. I
think the GDB Python API is not rich enough to implement xmethods for
the more interesting methods like find, count etc. The attached patch
only
On Sat, Nov 8, 2014 at 2:21 AM, Jerry DeLisle jvdeli...@charter.net wrote:
On 11/07/2014 02:15 AM, Janne Blomqvist wrote:
On Thu, Nov 6, 2014 at 12:38 PM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
On Wed, Nov 5, 2014 at 12:48 PM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
PR 63748 reports a false-positive uninitialized warning under the
presence of abnormal edges. The statements for which the uninitialized
warnings are emitted all look like:
buf_117(ab) = buf_317(D)(ab);
This PR is similar to PR 57287 which also reports false-positive
uninitialized warnings
I would like to put this patch out before Stage 1 ends even if there is
bikeshed renaming of macros in the next couple weeks as the C++
committee wraps up after their meeting.
The main part of this patch is a __has_cpp_attribute macro.
#if __has_cpp_attribute(foobar)
#else
#endif
In C++ we
On 11/09/2014 08:33 PM, Ed Smith-Rowland wrote:
+ //cpp_hashnode *node = 0;
+ //node = token-val.node.node;
+ //if (node)
+ // pfile-mi_ind_cmacro = node;
Remove this commented-out code?
The patch is OK.
Jason
DR 2007 points out that there's no need to do argument-dependent lookup
for operator=, which has to be a member function.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7601c0b8fb5d7093479f5587057f049bdc6cb622
Author: Jason Merrill ja...@redhat.com
Date: Sat Nov 8 09:32:15 2014 -0600
Someone was noticing that whether the result of reinterpret_castint
was an lvalue or rvalue depended on constant folding. It should always
be an rvalue.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit ff6494228a9bc40c7b78109163054840c1e44855
Author: Jason Merrill ja...@redhat.com
Date:
Warnings are suppressed in these headers by default, but I noticed some
after preprocessing and stripping # lines. A few functions were missing
return types, and _mm256_broadcast_f32x2 was passing a constant value
that overflows the 8-bit type of the parameter.
Tested x86_64-pc-linux-gnu,
On 10/01/2014 11:26 PM, Andi Kleen wrote:
+ if (check_no_cilk (cond, in a condition for a for-loop))
Why is this one in while the others are as?
The patch is OK in any case.
Please ping me directly on C++ patches.
Thanks,
Jason
On 11/08/14 02:20, Manuel López-Ibáñez wrote:
On 7 November 2014 22:39, Joseph Myers jos...@codesourcery.com wrote:
Neither Per nor Tom are active in GCC anymore. If the FE maintainers
do not feel comfortable reviewing line-map changes, could you nominate
Dodji as line-map maintainer if he is
Hi,
This patch adds doloop_end standard pattern for AArch64 port so that
-fmodulo-sched can do its job.
Reg-tested for aarch64-linux-gnu with QEMU. OK for the trunk?
Index: gcc/ChangeLog
===
--- gcc/ChangeLog
2014-11-09 19:23 GMT+03:00 Joern Rennecke joern.renne...@embecosm.com:
The defaults.h definition of
#define CPLUSPLUS_CPP_SPEC CPP_SPEC
does not do the right thing with the cpp spec picked up from a spec file,
which is now needed for -mmcu processing.
Also, a spec file can't override
44 matches
Mail list logo
