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
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
> 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, 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
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 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
> 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
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...
> 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
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
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
>
> 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 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
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 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 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
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 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. :-)
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 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, 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/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 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 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
>
> 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)
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
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
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
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
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
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
> 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/
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
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
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 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, 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
> >
... 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, 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]
>
> 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, 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
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, 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 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
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
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
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
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 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
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 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)
101 - 151 of 151 matches
Mail list logo
