I have committed the attached test case as Rev. 212220. The problem
popped up with the MPI version of the library. The race came apparent
with Open MPI 1.8 (but not 1.7) which shows how the one-sided
communication in Open MPI improved with 1.8 …
Tobias
Index: gcc/testsuite/ChangeLog
On Mon, May 5, 2014 at 8:21 AM, bin.cheng bin.ch...@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent: Thursday, May 01, 2014 10:03 PM
To: Bin Cheng
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH ARM]Handle REG addressing mode in
output_move_neon explicitly
On
Hi,
this patch adds predicate contains_polymorphic_type_p. This can be used
in the ICF pass - if one of the types is contains_polymorphic_type_p,
then TYPE_MAIN_VARIANTs of both types should be the same, at least for
now. Of course it would be possible to compare types for equality and then
also
Hi!
As the testcase shows, we ICE on old style initialization of derived type
components. ifort also rejects these, I think it doesn't make sense to
support such initializations of derived type components.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.9?
2014-07-02
On 01-07-14 21:47, Jeff Law wrote:
On 07/01/14 13:27, Tom de Vries wrote:
So my question is: is the combination of '' and '+' supported ? If so,
what is the exact semantics ? If not, should we warn or give an error ?
I don't think we can define any reasonable semantics for +. My
Hi,
It seems some of the scan-assembler directives fail:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/trunk/212196/aarch64-none-elf/diff-gcc-rh50-aarch64-none-elf-default-default-default.txt
Christophe.
On 1 July 2014 14:13, Marcus Shawcroft marcus.shawcr...@gmail.com wrote:
On 02/07/14 08:59, Christophe Lyon wrote:
Hi,
It seems some of the scan-assembler directives fail:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/trunk/212196/aarch64-none-elf/diff-gcc-rh50-aarch64-none-elf-default-default-default.txt
Hi Christophe
Yes, turns out removing the
On 02-07-14 08:23, Marc Glisse wrote:
In the first example you gave, looking at the pattern (no match_dup, setting the
full register), it seems that it may have wanted = instead of +.
[ move discussion from gcc ml to gcc-patches ml ]
Marcus,
The + constraint on operand 0 of
Hi!
Most of this probably doesn't need explanation, just the
expand_sdiv_pow2 change - shift_cost only tracks shift counts to
MAX_BITS_PER_WORD (but, for consistency between e.g. i?86 and x86_64 -m32
we'd better use BITS_PER_WORD instead as in most other expmed.c places),
when called with larger
This change is necessary to support Cortex-R based chips in RTEMS.
This patch should be applied to GCC 4.8, 4.9 and mainline. I do not
have write access, so in case this gets approved, please commit it for
me.
gcc/ChangeLog
2014-07-02 Sebastian Huber sebastian.hu...@embedded-brains.de
The whole point of using _PRECISION is to have the size be exactly the
same as the mode (bitsize is bigger than the mode for partial-int
modes). TYPE_SIZE_UNIT should be its storage size, right? If the
type is not a multiple of BITS_PER_UNIT, the actual size and
stored-in-memory size are
So in order to known whether it's safe and optimal to use regs_ever_live
instead, the question is whether the passes after pass_free_cfg (are allowed
to) add or remove sets or clobbers of call_really_used_regs. I don't know
the full answer there.
pass_machine_reorg is run after pass_free_cfg
Hello,
I would like to announce creation of a dedicated branch gomp4-offload to speed
up review of FE-independent offload-related features.
This branch includes:
- set of necessary patches from gomp4 branch
- set of patches which we were developed internally and were unable to
share
Hello,
I would like to announce creation of a dedicated branch gomp4-offload to speed
up review of FE-independent offload-related features.
This branch includes:
- set of necessary patches from gomp4 branch
- set of patches which we were developed internally and were unable to
share
Jakub Jelinek wrote:
As the testcase shows, we ICE on old style initialization of derived type
components. ifort also rejects these, I think it doesn't make sense to
support such initializations of derived type components.
Side remark: Cray ftn also rejects it, while PGI's compiler accepts
On 02 Jul 12:45, Kirill Yukhin wrote:
Hello,
Pls disregard this mail and use previous one. Sorry.
--
Thanks, K
Hello!
Attached patch fixes some fallout from IEEE support and enables -mieee
for alpha. Also, the patch removes -O0 from dg-additiona-options in
IEEE testsuite, as this always override default optimization flag.
libgfortran/ChangeLog:
2014-07-02 Uros Bizjak ubiz...@gmail.com
*
Hi all,
I've committed this patch as obvious with r212225. It fixes aarch64
bootstrap.
Cheers,
Kyrill
2014-07-02 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/aarch64/aarch64.c (aarch64_expand_vec_perm): Delete unused
variable i.diff --git a/gcc/config/aarch64/aarch64.c
Dear Uros,
Thanks very much for the patch. I have a few questions:
the patch removes -O0 from dg-additiona-options in IEEE testsuite, as this
always override default optimization flag.
That was my purpose: this test can fail with optimization (on x86_64, IIRC),
hence the -O0 should override
Hi,
This change:
r199935 | amodra | 2013-06-11 07:17:50 +0100 (Tue, 11 Jun 2013) | 4 lines
* config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Calculate
correct shift value in little-endian mode.
Hi,
While writing new guality.exp tests I noticed they often just fail
when ran with -flto, even though they PASS in all other cases. When
I asked on irc about this I was told that LTO was known to not play
well with DWARF debuginfo anyway. If that is the case, it seems better
to disable -flto
On Wed, Jul 2, 2014 at 11:16 AM, FX fxcoud...@gmail.com wrote:
Thanks very much for the patch. I have a few questions:
the patch removes -O0 from dg-additiona-options in IEEE testsuite, as this
always override default optimization flag.
That was my purpose: this test can fail with
Hi,
Silvermont processors have penalty for instructions having 4+ bytes of prefixes
(including escape bytes in opcode). This situation happens when REX prefix is
used in SSE4 instructions. This patch tries to avoid such situation by
preferring xmm0-xmm7 usage over xmm8-xmm15 in those
* Don't duplicate the logic for what's a hosted POSIX system; refactor it
to a common fragment in config/ (I guess it needs to be a shell script
fragment there rather than an actual autoconf macro, since you're using
that logic in configure.tgt which is itself such a fragment).
I've attached
On 30 June 2014 14:26, Richard Earnshaw rearn...@arm.com wrote:
On 30/06/14 13:53, Charles Baylis wrote:
I see two options to fix it - one is to teach the back-end to
successfully generate code for this insn, and the other is to teach
the back-end that such an insn is not valid. My proposed
Hello Kirill,
Kirill Yukhin wrote:
This branch should be capable to perform offload to Intel targets (Xeon PHI)
Which Xeon PHI does it support? Knights Corner, Knights Landing, both?
Tobias
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+!is_global_var (valbase))
+
On Wed, Jul 02, 2014 at 11:05:23AM +0100, Maciej W. Rozycki wrote:
As it
happens both macros have the same value for the Power target
Thanks! Looks good to me. As you note above it is effectively a
documentation fix.
--- gcc-fsf-trunk-quilt.orig/gcc/config/rs6000/rs6000.c 2014-06-10
Hello Tobias
On 02 Jul 14:11, Tobias Burnus wrote:
Kirill Yukhin wrote:
This branch should be capable to perform offload to Intel targets (Xeon PHI)
Which Xeon PHI does it support? Knights Corner, Knights Landing, both?
Currently liboffloadmic supports KNC. Future update will add support for
On Wed, 2 Jul 2014, Alan Modra wrote:
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+
On Wed, Jul 2, 2014 at 7:48 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Mon, May 5, 2014 at 8:21 AM, bin.cheng bin.ch...@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent: Thursday, May 01, 2014 10:03 PM
To: Bin Cheng
Cc: gcc-patches@gcc.gnu.org
Hello Kirill,
On Wed, Jul 02, 2014 at 04:35:01PM +0400, Kirill Yukhin wrote:
However, GCC (main trunk and this branch) does not support code generation
for KNC
and we don't plan to do that.
Hmm, I had hoped that the work would include the forward porting of HJ's
patches from
On 02 Jul 15:06, Tobias Burnus wrote:
Hmm, I had hoped that the work would include the forward porting of HJ's
patches from
https://software.intel.com/en-us/articles/intel-manycore-platform-software-stack-mpss
to the current trunk. In my understanding, that's all what is needed, isn't
it?
On 02/07/14 08:52, Tom de Vries wrote:
On 01-07-14 21:47, Jeff Law wrote:
On 07/01/14 13:27, Tom de Vries wrote:
So my question is: is the combination of '' and '+' supported ? If so,
what is the exact semantics ? If not, should we warn or give an error ?
I don't think we can define any
This patch fixes libgo to not explicitly free tiny blocks when deleting
an entry from a map. The memory allocator now has a special case for
tiny objects (less than 16 bytes), and they can not be explicitly freed,
only garbage collected. This is PR go/61620. Bootstrapped and ran Go
testsuite on
On Wed, Jul 02, 2014 at 09:48:18AM +0200, Jakub Jelinek wrote:
Hi!
As the testcase shows, we ICE on old style initialization of derived type
components. ifort also rejects these, I think it doesn't make sense to
support such initializations of derived type components.
Do you have modes whose size is not multiple of the unit?
Yes. That's exactly the problem I'm trying to solve here. I'm making
partial int modes have real corresponding types, and they can be any
bit size, with target PS*modes to match. The MSP430, for example, has
20-bit modes, 20-bit
.. consider this patch withdrawn. I believe that something is going
wrong indeed as part of most_specialized_instantiation but the details
need to be figured out. I'm now focusing on fn_type_unification via
get_bindings.
Paolo.
Hi,
this patch adds structural comparsion into ODR warnings, so we do not rely
on types_compatible_p to checks if the individual variants of same
name looks same. This allows us to give more precise reason for the
mismatch and also be more strict than canonical type merging.
Function
Hi again,
On 07/02/2014 05:06 PM, Paolo Carlini wrote:
.. consider this patch withdrawn. I believe that something is going
wrong indeed as part of most_specialized_instantiation but the details
need to be figured out. I'm now focusing on fn_type_unification via
get_bindings.
In fact my typo
On 07/02/14 02:32, Eric Botcazou wrote:
So in order to known whether it's safe and optimal to use regs_ever_live
instead, the question is whether the passes after pass_free_cfg (are allowed
to) add or remove sets or clobbers of call_really_used_regs. I don't know
the full answer there.
Ilya Enkovich enkovich@gmail.com writes:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape bytes in opcode). This situation happens
when REX prefix is used in SSE4 instructions. This patch tries to
avoid such situation by preferring
On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote:
Ilya Enkovich enkovich@gmail.com writes:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape bytes in opcode). This situation happens
when REX prefix is used in SSE4
On Jul 2, 2014, at 1:14 AM, Jakub Jelinek ja...@redhat.com wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
wide-int part, Ok.
* wide-int-print.cc (print_decs): Negate UHWI instead of HWI.
--- gcc/wide-int-print.cc.jj 2014-05-11 22:21:04.0 +0200
+++
Hello!
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape
bytes in opcode). This situation happens when REX prefix is used in SSE4
instructions. This
patch tries to avoid such situation by preferring xmm0-xmm7 usage over
xmm8-xmm15 in
On Jul 2, 2014, at 9:27 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote:
Ilya Enkovich enkovich@gmail.com writes:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape bytes in opcode). This
- Original Message -
/aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning:
field ‘mSpa’ (of type ‘struct BufferedMsg’) violates one definition rule
[-Wodr]
Can we reword this warning? The of type 'struct BufferedMsg' could be easily
taken to mean that the type of
Hi!
Reopening this oldie:
On Wed, 19 Dec 2012 16:38:41 +0100, Tobias Burnus bur...@net-b.de wrote:
The attached patch adds
-fintrinsic-modules-path ${blddir}
otherwise, the compiler might have trouble finding the libraries using
use, INTRINSIC :: omp_lib. Without intrinsic it searches
On Tue, Jul 1, 2014 at 6:34 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
On Tue, Jul 1, 2014 at 2:25 PM, Jeff Law l...@redhat.com wrote:
On 03/19/14 08:06, Marcos Díaz wrote:
Well, finally I have the assignment, could you please review this patch?
Thanks.
My first thought
On Jul 2, 2014, at 10:52 AM, Nathan Froyd froy...@mozilla.com wrote:
- Original Message -
/aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning:
field ‘mSpa’ (of type ‘struct BufferedMsg’) violates one definition rule
[-Wodr]
Can we reword this warning? The of
On Jul 2, 2014, at 10:52 AM, Nathan Froyd froy...@mozilla.com wrote:
- Original Message -
/aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning:
field ‘mSpa’ (of type ‘struct BufferedMsg’) violates one definition rule
[-Wodr]
Can we reword this warning?
Mike Stump mikest...@comcast.net writes:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape bytes in opcode). This situation happens
when REX prefix is used in SSE4 instructions. This patch tries to
avoid such situation by preferring xmm0-xmm7
2014-07-02 Gerald Pfeifer ger...@pfeifer.com
* news.html: Make a number of links relative.
* status.html: Ditto.
* libgcj-classpath-compare.html: Remove redundant link to gcc.css.
* gui-compare/libgcj-classpath-compare.html: Ditto.
Committed.
Yes, again this
gcc/
* config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Use
BYTES_BIG_ENDIAN rather than WORDS_BIG_ENDIAN to check for byte
endianness.
This patch is okay. Thanks for noticing it.
Thanks, David
Thomas Schwinge wrote:
Reopening this oldie:
index 5fa42f4..68440d18 100644
--- a/libgomp/testsuite/libgomp.fortran/fortran.exp
+++ b/libgomp/testsuite/libgomp.fortran/fortran.exp
@@ -14,6 +14,7 @@ set quadmath_library_path ../libquadmath/.libs
dg-init
if { $blddir != } {
+lappend
On Wed, Jul 02, 2014 at 05:15:20PM +0200, Jan Hubicka wrote:
Hi,
this patch adds structural comparsion into ODR warnings, so we do not rely
on types_compatible_p to checks if the individual variants of same
name looks same. This allows us to give more precise reason for the
mismatch and also
I can't find the code for the SampleFormat thing, but the rest of them
look like ODR violations to me.
I think it is some define renaming the field, I was also puzled by this one.
/aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning:
field ‘mSpa’ (of type ‘struct
The following patch adds support for a new libgcov interface,
__gcov_profiling_enabled, that can be used by applications to
determine whether a binary has been instrumented for test coverage or
profile optimization.
Passes regression tests and manual testing with different options. Ok
for google
Should the interface be something like:
int __gcov_profiling_for_test_coverage(void)?
David
On Wed, Jul 2, 2014 at 12:55 PM, Teresa Johnson tejohn...@google.com wrote:
The following patch adds support for a new libgcov interface,
__gcov_profiling_enabled, that can be used by applications to
Hi,
this patch strengthens detect_type_change and makes it cheaper based on the
following observation.
We propagate types from places we know instances are created across pointers
passed to functions. Once non-POD type is created at a given memory location,
one can not change its type by
OK.
Thanks, committed.
It would be useful if you could add one or more tests to the
testsuite to confirm proper behaviour when only one of ROTATE/ROTATERT
is defined.
I'll send a patch in a minute that tests this (as well as some other
things) for rs6000.
Segher
On Wed, Jul 2, 2014 at 1:15 PM, Xinliang David Li davi...@google.com wrote:
Should the interface be something like:
int __gcov_profiling_for_test_coverage(void)?
I was equating the term profiling with -fprofile-generate, as
opposed to -ftest-coverage instrumentation. But I can change it to
The reason is that test coverage is using the same underlying
profiling. Returning false when calling '__gcov_profiling_enabled())
in coverage mode is a little misleading.
David
On Wed, Jul 2, 2014 at 1:22 PM, Teresa Johnson tejohn...@google.com wrote:
On Wed, Jul 2, 2014 at 1:15 PM, Xinliang
Firstly, it adds back the split conditions that I accidentally removed.
Without it the dot insns are never generated, or rather, always split
back to a separate compare instruction.
Secondly, the shift amount should be SI always, not GPR, or GCC will
insert a zero-extend at expand time that it
Hi,
In parallel/unique_copy.h __counter is never deleted.
I'm also trying to follow from other posts how to submit a patch but
is well possible I missed some of the conventions. Many apologies if
that's the case.
libstdc++-v3/
* include/parallel/unique_copy.h: prevent memory leak of __counter
On Wed, Jul 02, 2014 at 09:28:03PM +0200, Jan Hubicka wrote:
I can't find the code for the SampleFormat thing, but the rest of them
look like ODR violations to me.
I think it is some define renaming the field, I was also puzled by this one.
On 07/02/14 02:14, Jakub Jelinek wrote:
Hi!
Most of this probably doesn't need explanation, just the
expand_sdiv_pow2 change - shift_cost only tracks shift counts to
MAX_BITS_PER_WORD (but, for consistency between e.g. i?86 and x86_64 -m32
we'd better use BITS_PER_WORD instead as in most other
On 07/02/14 06:19, Alan Modra wrote:
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+
On 06/30/14 15:37, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+!is_global_var (valbase))
+ || TREE_CODE
I think that makes sense; I'm not aware of anyone working on improving
LTO debugging.
Jason
From: Trevor Saunders tsaund...@mozilla.com
Hi,
So apparently its not entirely obvious to everyone that removing the names of
unused arguments is the best way of dealing with warnings about unused
arguments in places like hooks where the argument is required for some reason.
Apparently this is
On 07/02/2014 03:34 PM, Trevor Saunders wrote:
On Wed, Jul 02, 2014 at 09:28:03PM +0200, Jan Hubicka wrote:
it seems to me this doesn't get at the real issue that the type names
are the same but the fields are different. maybe a type of the same
name with different fields defined here?
This
On 07/02/2014 01:18 PM, Jan Hubicka wrote:
We propagate types from places we know instances are created across pointers
passed to functions. Once non-POD type is created at a given memory location,
one can not change its type by placement_new into something else.
Hmm. If the memory location
New patch below. Retested. Ok for google branches?
Thanks,
Teresa
2014-07-02 Teresa Johnson tejohn...@google.com
Google ref b/15378201.
* gcc/tree-profile.c (gcov_test_coverage_decl): Declare.
(tree_init_instrumentation): Initialize gcov_test_coverage_decl.
*
On 07/02/2014 12:02 PM, Tobias Burnus wrote:
Thomas Schwinge wrote:
In -fopenmp mode as well as in combined -fopenacc -fopenmp mode as
well as in regular (no -fopen*) mode, it parses fine.
[Note I am testing with an outdated branch (20140404), but it still
might be representative.]
I am
On 07/02/2014 01:18 PM, Jan Hubicka wrote:
We propagate types from places we know instances are created across pointers
passed to functions. Once non-POD type is created at a given memory
location,
one can not change its type by placement_new into something else.
Hmm. If the memory
On 07/02/2014 01:18 PM, Jan Hubicka wrote:
We propagate types from places we know instances are created across
pointers
passed to functions. Once non-POD type is created at a given memory
location,
one can not change its type by placement_new into something else.
Hmm. If the
On 07/02/2014 06:30 PM, Jan Hubicka wrote:
But this is one of things that was not quite clear to me. I know that
polymorphic type A
was created at a give memory location. THis means that accesses to that
location in one
alias class has been made.
Now I destroy A and turn it into B, construct
On 06/26/2014 03:22 PM, Marek Polacek wrote:
The following is a revamped patch for -Wsizeof-array-argument.
Its purpose is to detect suspicious usage of the sizeof operator on an array
function parameter.
Then the name should be -Wsizeof-array-parm, not -argument.
@@ -9550,6 +9551,8 @@
ok.
thanks,
David
On Wed, Jul 2, 2014 at 5:20 PM, Teresa Johnson tejohn...@google.com wrote:
New patch below. Retested. Ok for google branches?
Thanks,
Teresa
2014-07-02 Teresa Johnson tejohn...@google.com
Google ref b/15378201.
* gcc/tree-profile.c
On 2 July 2014 03:54, Jeff Law l...@redhat.com wrote:
On 07/01/14 01:16, Zhenqiang Chen wrote:
ChangeLog:
2014-07-01 Zhenqiang Chen zhenqiang.c...@linaro.org
* loop-invariant.c (struct invariant): Add a new member: eqno;
(find_identical_invariants): Update eqno;
Cesar Philippidis wrote:
I couldn't find anything obvious in gcc/fortran/parse.c; is someone
able to have a more in-depth look than I have?
First, some minor point, I think one should crosswise reset the
{openmp,openacc}_flag, i.e.
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@
On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote:
I think that makes sense; I'm not aware of anyone working on improving LTO
debugging.
I think at this point all we care about is that with -flto we don't ICE on
those, perhaps we should arrange to change all the tests into dg-do
83 matches
Mail list logo
