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
>
> * testsuite/libgomp.fortran/declare-simd-1.f90: Require
> vect_simd_clones effectiv
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 rig
On Mon, May 26, 2014 at 9:01 PM, Patrick Palka 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 C++ functions, b
On Tue, May 27, 2014 at 9:18 AM, Jakub Jelinek 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 the common c
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
>
> * testsuite/libgomp.fortran/declare-simd-1.f90: Require
> vect_simd_clones effective target.
> * testsuite/libgomp.fortran/de
... to avoid "implicit declaration of function ‘free’" warning.
2014-05-27 Uros Bizjak
* intrinsics/getcwd.c: Include stdlib.h.
Tested on x86_64-pc-linux-gnu.
OK for mainline?
Uros.
Index: intrinsics/getcwd.c
===
--- intri
Rainer Orth writes:
> Rainer Orth 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 hardware capabilities via linker maps for
>> Sun ld
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 shr
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=revision&revision=205899
This can be seen with the following test example:
test.c:
typedef struct
{
int *x;
"Joseph S. Myers" writes:
> On Thu, 22 May 2014, Rainer Orth wrote:
>
>> "Joseph S. Myers" writes:
>>
>> > On Thu, 22 May 2014, Rainer Orth wrote:
>> >
>> >> * common.opt (compressed_debug_sections): New enum.
>> >> (gz, gz=): New options.
>> >
>> >> * opts.c (common_handle_option): Handl
Patch approved by Jakub in the PR thread.
Dominique
2014-05-27 Dominique d'Humieres
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.
* c-c++-common/ub
Segher Boessenkool 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?
Oops. Upd
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 09:39:16.002
Uros Bizjak wrote:
> ... to avoid "implicit declaration of function âeeâwarning.
>
> 2014-05-27 Uros Bizjak
>
> * 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
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=revision&revision=205899
>
> This can be see
> + 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
> - && TR
On Tue, May 27, 2014 at 11:25 AM, Eric Botcazou 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 INT_MAX/INT_MIN. */
> 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
On Tue, May 27, 2014 at 11:59 AM, Eric Botcazou 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 symbolic-singleton +-
2014-03-01 1:40 GMT+04:00 Bernd Schmidt :
>> 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 find it. Then
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 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(bitm
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 ')'
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 sa
On 05/27/2014 12:17 PM, Ilya Verbin wrote:
2014-03-01 1:40 GMT+04:00 Bernd Schmidt :
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 e
2014-05-26 20:47 GMT+04:00 Georg-Johann Lay :
> 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 occurs o
2014-05-27 14:59 GMT+04:00 Bernd Schmidt :
> 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 described above.
Do I un
Tested x86_64-linux, committed to trunk, will commit to 4.9 later
today.
commit 9ea4330e4e3a7fe431206048f2e1efe5e9c28eaa
Author: Jonathan Wakely
Date: Tue May 27 11:48:50 2014 +0100
PR libstdc++/61329
* include/bits/regex_automaton.tcc (_State_base::_M_print): Add
inline specif
On 05/27/2014 01:11 PM, Ilya Verbin wrote:
2014-05-27 14:59 GMT+04:00 Bernd Schmidt :
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-offloa
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.
* config/rt
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
PR testsuite/61319
* c-c++-common/ubsan/float-cast.h: Conditionally define LLONG_MAX,
LLONG_MIN, and ULLONG_MAX.
diff --
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
>
> * intrinsics/getcwd.c: Include stdlib.h.
>
> Tested on x86_64-pc-linux-gnu.
>
> OK for mainline?
>
Yes.
It can also be comm
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
>
> PR testsuite/61319
> * c-c++-common/ubsan/float-cast.h
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 0x000
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 onl
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:
template struct A {};
template vo
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_MO
On Tue, May 27, 2014 at 3:33 AM, Richard Biener
wrote:
> On Mon, May 26, 2014 at 9:01 PM, Patrick Palka 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
Georg-Johann Lay 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 (Licen
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 av
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
/t
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 teste
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 de
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 to
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
PR c++/57543
* call.c (build_new_method_ca
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
* 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
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:
> /tmp/5673443_3.tmpdir/aci-gcc-fsf/sources/gcc-fsf
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 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 looking
at the old dema
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 wrote:
>
> libiberty/
> 2014-05-26 Pedro Alves
>
> * 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
https://gcc.gn
- 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
> > x86_sib
On Tue, May 27, 2014 at 8:32 AM, Patrick Palka wrote:
> On Tue, May 27, 2014 at 3:33 AM, Richard Biener
> wrote:
>> On Mon, May 26, 2014 at 9:01 PM, Patrick Palka wrote:
>>> Hi,
>>>
>>> This patch teaches the C++ frontend to warn on NULL checks against
>>> inline functions and it teaches the mid
Christophe Lyon 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:
> /tmp/5673443_3.tmpdir/aci-gcc-fsf/sources/gcc-fsf/tru
On Thu, Apr 17, 2014 at 6:23 AM, Teresa Johnson wrote:
> On Wed, Apr 16, 2014 at 10:39 PM, Jeff Law 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, particularly in the cas
Richard Sandiford 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 wrote:
> > >
> > >> Hi all,
> > >>
> > >> The recently added gcc.target/arm/pr58041.c test exposed a bug in the
> > >> backend. When compiling for NEO
On 27 May 2014 09:23, Thomas Preud'homme 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
>> reduce t
On Tue, May 27, 2014 at 3:31 PM, 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 wrote:
>> > >
>> > >> Hi all,
>> > >>
>> > >> The recently added gcc.target/arm/pr580
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
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 the
On Tue, May 27, 2014 at 4:06 PM, Patrick Palka wrote:
> On Tue, May 27, 2014 at 8:32 AM, Patrick Palka wrote:
>> On Tue, May 27, 2014 at 3:33 AM, Richard Biener
>> wrote:
>>> On Mon, May 26, 2014 at 9:01 PM, Patrick Palka wrote:
Hi,
This patch teaches the C++ frontend to warn on
On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt 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 working on.
> The -fwrita
On 27 May 2014 15:37, Ramana Radhakrishnan wrote:
> On Tue, May 27, 2014 at 2:12 PM, Christophe Lyon
> 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 3:26 PM, Bernd Schmidt 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 constants
> to match
On Tue, May 27, 2014 at 1:37 PM, Steve Kargl
wrote:
>> ... to avoid "implicit declaration of function ???free???" warning.
>>
>> 2014-05-27 Uros Bizjak
>>
>> * intrinsics/getcwd.c: Include stdlib.h.
> It can also be committed to the 4.9 branch if you have the time.
There is no need for s
Richard Sandiford writes:
> Richard Sandiford 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 << 4); }
int f2 (int x, int y) { return x - (y << 4
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 base
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 wrote:
> Hi all,
>
> The recently added gcc.target/arm/pr58041.c test exposed a bug in
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 pat
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
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 wrote:
Hi all,
The recently added gcc.target/arm/pr
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!
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 :
> 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 there was a wa
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 ther
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 di
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 instructio
On Tue, May 27, 2014 at 04:40:13PM +0100, Richard Earnshaw wrote:
>
> The @code{enabled} insn attribute may be used to disable certain insn
> alternatives for machine-specific reasons.
>
>
> The rest of the text just says what happens when this is done and then
> gives an example usage. It does
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
* config/mips/mips.c: Add include of cgraph.h.
diff --git a/gcc/config/mips/mips.c b/gcc/co
On 27/05/14 16:50, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:40:13PM +0100, Richard Earnshaw wrote:
>>
>> The @code{enabled} insn attribute may be used to disable certain insn
>> alternatives for machine-specific reasons.
>>
>>
>> The rest of the text just says what happens when this is d
Richard Earnshaw 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 assumed
"Steve Ellcey " 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
* tree.h (decl_comdat_group): Declare.
> 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
* fold-const.c (fold_comparison): Clean up and extend X +- C1 CMP C2
to X CMP
On May 27, 2014 6:12:58 PM CEST, Eric Botcazou 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.
>
>2014-05-27 Eric B
On 27/05/14 17:09, Richard Sandiford wrote:
> Richard Earnshaw 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 tha
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 writes:
> On 27/05/14 17:09, Richard Sandiford wrote:
>> Richard Earnshaw 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 "i
On Tue, 2014-05-27 at 17:12 +0100, Richard Sandiford wrote:
> "Steve Ellcey " 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 wrote:
> Richard Sandiford writes:
>> Richard Sandiford 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:
>
I confirm that the compiler no
"Thomas Preud'homme" writes:
> diff --git a/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
> b/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
> index 38f18fd..4368d83 100644
> --- a/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
> +++ b/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
> @@ -6,8 +6,11
On 05/27/14 10:22, Richard Henderson wrote:
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
Steve Ellcey writes:
> On Tue, 2014-05-27 at 17:12 +0100, Richard Sandiford wrote:
>> "Steve Ellcey " 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.
>>
1 - 100 of 151 matches
Mail list logo
