On Sat, Nov 8, 2014 at 1:47 PM, Marc Glisse 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
>
> * config/i386/avxintrin.h (__v4
On Sat, Nov 8, 2014 at 1:49 PM, Marc Glisse wrote:
> Hello,
>
> this patch uses &|^ for 128 bit integer vectors. I am doing the operations
> in type __v2du because __builtin_ia32_pand128 was apparently taking __v2di
> arguments, but using __v4su or any other should be equivalent. Even __int128
> w
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 not
> 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 g++.dg/cpp0x/constexpr
2014-11-09 Richard Biener
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
--- a/gcc/testsuite/gcc.target/
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
> emi
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, so
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 boots
Hello,
&|^ of size 256 and 512. Regtested with 6/n.
2014-11-10 Marc Glisse
* 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, _mm512_or_epi32,
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 set
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 door
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 +194,13
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 de
I forgot the 'x' number base specifier in r216034.
Committed as obvious.
2014-11-09 Joern Rennecke
* config/avr/predicates.md (low_io_address_operand): Fix typo.
Index: config/avr/predicates.md
===
--- config/avr/predicates.md (r
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 21
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 commi
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: Likewi
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.
* grap
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 @@
+2014
On Sun, Nov 9, 2014 at 9:56 AM, H.J. Lu 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
> --- a/gcc/tests
Bootstrapped and tested.
Thanks!
--
Regards,
Tim Shen
commit 1cb5f4e018e52d94e4902bd2424b8d5e75d917c2
Author: timshen
Date: Sat Nov 8 18:19:56 2014 -0800
PR libstdc++/63775
* include/bits/regex_compiler.h (_Compiler<>::_M_expression_term,
_BracketMatcher<>::_M_make_r
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
On Sun, Nov 9, 2014 at 8:16 PM, Uros Bizjak 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 necessary (l
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 == 6
On Sun, Nov 9, 2014 at 8:47 AM, Vladimir Makarov 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 necessary (liv
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 d
Ian Taylor 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, but I don't)
> 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
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 implement
On Sat, Nov 8, 2014 at 2:21 AM, Jerry DeLisle wrote:
> On 11/07/2014 02:15 AM, Janne Blomqvist wrote:
>>
>> On Thu, Nov 6, 2014 at 12:38 PM, Janne Blomqvist
>> wrote:
>>>
>>> On Wed, Nov 5, 2014 at 12:48 PM, Janne Blomqvist
>>> wrote:
Hi,
the attached patch fixes a few locale
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 und
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 can
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
Date: Sat Nov 8 09:32:15 2014 -0600
DR 2007
Someone was noticing that whether the result of reinterpret_cast
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
Date: Sat Nov 8 15:35:38
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, app
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 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 willing to accept it? I t
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 (revi
2014-11-09 19:23 GMT+03:00 Joern Rennecke :
> 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, sin
45 matches
Mail list logo
