On May 27, 2014 3:58:06 AM CEST, David Edelsohn dje@gmail.com wrote:
This patch (further) broke bootstrap on AIX. AIX defaults to 32 bit,
although it supports 64 bit HWI.
/nasfarm/edelsohn/src/src/gcc/bitmap.c: In function 'int
print_statistics(bitmap_descriptor_d**, output_info*)':
On Tue, May 27, 2014 at 08:26:35AM +0200, Richard Biener wrote:
/nasfarm/edelsohn/src/src/gcc/cfg.c: In function 'void
dump_bb_info(FILE*, basic_block, int, int, bool, bool)':
/nasfarm/edelsohn/src/src/gcc/cfg.c:737:33: error: expected ')' before
'PRId64'
This means aix has inttypes.h but
Hello!
These tests require vect_simd_clones effective target, as the target
should be able to compile AVX clones.
2014-05-27 Uros Bizjak ubiz...@gmail.com
* testsuite/libgomp.fortran/declare-simd-1.f90: Require
vect_simd_clones effective target. Remove
dg-additional-options
On Tue, May 27, 2014 at 08:58:18AM +0200, Uros Bizjak wrote:
These tests require vect_simd_clones effective target, as the target
should be able to compile AVX clones.
2014-05-27 Uros Bizjak ubiz...@gmail.com
* testsuite/libgomp.fortran/declare-simd-1.f90: Require
Hi Chistophe and Andreas,
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
I suspect it's the same kind of problem m68k run into. I already wrote a patch
to
reduce the impact of different bitfield layout and it's in review right
On Mon, May 26, 2014 at 9:01 PM, Patrick Palka patr...@parcs.ath.cx wrote:
Hi,
This patch teaches the C++ frontend to warn on NULL checks against
inline functions and it teaches the middle-end to fold NULL checks
against inline functions. These two things are currently done for
non-inline
On Tue, May 27, 2014 at 9:18 AM, Jakub Jelinek ja...@redhat.com wrote:
Please don't remove the dg-additional-options there, that is completely
intentional there, only the simd clones are built for SSE2/AVX/AVX2,
the simd loops are built with whatever options the loop is compiled with,
and for
On Tue, May 27, 2014 at 09:40:23AM +0200, Uros Bizjak wrote:
Following is the v2 patch that I plan to commit after testing:
2014-05-27 Uros Bizjak ubiz...@gmail.com
* testsuite/libgomp.fortran/declare-simd-1.f90: Require
vect_simd_clones effective target.
*
... to avoid implicit declaration of function ‘free’ warning.
2014-05-27 Uros Bizjak ubiz...@gmail.com
* intrinsics/getcwd.c: Include stdlib.h.
Tested on x86_64-pc-linux-gnu.
OK for mainline?
Uros.
Index: intrinsics/getcwd.c
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
Prompted by the recent failures of c-c++-common/gomp/pr60823-2.c on
Solaris/x86 with Sun as
http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00943.html
I've reworked the clearing of
Hi,
Following up Richard's comments:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00967.html
I investigate interrupt routines:
* gcc can shrink-wrapping an interrupt routine (ARM mode). The
shrink-wrap-interrupt_1.c in the patch can show it.
* There is restriction for interrupt routine to be
Hi,
I have been informed, that the following check-in may cause a slight performance
regression on aarch64 and arm on trunk and gcc-4_9-branch:
See https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=205899
This can be seen with the following test example:
test.c:
typedef struct
{
int *x;
Joseph S. Myers jos...@codesourcery.com writes:
On Thu, 22 May 2014, Rainer Orth wrote:
Joseph S. Myers jos...@codesourcery.com writes:
On Thu, 22 May 2014, Rainer Orth wrote:
* common.opt (compressed_debug_sections): New enum.
(gz, gz=): New options.
* opts.c
Patch approved by Jakub in the PR thread.
Dominique
2014-05-27 Dominique d'Humieres domi...@lps.ens.fr
PR testsuite/61319
* c-c++-common/ubsan/float-cast-overflow-1.c: Make the sign of
-nan optional.
* c-c++-common/ubsan/float-cast-overflow-2.c: Likewise.
Segher Boessenkool seg...@kernel.crashing.org writes:
- puts ( LAST_INSN_CODE\n\
+ printf ( LAST_INSN_CODE = %d\n\
};\n\
\n\
-#endif /* GCC_INSN_CODES_H */);
+#endif /* GCC_INSN_CODES_H */, last);
You probably didn't intend to delete the newline at the end of
the generated file?
On Tue, May 27, 2014 at 09:41:08AM +0100, Richard Sandiford wrote:
* gencodes.c (main): Make LAST_INSN_CODE higher than any insn code,
rather than any named insn's code.
Ok.
--- gcc/gencodes.c2014-05-27 09:38:02.195506710 +0100
+++ gcc/gencodes.c2014-05-27
Uros Bizjak wrote:
... to avoid implicit declaration of function âeeâwarning.
2014-05-27 Uros Bizjak ubiz...@gmail.com
* intrinsics/getcwd.c: Include stdlib.h.
Tested on x86_64-pc-linux-gnu.
OK for mainline?
OK - thanks for the patch. (I think it also counts as obvious.)
Tobias
On Tue, May 27, 2014 at 10:10 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi,
I have been informed, that the following check-in may cause a slight
performance
regression on aarch64 and arm on trunk and gcc-4_9-branch:
See https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=205899
+ tree new_const
+ = fold_build2_loc (loc, reverse_op, TREE_TYPE (arg1), const2,
const1);
/* If the constant operation overflowed this can be
simplified as a comparison against INT_MAX/INT_MIN. */
- if (TREE_CODE (lhs) == INTEGER_CST
-
On Tue, May 27, 2014 at 11:25 AM, Eric Botcazou ebotca...@adacore.com wrote:
+ tree new_const
+ = fold_build2_loc (loc, reverse_op, TREE_TYPE (arg1), const2,
const1);
/* If the constant operation overflowed this can be
simplified as a comparison against
I'm asking to merge them (move them to fold_comparison).
OK, I'll repost a first patch doing only the fold-const.c massaging.
Yeah, it would be nice to see some support. The most interesting cases
will be symbolic-singleton +- CST where the offset shrinks a constant offset
in a symbolic A
On Tue, May 27, 2014 at 11:59 AM, Eric Botcazou ebotca...@adacore.com wrote:
I'm asking to merge them (move them to fold_comparison).
OK, I'll repost a first patch doing only the fold-const.c massaging.
Yeah, it would be nice to see some support. The most interesting cases
will be
2014-03-01 1:40 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it into
locations where the host will eventually be able to
Especially for ops with symbolic ranges it may be preferable
to compare one range with an op such as in
[x + 1, x + 1] x instead of expanding the range of x on
the rhs to sth unrelated.
So, try harder.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-05-27 Richard
On Tue, 27 May 2014, Richard Biener wrote:
On May 27, 2014 3:58:06 AM CEST, David Edelsohn dje@gmail.com wrote:
This patch (further) broke bootstrap on AIX. AIX defaults to 32 bit,
although it supports 64 bit HWI.
/nasfarm/edelsohn/src/src/gcc/bitmap.c: In function 'int
On Tue, 27 May 2014, Jakub Jelinek wrote:
On Tue, May 27, 2014 at 08:26:35AM +0200, Richard Biener wrote:
/nasfarm/edelsohn/src/src/gcc/cfg.c: In function 'void
dump_bb_info(FILE*, basic_block, int, int, bool, bool)':
/nasfarm/edelsohn/src/src/gcc/cfg.c:737:33: error: expected ')' before
Spotted that a call to demangle_template might allocate storage within a
temporary string even if the call to demangle_template eventually returns
failure.
This will never cause the demangler to crash, but does leak memory, as a
result I've not added any tests for this.
Calling string_delete is
On 05/27/2014 12:17 PM, Ilya Verbin wrote:
2014-03-01 1:40 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it into
locations
2014-05-26 20:47 GMT+04:00 Georg-Johann Lay a...@gjlay.de:
This adds a note to the user manual that code with label differences is not
supported. This is because adding an offset to a stub address as generated
with gs() will in general not yield the address of the label+offset.
This actually
2014-05-27 14:59 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There isn't a way to do this. For ptx, target libraries can't be built
anyway. For your use case, I'd recommend building the offload gcc first,
installing it, and then building the host gcc with --enable-offload-targets
as
Tested x86_64-linux, committed to trunk, will commit to 4.9 later
today.
commit 9ea4330e4e3a7fe431206048f2e1efe5e9c28eaa
Author: Jonathan Wakely jwak...@redhat.com
Date: Tue May 27 11:48:50 2014 +0100
PR libstdc++/61329
* include/bits/regex_automaton.tcc (_State_base::_M_print): Add
On 05/27/2014 01:11 PM, Ilya Verbin wrote:
2014-05-27 14:59 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There isn't a way to do this. For ptx, target libraries can't be built
anyway. For your use case, I'd recommend building the offload gcc first,
installing it, and then building the host
This adds runtime library exceptions for some more files that go into libgcc.c
via tm.h, mostly due to v850.
Ok for trunk?
Johann
gcc/
PR libgcc/61152
* config/dbx.h (License): Add Runtime Library Exception.
* config/newlib-stdint.h (License): Same.
*
E.g. CentOS 5 doesn't define several macros in limits.h, so define
them conditionally to make the test pass.
Ok for trunk?
2014-05-27 Marek Polacek pola...@redhat.com
PR testsuite/61319
* c-c++-common/ubsan/float-cast.h: Conditionally define LLONG_MAX,
LLONG_MIN, and
On Tue, May 27, 2014 at 09:44:22AM +0200, Uros Bizjak wrote:
... to avoid implicit declaration of function ???free??? warning.
2014-05-27 Uros Bizjak ubiz...@gmail.com
* intrinsics/getcwd.c: Include stdlib.h.
Tested on x86_64-pc-linux-gnu.
OK for mainline?
Yes.
It can also
On Tue, May 27, 2014 at 01:32:03PM +0200, Marek Polacek wrote:
E.g. CentOS 5 doesn't define several macros in limits.h, so define
them conditionally to make the test pass.
Ok for trunk?
2014-05-27 Marek Polacek pola...@redhat.com
PR testsuite/61319
*
I tried running the demangler's testsuite with CP_DEMANGLE_DEBUG
defined, but it crashed, with:
Program received signal SIGSEGV, Segmentation fault.
0x0040a8c3 in d_dump (dc=0x1, indent=12) at
../../src/libiberty/cp-demangle.c:567
567 switch (dc-type)
(gdb) bt 3
#0
This patch teaches g++ to try to demangle any symbol it
generates/mangles, when checking is enabled in the build, as soon as
the symbol is mangled. The idea here is validate the demangling as
close as possible to the generator as possible.
This allows catching demangler bugs/crashes much earlier
There's been discussion on the GDB lists about demangler crashes
bringing down GDB.
Such demangler bugs should be fixed, of course. Patch 2 in this
series fixes the one that is currently known.
But while GDB demangles all symbols in every file it loads, always, in
libstdc++, the demangler is
The fix for bug 59195:
[C++ demangler handles conversion operator incorrectly]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195
unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.
For example, with:
templateint struct A {};
template
Hi,
On Tue, 27 May 2014 11:06:21, Richard Biener wrote:
But the coment previously read
/* A constant address in TO_RTX can have VOIDmode, we must not try
to call force_reg for that case. Avoid that case. */
and you are removing that check. So I guess you want to retain
GET_MODE (XEXP
On Tue, May 27, 2014 at 3:33 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, May 26, 2014 at 9:01 PM, Patrick Palka patr...@parcs.ath.cx wrote:
Hi,
This patch teaches the C++ frontend to warn on NULL checks against
inline functions and it teaches the middle-end to fold NULL
Georg-Johann Lay a...@gjlay.de writes:
gcc/
PR libgcc/61152
* config/dbx.h (License): Add Runtime Library Exception.
* config/newlib-stdint.h (License): Same.
* config/rtems.h (License): Same
* config/initfini-array.h (License): Same
* config/v850/v850.h
On 05/22/2014 05:56 PM, Joseph S. Myers wrote:
On Thu, 22 May 2014, Bernd Schmidt wrote:
The implementations of some functions like fork_execute are changed to those
from collect2 and the calls in lto-wrapper adapted accordingly. There are some
minor changes in these functions: for example I
Hi,
Commits 210964 and 210965 for this patch have broken GCC build on arm* targets.
For instance on target arm-none-linux-gnueabi, when creating
unwind-arm.o, I can see:
/tmp/5673443_3.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/lra.c:1362
0x8e3bcd process_insn_for_elimination
I noticed that string constants built by the Fortran frontend don't set
TREE_READONLY for STRING_CST (and subsequently noticed that nothing
seems to set it for COMPLEX_CST). That was confusing the ptx backend I'm
working on.
The -fwritable-strings option for C was removed a while ago, so I
Compiling Fortran code with the ptx backend I'm working on results in
assembler warnings about mismatch between function calls and function
decls. This seems to be a bug in the Fortran frontend, where a decl for
_gfortran_caf_init is created with four arguments, while the library
function is
When putting a constant into the constant pool, we make a copy of the
tree in build_constant_desc. This caused me some problems with the ptx
backend, which has a pass to modify the address spaces of all variables
and constants to match the requirements of the backend. It would be nice
for it
Hi,
here, in order to accept the code without an explicit this-
qualification, I propose to simply notice that instance ==
current_class_type. Tested x86_64-linux.
Thanks!
Paolo.
/cp
2014-05-27 Paolo Carlini paolo.carl...@oracle.com
PR c++/57543
*
This fixes the AIX breakage by defining __STDC_FORMAT_MACROS
earlier, before stdio.h on AIX gets to include inttypes.h.
Committed as obvious.
Richard.
2014-05-27 Richard Biener rguent...@suse.de
* system.h (__STDC_FORMAT_MACROS): Define as very first thing.
Index: gcc/system.h
On Tue, May 27, 2014 at 2:12 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
Hi,
Commits 210964 and 210965 for this patch have broken GCC build on arm*
targets.
For instance on target arm-none-linux-gnueabi, when creating
unwind-arm.o, I can see:
On Tue, May 27, 2014 at 12:27 PM, Richard Biener wrote:
* tree-vrp.c (vrp_evaluate_conditional_warnv_with_ops_using_ranges):
Try using literal operands when comparing value-ranges failed.
No test case?
Ciao!
Steven
On Tue, May 27, 2014 at 3:57 AM, Andrew Burgess aburg...@broadcom.com wrote:
libiberty/ChangeLog
* cplus-dem.c (do_type): Call string_delete even if the call to
demangle_template fails.
This is OK.
Thanks.
I have to ask: you know this code is not used, right? You're
On Tue, 27 May 2014, Steven Bosscher wrote:
On Tue, May 27, 2014 at 12:27 PM, Richard Biener wrote:
* tree-vrp.c (vrp_evaluate_conditional_warnv_with_ops_using_ranges):
Try using literal operands when comparing value-ranges failed.
No test case?
Sorry ;) Happens to
On Tue, May 27, 2014 at 4:57 AM, Pedro Alves pal...@redhat.com wrote:
libiberty/
2014-05-26 Pedro Alves pal...@redhat.com
* cp-demangle.c (d_dump): Handle DEMANGLE_COMPONENT_FUNCTION_PARAM
and DEMANGLE_COMPONENT_NUMBER.
This is OK.
Thanks.
Ian
Hello,
The VxWorks compilation of C sources using vxworks header files need the CPU
macro to be defined. Configuration files in the compiler are setup to to pick
a default value depending on the cpu variant for which we are compiling.
On powerpc, this is achieved with:
#define CPP_SPEC \
Bernd Schmidt wrote:
Compiling Fortran code with the ptx backend I'm working on results in
assembler warnings about mismatch between function calls and function decls.
Bootstrapped and tested on x86_64-linux. Ok?
OK.
The change/bug is due to my fortran-caf - trunk patch at
- Original Message -
On 05/23/14 02:58, Kai Tietz wrote:
Hello,
yes the underlying issue is the same as for PR/46219. Nevertheless
the patch doesn't solve this mentioned PR as I used for know a pretty
conservative checking of allowed memories. By extending
On Tue, May 27, 2014 at 8:32 AM, Patrick Palka patr...@parcs.ath.cx wrote:
On Tue, May 27, 2014 at 3:33 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, May 26, 2014 at 9:01 PM, Patrick Palka patr...@parcs.ath.cx wrote:
Hi,
This patch teaches the C++ frontend to warn on NULL
Christophe Lyon christophe.l...@linaro.org writes:
Hi,
Commits 210964 and 210965 for this patch have broken GCC build on arm*
targets.
Could you send me the .i?
For instance on target arm-none-linux-gnueabi, when creating
unwind-arm.o, I can see:
On Thu, Apr 17, 2014 at 6:23 AM, Teresa Johnson tejohn...@google.com wrote:
On Wed, Apr 16, 2014 at 10:39 PM, Jeff Law l...@redhat.com wrote:
On 03/26/14 17:44, Teresa Johnson wrote:
Recently I discovered that the profile updates being performed by jump
threading were incorrect in many cases,
Richard Sandiford rsand...@linux.vnet.ibm.com writes:
Does the following patch help?
Bah, it won't of course: %i1 needs to be the operator.
Richard
On Tue, 13 Aug 2013, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
backend. When compiling for NEON
On 27 May 2014 09:23, Thomas Preud'homme thomas.preudho...@arm.com wrote:
Hi Chistophe and Andreas,
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
I suspect it's the same kind of problem m68k run into. I already wrote a
patch
to
On Tue, May 27, 2014 at 3:31 PM, Maciej W. Rozycki
ma...@codesourcery.com wrote:
On Tue, 13 Aug 2013, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added
On Tue, 27 May 2014, Richard Biener wrote:
On Tue, 27 May 2014, Steven Bosscher wrote:
On Tue, May 27, 2014 at 12:27 PM, Richard Biener wrote:
* tree-vrp.c
(vrp_evaluate_conditional_warnv_with_ops_using_ranges):
Try using literal operands when comparing value-ranges
This patch fixes a memory leakage with allocatables and user-defined operators.
It is basically Mikael's patch adjusted in order to take into account Tobias'
comments. The patch fixes the memory leak in the test
gfortran.dg/class_array_15.f03
and I have added a check for it.
In the PR I asked
On Tue, May 27, 2014 at 4:06 PM, Patrick Palka patr...@parcs.ath.cx wrote:
On Tue, May 27, 2014 at 8:32 AM, Patrick Palka patr...@parcs.ath.cx wrote:
On Tue, May 27, 2014 at 3:33 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, May 26, 2014 at 9:01 PM, Patrick Palka
On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt ber...@codesourcery.com wrote:
I noticed that string constants built by the Fortran frontend don't set
TREE_READONLY for STRING_CST (and subsequently noticed that nothing seems to
set it for COMPLEX_CST). That was confusing the ptx backend I'm
On 27 May 2014 15:37, Ramana Radhakrishnan ramana@googlemail.com wrote:
On Tue, May 27, 2014 at 2:12 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
Hi,
Commits 210964 and 210965 for this patch have broken GCC build on arm*
targets.
For instance on target arm-none-linux-gnueabi,
On Tue, May 27, 2014 at 3:26 PM, Bernd Schmidt ber...@codesourcery.com wrote:
When putting a constant into the constant pool, we make a copy of the tree
in build_constant_desc. This caused me some problems with the ptx backend,
which has a pass to modify the address spaces of all variables and
On Tue, May 27, 2014 at 1:37 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
... to avoid implicit declaration of function ???free??? warning.
2014-05-27 Uros Bizjak ubiz...@gmail.com
* intrinsics/getcwd.c: Include stdlib.h.
It can also be committed to the 4.9 branch if you
Richard Sandiford rdsandif...@googlemail.com writes:
Richard Sandiford rsand...@linux.vnet.ibm.com writes:
Does the following patch help?
Bah, it won't of course: %i1 needs to be the operator.
Here's v2. I tested that it worked for simple tests like:
int f1 (int x, int y) { return x + (y
On 27/05/14 15:08, Richard Sandiford wrote:
Hmm, is this because of insn_enabled? If so, how did that work before
the patch? LRA already assumed that the enabled attribute didn't depend
on the operands.
Huh! enabled can be applied to each alternative. Alternatives are
selected based on the
On 27/05/14 15:31, Maciej W. Rozycki wrote:
On Tue, 13 Aug 2013, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
arm_neon.h contains a bunch of functions (for example, the wonderful vcgez_u*
intrinsics - that's an unsigned comparison of greater-than-or-equal-to zero)
that are not present in the current ARM Neon Intrinsics spec:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073a/index.html
This
On 05/27/14 02:07, Zhenqiang Chen wrote:
Hi,
Following up Richard's comments:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00967.html
I investigate interrupt routines:
* gcc can shrink-wrapping an interrupt routine (ARM mode). The
shrink-wrap-interrupt_1.c in the patch can show it.
* There is
On 27/05/14 15:47, Ramana Radhakrishnan wrote:
On Tue, May 27, 2014 at 3:31 PM, Maciej W. Rozycki
ma...@codesourcery.com wrote:
On Tue, 13 Aug 2013, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
On 05/27/14 15:57, Olivier Hainque wrote:
Hello,
The VxWorks compilation of C sources using vxworks header files need the CPU
macro to be defined. Configuration files in the compiler are setup to to pick
a default value depending on the cpu variant for which we are compiling.
OK for mainline
On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
On 27/05/14 15:08, Richard Sandiford wrote:
Hmm, is this because of insn_enabled? If so, how did that work before
the patch? LRA already assumed that the enabled attribute didn't depend
on the operands.
Huh! enabled can
No, hold that, vfmaq_n_f64 has been added back in the latest version (to which I
linked). Hang on...
--Alan
Alan Lawrence wrote:
arm_neon.h contains a bunch of functions (for example, the wonderful vcgez_u*
intrinsics - that's an unsigned comparison of greater-than-or-equal-to zero)
that are
2014-05-27 15:15 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
On 05/27/2014 01:11 PM, Ilya Verbin wrote:
Do I understand correctly that you recommend to build our offload gcc
manually, rather than during configure/make?
Well, configure/make it separately - build and install it first.
If
On 05/19/2014 06:10 PM, Jan Hubicka wrote:
Instead of adding extra loop over whole symtab, what about converting them at a
time
the symbols are inserted into the symbol table or in
function_and_variable_visibility
that already does quite few changes into various flags?
Converting them during
On 05/26/14 14:32, Kai Tietz wrote:
- Original Message -
On Mon, May 26, 2014 at 03:22:50PM -0400, Kai Tietz wrote:
In any case, I still can't understand how limiting the choices
of the register allocator can improve code rather than making
it worse. If the accumulator is available
On 27/05/14 16:27, Jakub Jelinek wrote:
On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
On 27/05/14 15:08, Richard Sandiford wrote:
Hmm, is this because of insn_enabled? If so, how did that work before
the patch? LRA already assumed that the enabled attribute didn't depend
On Tue, 27 May 2014, Ramana Radhakrishnan wrote:
Looking at the section on unaligned accesses, it seems that the
ldrb/strb-class instructions are the only ones that are unaffected by the
SCTLR.A bit and do not produce alignment faults in any case.
The NEON load/store instructions,
On Tue, May 27, 2014 at 04:40:13PM +0100, Richard Earnshaw wrote:
quote
The @code{enabled} insn attribute may be used to disable certain insn
alternatives for machine-specific reasons.
quote
The rest of the text just says what happens when this is done and then
gives an example usage. It
Ok, so just the part ok the patch remains to prevent varardic-functions being a
sibling-tail-call remains.
Kai
On 05/22/2014 02:33 PM, Kai Tietz wrote:
* config/i386/i386.c (ix86_expand_call): Enforce for sibcalls
on memory the use of accumulator-register.
I don't like this at all.
I'm fine with allowing memories that are fully symbolic, e.g.
extern void (*foo)(void);
void f(void) { foo();
The recent comdat group changes broke the mips build because mips.c
was not including cgraph.h. I am checking in the following patch
as obvious to fix the mips build.
2014-05-27 Steve Ellcey sell...@mips.com
* config/mips/mips.c: Add include of cgraph.h.
diff --git
On 27/05/14 16:50, Jakub Jelinek wrote:
On Tue, May 27, 2014 at 04:40:13PM +0100, Richard Earnshaw wrote:
quote
The @code{enabled} insn attribute may be used to disable certain insn
alternatives for machine-specific reasons.
quote
The rest of the text just says what happens when this is
Richard Earnshaw rearn...@arm.com writes:
On 27/05/14 16:27, Jakub Jelinek wrote:
On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
On 27/05/14 15:08, Richard Sandiford wrote:
Hmm, is this because of insn_enabled? If so, how did that work before
the patch? LRA already
Steve Ellcey sell...@mips.com writes:
The recent comdat group changes broke the mips build because mips.c
was not including cgraph.h. I am checking in the following patch
as obvious to fix the mips build.
Wasn't that fixed by:
2014-05-26 Jan Hubicka hubi...@ucw.cz
* tree.h
I'm asking to merge them (move them to fold_comparison).
Done (in the end the patch removes more lines than it adds :-).
Tested on x86_64-suse-linux with no regressions.
2014-05-27 Eric Botcazou ebotca...@adacore.com
* fold-const.c (fold_comparison): Clean up and extend X +- C1 CMP
On May 27, 2014 6:12:58 PM CEST, Eric Botcazou ebotca...@adacore.com wrote:
I'm asking to merge them (move them to fold_comparison).
Done (in the end the patch removes more lines than it adds :-).
That's what I like!
Tested on x86_64-suse-linux with no regressions.
OK.
Thanks,
Richard.
On 27/05/14 17:09, Richard Sandiford wrote:
Richard Earnshaw rearn...@arm.com writes:
On 27/05/14 16:27, Jakub Jelinek wrote:
On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
On 27/05/14 15:08, Richard Sandiford wrote:
Hmm, is this because of insn_enabled? If so, how did
On 05/27/2014 08:39 AM, Jeff Law wrote:
But the value we want may be sitting around in a convenient register (such as
r11). So if we force the sibcall to use %rax, then we have to generate a
copy. Yet if we have a constraint for the set of registers allowed here, then
we give the register
Richard Earnshaw rearn...@arm.com writes:
On 27/05/14 17:09, Richard Sandiford wrote:
Richard Earnshaw rearn...@arm.com writes:
On 27/05/14 16:27, Jakub Jelinek wrote:
On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
On 27/05/14 15:08, Richard Sandiford wrote:
Hmm, is this
On Tue, 2014-05-27 at 17:12 +0100, Richard Sandiford wrote:
Steve Ellcey sell...@mips.com writes:
The recent comdat group changes broke the mips build because mips.c
was not including cgraph.h. I am checking in the following patch
as obvious to fix the mips build.
Wasn't that fixed by:
On 27 May 2014 17:07, Richard Sandiford rdsandif...@googlemail.com wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
Richard Sandiford rsand...@linux.vnet.ibm.com writes:
Does the following patch help?
Bah, it won't of course: %i1 needs to be the operator.
Here's v2. I tested
1 - 100 of 150 matches
Mail list logo
