On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
> On May 26, 2014, at 2:22 AM, FX wrote:
> >> This causes GCC bootstrap to fail on Darwin systems (whose system compiler
> >> is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
> >> it’s the right call, see below)
Hi Richard,
Please refer to the attached patch files.
gcc-p5600-noMSA.patch
TARGET_P5600 has been removed
gcc-p5600-noMSA-msched-weight.patch
Per-instruction structure has been created to store both GP and VEC pressures.
We are using size of a mode to differentiate GP and VEC registers. Regist
On 22/05/14 22:18, Richard Earnshaw wrote:
> On 22/05/14 00:44, Kugan wrote:
>> Compiling some applications with -mgeneral-regs-only produces better
>> code (runs faster) compared to not using it. The difference here is that
>> when -mgeneral-regs-only is not used, floating point register are als
Dmitry,
You've introduced atomic_uint64_t stats_[AllocatorStatCount]; in
http://llvm.org/viewvc/llvm-project?view=revision&revision=173332
Do you mind to change it to atomic_uintptr_t?
There is of course a chance of overflow on 32-bit arch (the number of
mallocs in a process may easily go over 2^
On Mon, May 26, 2014 at 11:54:04AM +0400, Maxim Ostapenko wrote:
> Hi,
>
> A years ago there was a discussion (
> https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging
> compiler ICEs that resulted in a patch from Jakub, which dumps useful
> information into temporary file, but
Hi,
I was trying to compile an ilp32 enabled glibc and ran into a
failure with stack protector. The problem is two fold. First we were
generating the wrong mode for the result to testing against zero. The
next issue is we were using 64bit loads instead of 32bit loads from
__stack_chk_guard. T
This patch adds an RX-specific "vector" attribute as well as extending
the "interrupt" attribute. With this change, gcc will pass additional
information to the linker to auto-generate interrupt tables and other
vector tables. Also fixed a minor bug in adjust_insn_length.
Committed.
* co
On Tue, 27 May 2014, Kyrill Tkachov wrote:
> > > This change however has regressed gcc.dg/vect/vect-72.c on the
> > > arm-linux-gnueabi target, -march=armv5te, in particular in 4.8.
> > And what are all the configure flags you are using in case some one
> > has to reproduce this issue ?
>
> Sec
On Tue, May 27, 2014 at 11:00 PM, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 11:50:33PM +0200, Jakub Jelinek wrote:
>> On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
>> > It's being called form basically two files:
>> >
>> > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ fin
On 22/05/14 01:08, Marcus Shawcroft wrote:
> On 15 May 2014 01:10, Kugan wrote:
>>
>> Hi All,
>>
>> AAarch64 back-end defines GENERAL_REGS and CORE_REGS with the same set
>> of register. Is there any reason why we need this?
>
> Nope an artifact of the early evolution of AArch64. Long ago CORE_R
On Tue, 2014-05-27 at 17:04 -0500, Peter Bergner wrote:
> On Tue, 2014-05-27 at 23:50 +0200, Jakub Jelinek wrote:
> > Does ppc32 have any atomic 64-bit loads/stores (in the sense that the
> > aligned
> > 64 bits are written as one memory transaction, not each 32-bit word
> > separately)?
>
> The
>
> here we have decl and its local alias:
> (gdb) p debug_tree (sect->named.decl)
> type type 700f57e0>
> unsigned SI
> size
> unit size
> align 32 symtab 45 alias set 3 canonical type 700f5840
> pointer_to_this >
>
On Tue, May 27, 2014 at 05:04:52PM -0500, Peter Bergner wrote:
> On Tue, 2014-05-27 at 23:50 +0200, Jakub Jelinek wrote:
> > On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> > > It's being called form basically two files:
> > >
> > > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]
... if the approach makes sense, we want to pass a proper in_decl in one
more place, otherwise specializations are not handled (eg, K in the
testcase). Like the below, lightly tested so far.
Paolo.
///
Index: cp/pt.c
=
On Tue, 2014-05-27 at 23:50 +0200, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> > It's being called form basically two files:
> >
> > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ find . -name '*.o' |
> > xargs nm -AC | grep sync_fetch_and_add_8
> >
On crazy systems that mark the write system call as __attribute__
((warn_unused_result)), libgo gets a build failure. This patch from
Andrew Wilkins fixes it. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.9 branch.
Ian
diff -r 0127d52c1d74 libgo/run
On Tue, May 27, 2014 at 11:50:33PM +0200, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> > It's being called form basically two files:
> >
> > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ find . -name '*.o' |
> > xargs nm -AC | grep sync_fetch_and_add
On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> It's being called form basically two files:
>
> [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ find . -name '*.o' | xargs
> nm -AC | grep sync_fetch_and_add_8
> ./powerpc64-linux/32/libsanitizer/sanitizer_common/.libs/sanitizer_a
Hi,
On 05/27/2014 07:15 PM, Jason Merrill wrote:
I don't think this is the right place for the fix; why do we have a
dummy object at all? Doesn't maybe_dummy_object return
current_class_ref in this situation?
I see, thanks for the dummy object clarification.
Therefore, it seems to me that th
> Or, I can ask, any objections? In https://gcc.gnu.org/PR61146 it is stated
> that GMP removed the casts in 2005.
Among the many many versions of longlong.h that one can find around the web,
many have don’t have these casts, including GMP and coreutils
(http://code.metager.de/source/xref/gnu/
Ping?
Or, I can ask, any objections? In https://gcc.gnu.org/PR61146 it is stated
that GMP removed the casts in 2005.
On May 26, 2014, at 4:26 AM, FX wrote:
>> So changing just 2 of them doesn't feel right to me…
>
> [Again, with the patch actually attached… sorry]
>
> Here’s a patch that rem
On Tue, 2014-05-27 at 20:07 +0200, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 09:25:37PM -0500, Peter Bergner wrote:
> > In one of my other posts, I asked should 32-bit ports even attempt
> > to use the 2 * word_size atomics. What is the code doing such that
> > it wants to use a 2 * word_size
Hi,
the attached patch implements the idea in
https://gcc.gnu.org/ml/fortran/2013-04/msg00258.html ; though it
turned out it was much simpler than what I envisaged back then. With
this patch, we no longer seek back and forth when writing small
records with sequential unformatted, which previously
Almost 4 years ago I installed the following patch:
2010-11-28 Eric Botcazou
* gnat.dg/aliasing2.adb (dg-final): Robustify pattern matching.
* gnat.dg/pack9.adb (dg-final): Likewise.
and somehow missed gnat.dg/aliasing1.adb which needs the same treatment.
Tested on x86_64-sus
On May 27, 2014, at 11:16 AM, Konstantin Serebryany
wrote:
> On Tue, May 27, 2014 at 9:53 PM, Mike Stump wrote:
>>
>> On May 26, 2014, at 10:13 PM, Konstantin Serebryany
>> wrote:
On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote:
> Because this is my default reply to an
This is an old bug in div_and_round_double for ROUND_DIV_EXPR: when the code
detects that it needs to adjust the quotient, it needs to decide whether it
increases or decreases it by 1. This only depends on the expected sign of the
quotient, but the test reads:
if (*hquo < 0)
So if
>
> Sadly this doesn't appear to have fixed the issue.
I have now reproduced it on AIX. We die at:
/* Sanity check user variables for flag changes. */
if (sect->named.decl != NULL
&& DECL_P (sect->named.decl)
&& decl != sect->named.decl)
On Tue, May 27, 2014 at 01:35:16PM -0600, Jeff Law wrote:
> On 05/26/14 08:01, Marek Polacek wrote:
> >@@ -3114,7 +3120,8 @@ convert_arguments (location_t loc, vec
> >arg_loc, tree typelist,
> >
> > if (type == error_mark_node || !COMPLETE_TYPE_P (type))
> > {
> >- error ("t
On 05/26/14 08:01, Marek Polacek wrote:
This patch introduces $subject, so if the warning says "passing
argument N of X", the caret points to actual argument and not
to function decl. So e.g.:
pr56724-2.c:23:17: warning: passing argument 3 of ‘foo_sc’ from incompatible
pointer type
foo_sc (
On 05/27/2014 05:33 PM, Ilya Verbin wrote:
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 in
On Tue, 27 May 2014, Ramana Radhakrishnan wrote:
> > Beforehand the code fragment in question produced was:
> >
> > .L14:
> > sub r1, r3, #16
> > add r3, r3, #16
> > vld1.8 {q8}, [r1]
>
> vld1 allows a misaligned load.
Can you point me at the relevant piece of
On 05/26/14 06:28, Olivier Hainque wrote:
Hello,
This is a follow up on a thread started long ago there:
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00967.html
With a first followup and a patch proposal there:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00731.html
Then a refinement s
On Tue, May 27, 2014 at 9:53 PM, Mike Stump wrote:
>
> On May 26, 2014, at 10:13 PM, Konstantin Serebryany
> wrote:
>>> On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote:
Because this is my default reply to any such case. :)
>>>
>>> I hope that is a humorous reply and not a ser
On May 27, 2014, at 4:57 AM, Pedro Alves wrote:
> This patch teaches g++ to try to demangle any symbol it
> generates/mangles, when checking is enabled in the build
I like this strategy. :-)
Jan Hubicka writes:
>> This patch broke Solaris bootstrap:
>>
>> /vol/gcc/src/hg/trunk/local/gcc/config/sol2.c: In function 'void
>> solaris_elf_asm_comdat_section(const char*, unsigned int, tree)':
>> /vol/gcc/src/hg/trunk/local/gcc/config/sol2.c:213:17: error:
>> 'decl_comdat_group' was not
> 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?
>
> Conve
On Mon, May 26, 2014 at 09:25:37PM -0500, Peter Bergner wrote:
> In one of my other posts, I asked should 32-bit ports even attempt
> to use the 2 * word_size atomics. What is the code doing such that
> it wants to use a 2 * word_size atomic? Is it as simple as commenting
> that code out for 32-b
On May 27, 2014, at 1:04 AM, Rainer Orth wrote:
> It's been a week since I've submitted the patch, so far having received
> approval for the testsuite parts only.
So, I read the doc bits, and they look fine. I’m not a doc reviewer, but, the
changes are usual and customary for a port, and trivia
On May 26, 2014, at 10:13 PM, Konstantin Serebryany
wrote:
>> On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote:
>>> Because this is my default reply to any such case. :)
>>
>> I hope that is a humorous reply and not a serious one.
>
> Not really humorous. Our position is and alwa
>
> This patch broke Solaris bootstrap:
>
> /vol/gcc/src/hg/trunk/local/gcc/config/sol2.c: In function 'void
> solaris_elf_asm_comdat_section(const char*, unsigned int, tree)':
> /vol/gcc/src/hg/trunk/local/gcc/config/sol2.c:213:17: error:
> 'decl_comdat_group' was not declared in this scope
>
On 05/26/14 13:21, Richard Sandiford wrote:
If we're going to change it, then clearly the docs need to change and
ideally we'd statically check the port's constraints during the build
process to ensure they meet the tighter definition.
OK, how does this look? I built a cc1 for one target per c
On Tue, May 27, 2014 at 9:39 PM, Yuri Gribov wrote:
>> Asan and kasan are very different, so it would be good to separate
>> them straight away.
>
> Do you mean separation of interfaces (i.e. have -fsanitize=address and
> -fsanitize=kernel-address but use same code in GCC to compile both
> maybe w
> Asan and kasan are very different, so it would be good to separate
> them straight away.
Do you mean separation of interfaces (i.e. have -fsanitize=address and
-fsanitize=kernel-address but use same code in GCC to compile both
maybe with different default options) or separation of
implementation
This is OK. Thanks! Do you need someone to commit it for you?
> +MULTILIB_OPTIONS= mg10 m64bit-doubles
> +MULTILIB_DIRNAMES = g10 64-bit-double
I assume this should be "doubles" not "double" though...
> On Tue, 2014-05-27 at 17:49 +0100, Richard Sandiford wrote:
>
> > > It didn't fix the build for me. I still got this failure after that
> > > patch:
> > >
> > > /local/home/sellcey/nightly/src/gcc/gcc/config/mips/mips.c: In function
> > > 'void mips_start_unique_function(const char*)':
> > > /l
On 05/27/2014 09:48 AM, Jeff Law wrote:
>> leaofs(base, index, scale), %eax
>> ...
>> call*0(%eax)
>>
>> we might as well include the memory load
>>
>> movofs(base, index, scale), %eax
>> ...
>> call*%eax
> Ok. My misunderstanding.
>
> Granted, this probabl
I don't think this is the right place for the fix; why do we have a
dummy object at all? Doesn't maybe_dummy_object return
current_class_ref in this situation?
Jason
On Tue, 2014-05-27 at 17:49 +0100, Richard Sandiford wrote:
> > It didn't fix the build for me. I still got this failure after that
> > patch:
> >
> > /local/home/sellcey/nightly/src/gcc/gcc/config/mips/mips.c: In function
> > 'void mips_start_unique_function(const char*)':
> > /local/home/sellce
> Thanks. I still need approval for the doc and build parts, as well
> as the Darwin and DJGPP changes. For the latter two, I've included
> the
I'll approve the DJGPP change, despite the segv. I suspect it's
unrelated.
On Tue, 27 May 2014, Richard Earnshaw wrote:
> > Afterwards it is:
> >
> > .L14:
> > vldrd16, [r3, #-16]
> > vldrd17, [r3, #-8]
> > add r3, r3, #16
> > cmp r3, r1
> > vst1.64 {d16-d17}, [r2:64]!
> > bne .L14
> >
> > and the second VLDR instruction trap
On Tue, May 27, 2014 at 9:43 AM, Konstantin Serebryany
wrote:
> On Tue, May 27, 2014 at 9:40 AM, Yury Gribov wrote:
>>> - using instrumentation via calls adds extra 1.5x-2.x slowdown
>>
>> On x64.
>
> Interesting. can you share your ARM numbers?
>
>>
>>
>>> - it would be nice to have the name pre
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.
>>
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
"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 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
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:
>
>
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 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
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 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
> 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
"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.
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
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
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 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()
Ok, so just the part ok the patch remains to prevent varardic-functions being a
sibling-tail-call remains.
Kai
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
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 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 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
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
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
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!
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 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 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
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 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
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
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 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
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 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: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 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
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, 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
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 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, 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
Richard Sandiford writes:
> Does the following patch help?
Bah, it won't of course: %i1 needs to be the operator.
Richard
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
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 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
- 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
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
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 \
"%{
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
1 - 100 of 151 matches
Mail list logo
