From: Thomas Schwinge
libgomp/
* libgomp_g.h: Include for size_t.
---
libgomp/libgomp_g.h | 1 +
1 file changed, 1 insertion(+)
diff --git libgomp/libgomp_g.h libgomp/libgomp_g.h
index 32c4cf6..577956a 100644
--- libgomp/libgomp_g.h
+++ libgomp/libgomp_g.h
@@ -29,6 +29,7 @@
#d
From: Thomas Schwinge
libgomp/
* testsuite/lib/libgomp.exp (libgomp_init): Don't add -fopenmp to
ALWAYS_CFLAGS.
* testsuite/libgomp.c++/c++.exp (ALWAYS_CFLAGS): Add -fopenmp.
* testsuite/libgomp.c/c.exp (ALWAYS_CFLAGS): Likewise.
* testsuite/libgomp
From: Thomas Schwinge
gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): Conditionally define _OPENACC.
gcc/fortran/
* cpp.c (cpp_define_builtins): Conditionally define _OPENACC.
gcc/testsuite/
* c-c++-common/cpp/openacc-define-1.c: Test _OPENACC.
From: Thomas Schwinge
gcc/
* gimplify.c (gimplify_body): Consider flag_openacc additionally
to flag_openmp.
* omp-low.c (execute_expand_omp, execute_lower_omp)
(gate_diagnose_omp_blocks): Likewise.
gcc/testsuite/
* gcc.dg/goacc-gomp/goacc-go
From: Thomas Schwinge
gcc/c-family/
* c.opt (fopenacc): New option.
gcc/fortran/
* lang.opt (fopenacc): New option.
* invoke.texi (-fopenacc): Document it.
* gfortran.h (gfc_option_t): New member.
* options.c (gfc_init_options, gfc_handle_op
Hello!
Attached patch fixes PR 59021, where new vzeroupper instructions are
generated for -mavx after Vlad's useless insn removal patch.
The problem was, that we depent on (useless) moves to AVX256 function
argument registers in front of the function call to switch the mode to
DIRTY mode. This is
Here is the final version of the patch I committed as rev.204465.
It takes Jeff's proposal into account.
The patch was successfully bootstrapped with -flive-range-shrinkage
on x86 and x86-64.
2013-11-06 Vladimir Makarov
* tree-pass.h (make_pass_live_range_shrinkage): New ext
On Wed, Nov 06, 2013 at 08:42:23PM +0100, tho...@codesourcery.com wrote:
> +#define OACC_PARALLEL_CLAUSE_MASK\
> + PRAGMA_OMP_CLAUSE_NONE
This is incorrect, either you should define in c-common.h
also OMP_CLAUSE_MASK_0 and define this to it, or
it needs to be (OMP_CLAUSE_MA
From: Thomas Schwinge
gcc/c-family/
* c-pragma.c (oacc_pragmas): New array.
(c_pp_lookup_pragma, init_pragma): Handle it.
gcc/
* doc/invoke.texi (-fopenacc): Update.
gcc/c/
* c-parser.c (c_parser_omp_all_clauses): Make a parser error
From: Thomas Schwinge
gcc/
* oacc-builtins.def: New file.
* Makefile.in (BUILTINS_DEF): Add oacc-builtins.def.
* builtins.def (DEF_GOACC_BUILTIN): New macro.
Include "oacc-builtins.def".
gcc/fortran/
* f95-lang.c (DEF_GOACC_BUILTIN): New mac
From: Thomas Schwinge
gcc/
* gcc.c (LINK_COMMAND_SPEC, GOMP_SELF_SPECS): For -fopenacc, link
to libgomp and its dependencies.
* config/arc/arc.h (LINK_COMMAND_SPEC): Likewise.
* config/darwin.h (LINK_COMMAND_SPEC_A): Likewise.
* config/i386/mingw32.
> "Jeff" == Jeff Law writes:
Jeff> ISTM that one liner belongs in GCC's .gdbinit. Until then, I'm adding
Jeff> it to my own :-)
Yeah, I think that would be reasonable.
It seems like it isn't appropriate in many cases, so we left it off by
default.
Tom
On 11/06/13 13:01, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
Jeff> ISTM that one liner belongs in GCC's .gdbinit. Until then, I'm adding
Jeff> it to my own :-)
Yeah, I think that would be reasonable.
It seems like it isn't appropriate in many cases, so we left it off by
default.
Here's t
These 4 patches fix libsanitizer build for x32. They will be checked
into upstream:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018#c4
In the meantime, OK to install to unblock x32 build?
Thanks.
H.J.
>From de59975f158501bc99b345c02687944a49c9d31c Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
D
On 11/05/13 16:23, Ian Lance Taylor wrote:
On Tue, Nov 5, 2013 at 2:12 PM, Jeff Law wrote:
I can't speak for Andrew, but my experience with this kind of object type
casting in a large C++ project is that it's a red flag for a design problem.
I'm going to chime in to say that I think it's a p
On Wed, Nov 06, 2013 at 12:37:42PM -0800, H.J. Lu wrote:
> diff --git a/libsanitizer/ChangeLog.x32 b/libsanitizer/ChangeLog.x32
> new file mode 100644
> index 000..7b54005
> --- /dev/null
> +++ b/libsanitizer/ChangeLog.x32
> @@ -0,0 +1,20 @@
Just put it into libsanitizer/ChangeLog, please don'
On 11/06/13 04:02, Bernd Schmidt wrote:
On 11/06/2013 10:31 AM, Richard Biener wrote:
We decided to move to C++. As part of a later discussion we decided
to go with a single general dynamic-casting style, mimicing the "real"
C++ variant which is dynamic_cast < ... >. Which resulted in
is-a.h.
I removed the gccgo branch based on the GCC 4.8 branch, and then
recreated it as a copy of mainline. Future changes to the gccgo
branch will be merged from mainline.
The effect is that the gccgo branch now provides an early snapshot of Go 1.2.
I tagged the former gccgo branch as tags/gccgo-go1_1
On Wed, Nov 06, 2013 at 01:38:23PM -0700, Jeff Law wrote:
> On 11/05/13 16:23, Ian Lance Taylor wrote:
> >On Tue, Nov 5, 2013 at 2:12 PM, Jeff Law wrote:
> >>
> >>I can't speak for Andrew, but my experience with this kind of object type
> >>casting in a large C++ project is that it's a red flag fo
On 11/06/13 04:31, Richard Biener wrote:
On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt wrote:
On 11/06/2013 10:31 AM, Richard Biener wrote:
We decided to move to C++. As part of a later discussion we decided
to go with a single general dynamic-casting style, mimicing the "real"
C++ variant w
On 11/06/2013 06:31 AM, Richard Biener wrote:
On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt wrote:
Maybe we need to revisit it? As one of those who were not in favour of
the C++ move, can I ask you guys to step back for a moment and think
about - what do all of these changes buy us, exactly?
On 11/06/13 04:42, Jakub Jelinek wrote:
On Wed, Nov 06, 2013 at 12:31:00PM +0100, Richard Biener wrote:
Maybe we need to revisit it? As one of those who were not in favour of
the C++ move, can I ask you guys to step back for a moment and think
about - what do all of these changes buy us, exactly
On 11/06/13 06:23, Joseph S. Myers wrote:
On Wed, 6 Nov 2013, Jakub Jelinek wrote:
On Wed, Nov 06, 2013 at 12:31:00PM +0100, Richard Biener wrote:
Maybe we need to revisit it? As one of those who were not in favour of
the C++ move, can I ask you guys to step back for a moment and think
about -
On 11/06/13 02:31, Richard Biener wrote:
We decided to move to C++. As part of a later discussion we decided
to go with a single general dynamic-casting style, mimicing the "real"
C++ variant which is dynamic_cast < ... >. Which resulted in
is-a.h.
So yes, we've decided to go C++ so we have
On 11/06/13 13:56, Andrew MacLeod wrote:
5 - When done we will be significantly closer to having the ability to
create a self contained IL that we can strictly define... That alone
seems a worthwhile goal to me. The IL then becomes appropriate for
streaming at any point in during compilation.
Hello,
It appeared that gcov.c and input.c both have a static function named
read_line. I guess we ought to keep just one.
So I changed the one in input.c as it handles lines with bytes of zero
value (as of the work on PR preprocessor/58580) to make it suitable for
what the uses of read_line in
Ian Lance Taylor writes:
> I removed the gccgo branch based on the GCC 4.8 branch, and then
> recreated it as a copy of mainline. Future changes to the gccgo
> branch will be merged from mainline.
This is probably a silly question, but presuamably bug fixes to the 4.8
gccgo will continue to lan
On Wed, Nov 6, 2013 at 12:45 PM, Jakub Jelinek wrote:
> On Wed, Nov 06, 2013 at 12:37:42PM -0800, H.J. Lu wrote:
>> diff --git a/libsanitizer/ChangeLog.x32 b/libsanitizer/ChangeLog.x32
>> new file mode 100644
>> index 000..7b54005
>> --- /dev/null
>> +++ b/libsanitizer/ChangeLog.x32
>> @@ -0,0
On Wed, Nov 6, 2013 at 1:51 PM, Michael Hudson-Doyle
wrote:
> Ian Lance Taylor writes:
>
>> I removed the gccgo branch based on the GCC 4.8 branch, and then
>> recreated it as a copy of mainline. Future changes to the gccgo
>> branch will be merged from mainline.
>
> This is probably a silly que
On 11/06/13 10:13, Jakub Jelinek wrote:
On Tue, Nov 05, 2013 at 02:00:16PM -0800, Cong Hou wrote:
I'm also curious -- did this code show up in a particular benchmark, if so,
which one?
I didn't find this problem from any benchmark, but from another
concern about loop upper bound estimation. Lo
Richard Biener writes:
> On Sat, Nov 2, 2013 at 3:25 PM, Richard Sandiford
> wrote:
>> Kenneth Zadeck writes:
>>> On 11/02/2013 06:30 AM, Richard Sandiford wrote:
Bah. After all that effort, it turns out that -- by design --
there is one special case where CONST_INTs are not sign-exte
> Attached patch fixes PR 59021, where new vzeroupper instructions are
> generated for -mavx after Vlad's useless insn removal patch.
>
> The problem was, that we depent on (useless) moves to AVX256 function
> argument registers in front of the function call to switch the mode to
> DIRTY mode. Thi
Following the removal of SHIFT_COUNT_TRUNCATED from double-int, this patch
reverts the changed I'd made to mimic the old behaviour on wide-int.
Tested on powerpc64-linux-gnu and by assembly comparison on a range of targets.
OK to install?
Thanks,
Richard
Index: gcc/fold-const.c
On 11/06/13 10:23, Jakub Jelinek wrote:
On Wed, Nov 06, 2013 at 06:13:42PM +0100, Jakub Jelinek wrote:
I've looked at the above testcase to see why we aren't able to determine
the number of iterations upper bound properly here.
And here is a patch that uses get_range_info during # of iteration
On Wed, Nov 6, 2013 at 11:06 PM, Eric Botcazou wrote:
>> Attached patch fixes PR 59021, where new vzeroupper instructions are
>> generated for -mavx after Vlad's useless insn removal patch.
>>
>> The problem was, that we depent on (useless) moves to AVX256 function
>> argument registers in front o
Sorry Dodji,
I still do not see how this is supposed to work:
If the previous invocation of get_line already had read some
characters of the following line(s), how is that information
recovered?
I see it is copied behind lineptr[cur_len].
But when get_line is re-entered, cur_len is set to zero a
This patch makes the shift code in simplify-rtx.c more like the CONST_INT
handling on mainline. There we have:
case LSHIFTRT:
case ASHIFT:
case ASHIFTRT:
/* Truncate the shift if SHIFT_COUNT_TRUNCATED, otherwise make sure
the value is in range. We c
On 11/04/13 08:44, Jakub Jelinek wrote:
I guess short time yes, but I wonder if it wouldn't be better to use
walk_gimple_op and do all changes in the callback. Instead of passing
adjustments pass around a struct containing the adjustments, current stmt
and the modified flag. You can use the val
On 11/05/13 20:22, Diego Novillo wrote:
This is the first patch in a series of patches to cleanup tree.h to
reduce the exposure it has all over the compiler.
[ ... ]
Additionally, the patch removes functions that were never used.
This part should just go forward and should be considered pre-a
After the previous two patches, we can remove the shift truncation
from wide-int.h, which simplifies the interface and makes it behave
more like double_int does now. At the same time I generalised the
rotate code to handle non-power-of-2 widths.
Tested on powerpc64-linux-gnu and by comparing asse
Ping.
Richard Sandiford writes:
> As discussed on gcc@, integer_onep is supposed to return false for
> a nonzero 1-bit value if the type is signed.
>
> Tested on x86_64-linux-gnu and powerpc64-linux-gnu. OK to install?
>
> Thanks,
> Richard
>
>
> Index: gcc/tree.c
> =
Ian Lance Taylor wrote:
On Wed, Nov 6, 2013 at 7:37 AM, Tom Tromey wrote:
Tobias> + cpp_warning (pfile, CPP_W_DATE_TIME, "Macro \"%s\" might prevent
"
Tobias> + "reproduce builds", NODE_NAME (node));
Tobias> + cpp_warning (pfile, CPP_W_DATE_TIME, "Macro \"%s
On 11/05/2013 06:21 PM, Joseph S. Myers wrote:
This patch, relative to trunk and based on work done on the C11-atomic
branch, adds support for C11 _Atomic. It is intended to include all
the required language support.
Thanks for picking this up Joseph... It would have taken me months to do
the
Richard Biener writes:
> --- 599,615
>
> exp = TREE_OPERAND (exp, 0);
> }
>
> + /* We need to deal with variable arrays ending structures. */
> + if (seen_variable_array_ref
> + && maxsize != -1
> + && (!bit_offset.fits_shwi ()
> + || !host_integerp
On 11/02/13 09:50, Jakub Jelinek wrote:
On Sat, Nov 02, 2013 at 08:25:28AM -0500, Aldy Hernandez wrote:
Your patch mangling negative linear steps caused a regression in
simd-clones-2.c. Well, it already had a failure, but now it has two
:).
The problem is that AFAIU, a linear step of 1, is man
The main part of getting avr to work was changing the type used to
handle the insert_bits mask, which went into mainline first. This just
mops up a couple of other problems.
The first two hunks are from still using double_int for fixed-point.
Tested by comparing avr-rtems between the branch and
On Wed, Nov 06, 2013 at 03:24:40PM -0700, Aldy Hernandez wrote:
> I have checked the following patch with the attached testcases that
> were previously ICEing, and with a handful of handcrafted tests that
> I checked manually (array references on lhs and rhs, vectors of
> pointers, etc).
I'd like
On Nov 6, 2013, at 2:33 PM, Oleg Endo wrote:
> I've committed the attached patch as rev 204487.
I doubled checked the patch, all looks good, thanks for the work.
On Nov 6, 2013, at 2:48 PM, Richard Sandiford
wrote:
> The main part of getting avr to work was changing the type used to
> handle the insert_bits mask, which went into mainline first. This just
> mops up a couple of other problems.
> Will say more about the comparison later.
Look forward to
> Please send a patch that adds a testcase to the testsuite to show the
> diagnostics you get after the patch.
How's this?
* c-decl.c (locate_old_decl): If a previous conflicting decl is
both explicit and builtin, print the location of the explicit one.
* gcc.dg/mismatc
I have not looked this in detail, but it looks like the copy right
header of the new file is wrong (including the year).
You should 1) document the command line syntax somewhere, possibly in
comment? 2) add a help command for the tool to dump out help message.
David
On Wed, Nov 6, 2013 at 1:25
On Wed, 6 Nov 2013, DJ Delorie wrote:
> > Please send a patch that adds a testcase to the testsuite to show the
> > diagnostics you get after the patch.
>
> How's this?
>
> * c-decl.c (locate_old_decl): If a previous conflicting decl is
> both explicit and builtin, print the locatio
On my Ubuntu precise system /usr/include/bits is a symlink to
/usr/include/x86_64-linux-gnu/bits. This breaks the fix for fenv.h,
which only looks for bits/fenv.h. The ordering of the directories is
such that x86_64-linux-gnu/bits is handled first, which means that
nothing in bits is handled expl
Thanks! Committed.
The following tests were failing on Aarch64 because the vectorizer was
successfully able to vectorize their loop nests:
FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect
"vectorized 0 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect
"vectorized 0 loops" 1
Appar
This patch is to add another set of multilibs to the mips-mti-* targets. The
new multilibs are for programs compiled and linked with -mfp64 using the
old 32 bit ABI. They are only going to be built for the mips32r2 architecture
in order to reduce the number of new libraries being added.
I also d
On Wed, Nov 6, 2013 at 4:03 PM, Bruce Korb wrote:
> please try to see if just one file name expression is sufficient.
> If one is sufficient, please fix, otherwise, approved.
> But, also, "all active branches", please.
I tried to do that, but I ran into my lack of knowledge of the
fixincludes fra
On 11/06/13 15:48, Jakub Jelinek wrote:
On Wed, Nov 06, 2013 at 03:24:40PM -0700, Aldy Hernandez wrote:
I have checked the following patch with the attached testcases that
were previously ICEing, and with a handful of handcrafted tests that
I checked manually (array references on lhs and rhs, ve
You should be testing aarch64*-*-* so as to match aarch64_be targets.
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 5 Nov 2013, Tobias Burnus wrote:
OK?
Looks good to me, thanks!
Gerald
PS: If I were to nitpick, I'd probably omit the comma before "while".
On Wed, 6 Nov 2013, Rong Xu wrote:
> In current implementation, if you use 'profile-tool help', it will
> print out the usage and exit.
Please make sure you follow the GNU Coding Standards. Any installed tool
needs to support --help, with output following the GNU Coding Standards,
to standard
So what is the big plan here? if you remove it here and then do not
do it in wide int, then it is not going to be truncated.
kenny
On 11/06/2013 05:10 PM, Richard Sandiford wrote:
Following the removal of SHIFT_COUNT_TRUNCATED from double-int, this patch
reverts the changed I'd made to mi
On Wed, Nov 6, 2013 at 4:47 AM, Jonathan Wakely wrote:
> This simply fixes s/boundry/boundary/, which I wanted to do first
> before some more regex refactoring I'm planning.
Thanks a lot Jonathan!
--
Regards,
Tim Shen
On 11/06/13 00:12, Jakub Jelinek wrote:
On Tue, Nov 05, 2013 at 11:15:30PM -0700, Jeff Law wrote:
* java/builtins.c (initialize_builtins): Provide __builtin_trap.
Without java/ ;)
Yes. I was aware of that. I probably should have done
java/
* builtins.c ...
--- a/gcc/ja
2013/11/6 Richard Biener :
> You miss a testcase.
>
> Also why should the warning be omitted for unused automatic
> volatile variables? They cannot be used in any way.
>
> Richard.
Thanks. I've updated the patch with a test case.
c/ChangeLog
PR 57258
* c-decl.c (pop_scope): Don
On Wed, 2013-11-06 at 16:32 +0100, Michael Matz wrote:
> Hi,
>
> On Tue, 5 Nov 2013, David Malcolm wrote:
>
> > Here's a followup patch which ensures that every gimple code has its own
> > subclass, by adding empty subclasses derived from the GSS_-based
> > subclasses as appropriate (I don't both
[ Just a note, of this reply is meant for Michael and other parts for
David, hopefully the audience is clear from the context. ]
On 11/06/13 21:56, David Malcolm wrote:
On Wed, 2013-11-06 at 16:32 +0100, Michael Matz wrote:
Hi,
On Tue, 5 Nov 2013, David Malcolm wrote:
Here's a followup patc
On Wed, Nov 6, 2013 at 3:53 AM, Jakub Jelinek wrote:
> On Tue, Nov 05, 2013 at 01:49:43PM -0800, Evgeniy Stepanov wrote:
>> This way we can't test kernel interfaces that are not used in glibc,
>> like linux aio.
>
> So you just test what you can test. Why do you need to intercept kernel
> aio whe
Hi,
We should use Pmode with stack_pointer_rtx. OK for trunk and 4.8
branch?
Thanks.
H.J.
---
gcc/
2013-11-06 H.J. Lu
PR target/59034
* config/i386/i386.md (push peepholer/splitter): Use Pmode
with stack_pointer_rtx.
gcc/testsuite/
2013-11-06 H.J. Lu
P
Kenneth Zadeck writes:
> So what is the big plan here? if you remove it here and then do not
> do it in wide int, then it is not going to be truncated.
Yeah, that is the big plan for trees. Mainline doesn't truncate at the
tree level after:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg
"Steve Ellcey " writes:
> @@ -40,3 +40,11 @@ MULTILIB_EXCEPTIONS += *mips16/mabi=64*
> MULTILIB_EXCEPTIONS += *mips64*/mmicromips*
> MULTILIB_EXCEPTIONS += *mips32/mmicromips*
> MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*
> +
> +# We do not want nan2008 libraries for soft-float.
> +MULTILIB_EXC
On Thu, Nov 7, 2013 at 1:06 AM, Richard Sandiford
wrote:
> Hi,
>
> "bin.cheng" writes:
>> Index: gcc/tree-ssa-loop-ivopts.c
>> ===
>> --- gcc/tree-ssa-loop-ivopts.c(revision 203267)
>> +++ gcc/tree-ssa-loop-ivopts.c(w
On Thu, Nov 7, 2013 at 11:53 AM, Mingjie Xing wrote:
> 2013/11/6 Richard Biener :
>> You miss a testcase.
>>
>> Also why should the warning be omitted for unused automatic
>> volatile variables? They cannot be used in any way.
>>
>> Richard.
>
> Thanks. I've updated the patch with a test case.
>
On Thu, Nov 7, 2013 at 7:19 AM, H.J. Lu wrote:
> We should use Pmode with stack_pointer_rtx. OK for trunk and 4.8
> branch?
OK everywhere.
Thanks,
Uros.
On Wed, Nov 06, 2013 at 07:48:49PM -0700, Jeff Law wrote:
> * doc/invoke.texi (-fisolate-erroneous-paths): Document.
>
> * gimple-ssa-isolate-paths.c (gate_isolate_erroneous_paths):
> No longer check if we have __builtin_trap, assume it's
> available.
>
> java/
>
> * builtins
> -Original Message-
> From: Ian Lance Taylor [mailto:i...@google.com]
> Sent: Wednesday, November 06, 2013 6:42 PM
> To: Joey Ye
> Cc: gcc-patches; d...@redhat.com; Vladimir Simonov
> Subject: Re: [PATCH] [libiberty] MAX_PATH problems with mingw gcc
Jan, thank you for your attention.
It
101 - 176 of 176 matches
Mail list logo
