Hello!
>>> do $subject, and cleanup for always 64 bit hwi.
>>>
>>>
>>> bootstrapped + regtested x86_64-unknown-linux-gnu, ok?
>>
>> Ok. Can you please replace remaining HOST_WIDE_INT
>> vestiges in there with [u]int64_t please?
>
>
> This patch breaks the build on debian 6.0:
>
> ../../gcc/sreal.
Hi,
Dose anybody have time to review this? Thanks.
>
> Hello,
>
> Ping for https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02933.html
>
> Thanks
PING! I am worried if it goes in stage-1.
-Original Message-
From: Gopalasubramanian, Ganesh
Sent: Thursday, October 30, 2014 2:24 PM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH, aarch64] Add prefetch support
Hi,
Below is the patch that implements prefetching support.
This patch has be
On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
> On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
> > On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
> > > To be constructive here - the above case is from within a
> > > GIMPLE_ASSIGN case label
> > > and thus
On Mon, Nov 10, 2014 at 02:43:38PM -0800, Cesar Philippidis wrote:
> >> I'll post a separate patch with the fortran tests later. If anyone
> >> wants to test this patch, please use gomp-4_0-branch instead. You
> >> don't need a CUDA accelerator to use
> >> OpenACC, and some of the runtime tests wil
On Mon, Nov 10, 2014 at 05:36:24PM -0500, Michael Meissner wrote:
> However, the double pattern is completely broken. This cannot go in.
[snip]
> It is unacceptable to have to do the inner loop doing a load, vector add, and
> store in the loop.
Before the patch, the final reduction used *vsx_re
On Mon, Nov 10, 2014 at 05:34:30PM +0300, Ilya Verbin wrote:
> Done, I put them into env vars.
>
> > > +lappend ALWAYS_CFLAGS
> > > "additional_flags=${offload_additional_options}"
> > > }
> >
> > Perhaps add this only if offload_additional_options is non-empty?
>
> Done.
Ok (with appropr
On Mon, Nov 10, 2014 at 05:30:38PM +0300, Ilya Verbin wrote:
> On 06 Nov 19:25, Jakub Jelinek wrote:
> > Oh, one more point, if mic_lib_path is NULL, what is the point
> > to do the alloca/malloc and string copying? Can't you just
> > setenv (MIC_LD_LIBRARY_PATH_ENV, ld_lib_path, 1);
> > in that
Cesar Philippidis wrote:
This patch contains compile-time tests for OpenACC in gfortran. Is this
patch OK for mainline trunk after the OpenACC fortran front end changes
make their way in?
I browsed the test cases – and they look okay. I didn't try hard to see
whether every single one is valid
On Fri, Oct 24, 2014 at 1:55 AM, Richard Biener
wrote:
> On Fri, Oct 24, 2014 at 8:28 AM, wrote:
>> From: Trevor Saunders
>>
>> Hi,
>>
>> do $subject, and cleanup for always 64 bit hwi.
>>
>>
>> bootstrapped + regtested x86_64-unknown-linux-gnu, ok?
>
> Ok. Can you please replace remaining HOS
On 11/10/2014 12:10 PM, Jason Merrill wrote:
On 11/10/2014 10:55 AM, Ed Smith-Rowland wrote:
Would a 4.9 version be accepted?
Sure.
What do you think about defining the macros for unsupported features
to 0 rather than leaving them undefined? The document doesn't seem to
specify.
Jason
This patch refactors the VRP edge-assertion code to make it always
traverse SSA-name definitions in order to find suitable edge assertions
to insert. Currently SSA-name definitions get traversed only when the
LHS of the original conditional is a bitwise AND or OR operation which
seems like a stran
Hi,
This patch tweaks the VRP code to simply inspect the need_assert_for
bitmap when determining whether any asserts need to be inserted.
Consequently we no longer have to manually keep track of whether a call
to register_new_assert_for() was made.
This patch is an updated version of a patch that
On x86_64-apple-darwin14, the attached patch allows gcc trunk to
build against isl 0.14. I assume if we want to retain the...
#if defined(__cplusplus)
extern "C" {
#endif
#if defined(__cplusplus)
}
#endif
wrappers around the include of isl/val_gmp.h, to continue to support
isl 0.12.2, isl.m
Hi Jeff,
I have adapted the code generation part from James' patch to current trunk, and
the resulting patch gets the 30% speedup on coremark and passes bootstrap of
GCC.
Ok for trunk?
Thanks,
Sebastian
Sebastian Pop wrote:
> Sebastian Pop wrote:
> > Jeff Law wrote:
> > > On 08/21/14 04:30, Ri
On Mon, Nov 10, 2014 at 3:56 PM, Cary Coutant wrote:
> Backport pending upstream patch to fix demangler crash.
>
> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html
>
> This patch is for the google/gcc-4_9 branch.
>
> Google ref: 17891596
>
> -cary
OK for Google branches.
Backport pending upstream patch to fix demangler crash.
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html
This patch is for the google/gcc-4_9 branch.
Google ref: 17891596
-cary
2014-05-27 Pedro Alves
include/
* demangle.h (enum demangle_component_type)
: New value.
On Nov 10, 2014, at 2:06 PM, Andreas Tobler wrote:
> another one. Here I'm not really sure if there are EABI variants which do
> _not_ support these test cases.
I think the patch is fine, just watch for any follow-on comments from an
eabi/arm expert. Usually they are pretty responsive.
On Mon, Nov 10, 2014 at 2:27 PM, David Malcolm wrote:
> On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
>> On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
>> > To be constructive here - the above case is from within a
>> > GIMPLE_ASSIGN case label
>> > and thus I'd have exp
Hello!
Now that Vlad fixed the real problem of PR 63620 [1], we can remove
the temporary workaround. The patch also adds the testcase from PR.
2014-11-11 Uros Bizjak
Revert:
2014-10-31 Uros Bizjak
PR target/63620
* config/i386/i386-protos.h (ix86_use_pseudo_pic_reg): Decla
Ping.
On Mon, Oct 6, 2014 at 1:43 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam wrote:
>>> Hi Richard,
>>>
>>> I also ran the gcc testsuite with
>>> RUNTESTFLAGS="--tool_opts=-mcopy
On Tue, Nov 11, 2014 at 3:35 AM, Marek Polacek wrote:
> On Tue, Nov 11, 2014 at 03:24:48AM +0530, Prathamesh Kulkarni wrote:
>> * gcc/c/c-decl.c
>> (warn_cxx_compat_finish_struct): Add new parameter of type location_t.
>> Warn for empty struct.
>> (finish_struct): Pass loc to warn_cxx_comp
On Sun, Nov 02, 2014 at 08:31:43PM +0100, Uros Bizjak wrote:
> Attached (mechanical) patch adds i?86-*-* target to many tests, where
> only x86_64-*-* is listed. Please note that x86_64-*-* already
> included && lp64 for 64bit specific tests due to -m32 multilib
> testing.
>
> 2014-11-02 Uros Biz
On Mon, Nov 10, 2014 at 10:08:54PM +0100, Richard Biener wrote:
> >@@ -662,9 +662,49 @@ func_checker::compare_gimple_call (gimpl
> > t1 = gimple_call_fndecl (s1);
> > t2 = gimple_call_fndecl (s2);
>
> Just drop these and compare gimple_call_fn only.
>
> >+ tree chain1 = gimple_call_chain (s1
On 05/11/14 17:49 +, Jonathan Wakely wrote:
On 5 November 2014 14:14, David Edelsohn wrote:
Jonathan,
I still am seeing new failures in the libstdc++ deque testsuite as of
last night. I don't know if you still are working through the fallout
from the earlier patches, but I wanted to make y
On 10/11/14 23:39 +0100, François Dumont wrote:
No the random tests didn't show any problem. I had demonstrated the
problems with the modifications on the existing tests simulating
constraint memory context.
So unless specified otherwise I will commit tomorrow without the tests
using random n
On 11/10/2014 02:08 PM, Tobias Burnus wrote:
> Cesar Philippidis wrote:
>> This patch adds support for OpenACC 2.0a, with some omissions, to the
>> fortran front end. It only contains the fortran changes from
>> gomp-4_0-branch, therefore the middle end and runtime changes are a
>> necessary prereq
No the random tests didn't show any problem. I had demonstrated the
problems with the modifications on the existing tests simulating
constraint memory context.
So unless specified otherwise I will commit tomorrow without the tests
using random numbers.
François
On 10/11/2014 23:20, Jonatha
On Fri, Oct 24, 2014 at 01:06:41PM +0100, Alan Lawrence wrote:
> This migrates the reduction patterns in altivec.md and vector.md to
> the new names. I've not touched paired.md as I wasn't really sure
> how to fix that (how do I vec_extractv2sf ?), moreover the testing I
> did didn't seem to exerci
On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
> On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
> > To be constructive here - the above case is from within a
> > GIMPLE_ASSIGN case label
> > and thus I'd have expected
> >
> > case GIMPLE_ASSIGN:
> > {
> >
On 10/11/14 23:14 +0100, François Dumont wrote:
I introduced the random tests after Christopher Jefferson request
to have more intensive tests on those algos. Is it the whole stuff of
tests using random numbers that you don't like or just the usage of
mt19937 ?
The use of random number in
I introduced the random tests after Christopher Jefferson request
to have more intensive tests on those algos. Is it the whole stuff of
tests using random numbers that you don't like or just the usage of
mt19937 ? If second is this new version using the usual random_device I
used so far bet
Cesar Philippidis wrote:
This patch adds support for OpenACC 2.0a, with some omissions, to the
fortran front end. It only contains the fortran changes from
gomp-4_0-branch, therefore the middle end and runtime changes are a
necessary prerequisite for this patch.
I'd assume that one could commit
Hi all,
another one. Here I'm not really sure if there are EABI variants which
do _not_ support these test cases.
My target succeeds with this patch.
Comments?
If no (comments), ok for trunk?
TIA,
Andreas
2014-11-10 Andreas Tobler
* g++.old-deja/g++.jason/enum6.C: Use arm_eabi
On Tue, Nov 11, 2014 at 03:24:48AM +0530, Prathamesh Kulkarni wrote:
> * gcc/c/c-decl.c
> (warn_cxx_compat_finish_struct): Add new parameter of type location_t.
> Warn for empty struct.
> (finish_struct): Pass loc to warn_cxx_compat_finish_struct.
>
> * gcc/testsuite/gcc.dg/Wcxx-compat-22.
> Hi!
>
> As the following two testcases shows, there are lots of issues in
> ICF compare_gimple_call, in particular, it doesn't handle indirect calls
> properly (see the ipa-icf-31.c testcase), doesn't handle internal calls
> properly (see ubsan/ipa-icf-1.c), didn't check gimple_call flags at all
[ sorry for dup, if any ]
On Nov 10, 2014, at 1:12 PM, Andreas Tobler wrote:
> As I was told, arm*-*-symbianelf* should be EABI so we can use arm_eabi for
> all instead of listing each OS.
>
> Ok for trunk?
Ok.
Hi,
For the following test-case:
struct A {};
clang -fsyntax-only -Wc++-compat gives following warning and gcc does not:
empty-struct.c:1:1: warning: empty struct has size 0 in C, size 1 in
C++ [-Wc++-compat]
struct F {};
This patch adds the above warning to the C FE.
Bootstrapped on x86_64-unkn
On Nov 10, 2014, at 1:12 PM, Andreas Tobler wrote:
> As I was told, arm*-*-symbianelf* should be EABI so we can use arm_eabi for
> all instead of listing each OS.
>
> Ok for trunk?
Ok.
On Mon, 10 Nov 2014, Richard Biener wrote:
No extra includes required?
is already included in wide-int.h and rtl.h, should probably
move those.
--
Marc Glisse
On 09/11/14 16:00 -0800, Siva Chandra wrote:
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 fin
Tobias Grosser wrote:
On 10.11.2014 20:14, Roman Gareev wrote:
Sure. We should drop the flag in these test cases.
This seems to make sense, as they now test something different and
the flag removal would reflect this.
I personally would include this in the same patch. Would this be
difficult
On 10/11/14 21:50 +0100, François Dumont wrote:
Any news about this one ?
Here is another version with additional random tests on algos just to
challenge other combinations of tests.
PR libstdc++/61107
* include/bits/stl_algo.h (__inplace_stable_partition): Delete.
(__stable_partitio
Ping. I'm getting more reports of this bug internally, and it would be
nice to have the fix upstream.
-cary
On Mon, Oct 13, 2014 at 11:43 AM, Cary Coutant wrote:
> Ping. Jason, do you still think the special-case for conversion ops is
> inappropriate?
>
> -cary
>
>
> On Fri, Jul 25, 2014 at 2:1
Uros reported that my latest patch to fix PR63620 does not fix actually
the problem and H.J. reported that the patch resulted in 2 java test
failures (PR63799).
The following patch fixes PR63620 and PR63799.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
https://gcc.gnu.org/bugzilla/show
On Mon, Nov 10, 2014 at 10:13 PM, Richard Biener
wrote:
> On November 10, 2014 9:13:29 PM CET, Uros Bizjak wrote:
>>Hello!
>>
>>std::swap was recently mentioned in gcc-patches@ mailing list, so I
>>gave it a try. As can be seen below, a lot of code in config/i386
>>benefits from this conversion.
On November 10, 2014 9:13:29 PM CET, Uros Bizjak wrote:
>Hello!
>
>std::swap was recently mentioned in gcc-patches@ mailing list, so I
>gave it a try. As can be seen below, a lot of code in config/i386
>benefits from this conversion.
>
>Surprisingly, I didn't have to include any header on F20 linu
Hi all,
here a second chunk which uses arm_eabi instead of arm*-*-*eabi* and
arm*-*-symbianelf*.
As I was told, arm*-*-symbianelf* should be EABI so we can use arm_eabi
for all instead of listing each OS.
Ok for trunk?
TIA,
Andreas
2014-11-10 Andreas Tobler
* gcc.target/arm/ea
On November 10, 2014 9:45:27 PM CET, Jakub Jelinek wrote:
>Hi!
>
>As the following two testcases shows, there are lots of issues in
>ICF compare_gimple_call, in particular, it doesn't handle indirect
>calls
>properly (see the ipa-icf-31.c testcase), doesn't handle internal calls
>properly (see ubs
Hi!
This patch implements what I understood from Joseph's
https://gcc.gnu.org/ml/gcc/2013-10/msg00280.html
and also adds clang compatible builtins (which implement
small subset of the typegeneric ones).
Besides the clang compatibility builtins, there are 3 new
type-generic builtins, __builtin_{ad
Any news about this one ?
Here is another version with additional random tests on algos just to
challenge other combinations of tests.
PR libstdc++/61107
* include/bits/stl_algo.h (__inplace_stable_partition): Delete.
(__stable_partition_adaptive): Return __first is range length is
Hi!
As the following two testcases shows, there are lots of issues in
ICF compare_gimple_call, in particular, it doesn't handle indirect calls
properly (see the ipa-icf-31.c testcase), doesn't handle internal calls
properly (see ubsan/ipa-icf-1.c), didn't check gimple_call flags at all.
As discus
On Sun, Nov 9, 2014 at 4:57 PM, Marc Glisse wrote:
> 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.
> *
On Nov 10, 2014, at 12:37 PM, H.J. Lu wrote:
> I also checked in this patch to add missing braces in
> gcc.dg/pr44194-1.c.
Thanks.
On Mon, Nov 10, 2014 at 12:04 PM, Jakub Jelinek wrote:
> On Mon, Nov 10, 2014 at 05:19:57PM +0100, Bernd Schmidt wrote:
>> commit 659744a99d815b168716b4460e32f6a21593e494
>> Author: Bernd Schmidt
>> Date: Thu Nov 6 19:03:57 2014 +0100
>
> Note, in r217301 you've committed a change to pr35468.c,
On Mon, Nov 10, 2014 at 12:04 PM, Jakub Jelinek wrote:
> On Mon, Nov 10, 2014 at 05:19:57PM +0100, Bernd Schmidt wrote:
>> commit 659744a99d815b168716b4460e32f6a21593e494
>> Author: Bernd Schmidt
>> Date: Thu Nov 6 19:03:57 2014 +0100
>
> Note, in r217301 you've committed a change to pr35468.c,
On Sun, Nov 9, 2014 at 5:26 PM, Marc Glisse wrote:
> 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
> ret
On Nov 10, 2014, at 12:19 PM, H.J. Lu wrote:
> I checked in this patch to revert the accidental checkin.
Thanks.
fredag 01 augusti 2014 10.52.27 skrev Rainer Orth:
> Hi Magnus,
>
> a couple of comments, mostly nits.
>
> > 2014-07-31 Magnus Granberg
> >
> > /gcc
> > * config/gnu-user.h: Define PIE_DRIVER_SELF_SPECS for PIE
> > as default and GNU_DRIVER_SELF_SPECS.
> > * config/i386/gnu-u
On Mon, Nov 10, 2014 at 12:16 PM, Markus Trippelsdorf
wrote:
> On 2014.11.10 at 12:05 -0800, H.J. Lu wrote:
>> On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf
>> wrote:
>> > On 2014.11.10 at 11:43 -0800, H.J. Lu wrote:
>> >> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek wrote:
>> >> > On
On Tue, Oct 21, 2014 at 8:33 AM, Jeff Law wrote:
> On 10/21/14 14:29, Bernd Schmidt wrote:
>>
>> This tests for availability of return addresses in a number of tests.
>>
>>
>> Bernd
>>
>>
>> r422426.diff
>>
>>
>> gcc/testsuite/
>> * lib/target-supports.exp (check_effective_target_r
On 2014.11.10 at 12:05 -0800, H.J. Lu wrote:
> On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf
> wrote:
> > On 2014.11.10 at 11:43 -0800, H.J. Lu wrote:
> >> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek wrote:
> >> > On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
> >> >>
Hello!
std::swap was recently mentioned in gcc-patches@ mailing list, so I
gave it a try. As can be seen below, a lot of code in config/i386
benefits from this conversion.
Surprisingly, I didn't have to include any header on F20 linux build.
So, is this patch OK as far as c++ is concerned?
2014-
On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf
wrote:
> On 2014.11.10 at 11:43 -0800, H.J. Lu wrote:
>> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek wrote:
>> > On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
>> >> >> > I admit I haven't tried LTO bootstrap, but from norm
On Mon, Nov 10, 2014 at 05:19:57PM +0100, Bernd Schmidt wrote:
> commit 659744a99d815b168716b4460e32f6a21593e494
> Author: Bernd Schmidt
> Date: Thu Nov 6 19:03:57 2014 +0100
Note, in r217301 you've committed a change to pr35468.c, not mentioned in
the ChangeLog, that uses no_const_addr_space e
On 2014.11.10 at 11:43 -0800, H.J. Lu wrote:
> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek wrote:
> > On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
> >> >> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
> >> >> > libcc1 is built normally using libtool
On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek wrote:
> On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
>> >> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
>> >> > libcc1 is built normally using libtool using -fPIC only, and linked into
>> >> > libcc1.so.
On 11/10/2014 1:03 PM, Paolo Carlini wrote:
> Hi,
>
> On 11/10/2014 07:34 PM, Jonathan Wakely wrote:
>> On 10/11/14 12:01 -0600, Joel Sherrill wrote:
>>> cc'ing since both lists should be included.
>>>
>>> The m32c has 24-bit pointers and 16-bit size_t. This changes
>>> pushing a pointer through a
On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener
wrote:
> On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek wrote:
>> On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote:
>>> On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek wrote:
>>> > On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrot
Is the current isl 0.12.2 in infrastructure entirely sufficient
to replace cloog-isl. or should the ABI compatibility changes be made
to graphite to allow gcc 5.0 to be transitioned to the isl 0.14
release? Especially if any graphite changes might be made before the
gcc 5.0 release that could
On 10.11.2014 20:14, Roman Gareev wrote:
Sure. We should drop the flag in these test cases.
This seems to make sense, as they now test something different and the flag
removal would reflect this.
I personally would include this in the same patch. Would this be difficult?
I don’t think that it
On Sun, Nov 09, 2014 at 11:03:50PM -0600, Jason Merrill wrote:
> 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"?
I think "in" was somewhere hard coded in the test suite
and I wanted to m
> Sure. We should drop the flag in these test cases.
>
> This seems to make sense, as they now test something different and the flag
> removal would reflect this.
>
> I personally would include this in the same patch. Would this be difficult?
I don’t think that it could be difficult. I just wanted
On Sun, 9 Nov 2014, Sandra Loosemore wrote:
> Hrmmm. In C, sp->a has type "3-bit unsigned integer" which is promoted to int
> by the integral promotions since all values are representable as int. sp->c
> has type "5-bit unsigned integer" which is likewise promoted to int. In C++,
> sp->a has t
For completeness, this version adds the missing warning if the
'const' is lost in a conditional expression with a void* on the
other branch. The only code change relative to the previous
version is in c/c-typeck.c in build_conditional_expr (otherwise
I added the warnings to the testsuite and fix
On Sat, 8 Nov 2014, Sandra Loosemore wrote:
> I thought that the point at which integral promotions are applied would be a
> good place to catch this, as it excludes places where bit-fields are already
> being converted by assignment or explicit cast. I think we also want to
Formally of course t
Hi,
On 11/10/2014 07:34 PM, Jonathan Wakely wrote:
On 10/11/14 12:01 -0600, Joel Sherrill wrote:
cc'ing since both lists should be included.
The m32c has 24-bit pointers and 16-bit size_t. This changes
pushing a pointer through a size_t to pushing it through a
uintptr_t.
I'm OK with this cha
On Nov 10, 2014, at 10:10 AM, Mike Stump wrote:
> I’’ve asked Jack for the header in question that makes max/min ambiguous.
Ok, found it, page 903 of c++14. Also in the 97 version. We need the wi::
qualifications for wide-int with min and max. That part of the patch is Ok.
On Sat, 8 Nov 2014, Manuel López-Ibáñez wrote:
> This patch is a minor variant of the one approved here:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00246.html
>
> fixing the problem with linker parameters (which are stored in infiles).
>
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00
On Sat, 8 Nov 2014, 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 t
OK.
Jason
Andi Kleen writes:
Ping!
> From: Andi Kleen
>
> xbegin/xend/xabort were missing memory barriers. This can
> lead to memory operations being moved out of transactions, which would
> cause unexpected races.
>
> Always generate implicit memory barriers for these intrinsics.
>
> The compat header v
Andi Kleen writes:
Ping!^3
> Andi Kleen writes:
>
> Ping!^2
>
>> Andi Kleen writes:
>>
>> Ping!
>>
>> Can someone from the C++ side please approve this patch?
>> That's the only patch not approved in this patch kit, but blocking
>> the commit.
>>
>> -Andi
>>
>>> From: Andi Kleen
>>>
>>> Add c
On 09/11/14 01:41 +0100, Marc Glisse wrote:
Hello,
I am digging out https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00637.html
It isn't completely clear if the libstdc++ part was accepted or not. I
won't commit immediately (waiting on another patch), but I'd like to
be ready.
The libstdc++ pa
Roman Gareev writes:
> Hi Tobias,
>
> I've attached a patch which removes using of CLooG library from
> Graphite. Is it fine for trunk?
Could you please also remove -Werror by default from cloog?
Currently with LTO builds warnings in one of these libraries
usually break the build, unless --disa
On 10/11/14 12:01 -0600, Joel Sherrill wrote:
cc'ing since both lists should be included.
The m32c has 24-bit pointers and 16-bit size_t. This changes
pushing a pointer through a size_t to pushing it through a
uintptr_t.
I'm OK with this change if Paolo is.
If it breaks any targets without ui
On 09/11/14 10:17 -0800, Tim Shen wrote:
__matcher._M_add_equivalence_class(_M_value);
else if (_M_match_token(_ScannerT::_S_token_char_class_name))
__matcher._M_add_character_class(_M_value, false);
- else if (_M_try_char()) // [a
+ // POSIX doesn't permit '-' as
Hi again,
thus the below only adds the warnings. Would be mainline only of course.
Thanks!
Paolo.
2014-11-10 Paolo Carlini
* doc/invoke.texi ([-Wshift-count-negative, -Wshift-count-overflow]):
Add.
/c-family
2014-11-10 Paolo Carlini
On Nov 9, 2014, at 12:33 PM, Andreas Tobler wrote:
> The upcoming FreeBSD ARM target does not have eabi in the target triplet. But
> it is EABI based.
> Ok for trunk?
Ok.
On Nov 10, 2014, at 6:58 AM, FX wrote:
>> My knowledge of C++ is limited, but I think this additional patch to
>> wide-int.h is the proper fix to the issue reported by Jack, no?
>> I’m bootstrapping it right now, it already passed stage 2.
>
> Boostrapped succeeded on x86_64-apple-darwin14.
> OK
I checked in this patch to add a testcase for PR tree-optimization/63778.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 217303)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2014-11-10 H.J. Lu
+
+ PR tree-optimiza
cc'ing since both lists should be included.
The m32c has 24-bit pointers and 16-bit size_t. This changes
pushing a pointer through a size_t to pushing it through a
uintptr_t.
--joel
On 11/10/2014 9:36 AM, Joel Sherrill wrote:
> 2014-11-10 Joel Sherrill
>
> * src/c++98/mt_allocator.cc: Fix
Am 2014-11-10 17:06, schrieb David Edelsohn:
> On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner
> wrote:
>>
>> Am 2014-11-07 20:52, schrieb David Edelsohn:
>>> First, please explicitly copy me on AIX or PowerPC patches sent to
>>> gcc-patches.
>>>
>>> I don't have a fundamental objection
Hi,
On 11/10/2014 06:16 PM, Jason Merrill wrote:
On 11/10/2014 12:16 PM, Jason Merrill wrote:
I don't think we want to suppress this warning in general. The problem
in this PR is that the warning code is failing to recognize that the
first operand is constant false.
But adding the warning op
Also confirmed that FX's proposed string.diff patch solves both
PR63699 and PR63750 on x86_64-apple-darwin13 against Xcode 6.1.
On Mon, Nov 10, 2014 at 9:58 AM, FX wrote:
>> My knowledge of C++ is limited, but I think this additional patch to
>> wide-int.h is the proper fix to the issue reported
I don't think we want to suppress this warning in general. The problem
in this PR is that the warning code is failing to recognize that the
first operand is constant false.
Jason
On 11/10/2014 12:16 PM, Jason Merrill wrote:
I don't think we want to suppress this warning in general. The problem
in this PR is that the warning code is failing to recognize that the
first operand is constant false.
But adding the warning options is OK.
Jason
On 11/10/2014 10:55 AM, Ed Smith-Rowland wrote:
Would a 4.9 version be accepted?
Sure.
What do you think about defining the macros for unsupported features to
0 rather than leaving them undefined? The document doesn't seem to specify.
Jason
Hi Renlin,
Looks like Jeff already approved it:
>Can you add a testcase please? With a testcase, this patch is OK for the
>trunk.
Teresa
On Mon, Nov 10, 2014 at 8:59 AM, Renlin Li wrote:
> On 06/11/14 18:07, Renlin Li wrote:
>>
>> On 06/11/14 17:59, Teresa Johnson wrote:
>>>
>>> Thanks for f
On 06/11/14 18:07, Renlin Li wrote:
On 06/11/14 17:59, Teresa Johnson wrote:
Thanks for fixing the test case. Can you also add the comment I
suggested to the source change?
Please add a comment that this is needed due to insane incoming
frequencies.
Sorry, I mistakenly add it to the Change
1 - 100 of 151 matches
Mail list logo
