Hello,
cgraph_make_wrapper is a new function that creates a simple wrapper of a
function. The function will be used further in identical code folding if a pass
proves that two functions are semantically equivalent.
Bootstrapped and tested on x86_64-linux.
OK for trunk?
Thanks,
Martin
2014-
Hi,
this patch introduces a new function lookup_attribute_starting that can find
all attributes starting with a specified string. Purpose of the function is to
be able to identify e.g. if a function has any 'omp' attribute.
Bootstrapped and tested on x86_64-linux.
OK for trunk?
Thanks,
Mart
Hello,
this patch enhances callgraph API to enable more precise control of
expand_thunk; another function becomes global.
Bootstrapped and tested on x86_64-linux.
OK for trunk?
Thanks,
Martin
2014-05-29 Martin Liska
* cgraph.h (expand_thunk): New argument added.
(address
Hello,
this is a small patchset that prepares API for new IPA Identical code folding
pass. The patch adds an argument for coverage_compute_cfg_checksum.
Bootstrapped and tested on x86_64-linux.
OK for trunk?
Thanks,
Martin
2014-05-29 Martin Liska
* coverage.h (coverage_compute_cf
Jack finally found the answer to a question I had back in 2010… Why, yes, one
does have to arrange to run the post ld pass when lto runs but doesn’t have to
relink.
Committed revision 211067.
Thanks Jack.
PR debug/61352
* collect2.c (maybe_run_lto_and_relink): Be sure
On Wed, 28 May 2014, Richard Earnshaw wrote:
> Ah, light dawns (maybe).
>
> I guess the problems stem from the attempts to combine Neon with ARMv5.
> Neon shouldn't be used with anything prior to ARMv7, since that's the
> earliest version of the architecture that can support it.
Good to know,
> Fixed.
Thanks!
--
Eric Botcazou
This patch from Peter Collingbourne adds a --without-libatomic configure
option to libgo, to make it easier to build libgo outside of the GCC
build system. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 9e7a28ffe425 libgo/Makefile.am
--- a/libg
Hi again,
On 05/29/2014 03:34 PM, Jason Merrill wrote:
On 05/28/2014 01:06 PM, Paolo Carlini wrote:
Now, I got this "insane" idea: would it make sense to simply invert the
substitutions (args and return) unconditionally?
If we're going to change the order, I want to do it in a more correct,
On 05/28/2014 04:32 PM, Richard Sandiford wrote:
> While working on patches to speed up the handling of constraints,
> I hit some behaviour in ira_get_dup_out_num that looked unintentional:
>
> - the check for output operands was part of the !ignored_p condition
> so would be skipped if the first
On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote:
> Hi!
>
> On Mon, 26 May 2014 18:53:22 +0800, Arseny Solokha wrote:
> > Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it
> > impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets.
>
> I hit this, too
Hi,
Device ATA6289 has MUL instruction and it belongs to avr4 ISA.
Now it is incorrectly listed under avr25. Attached patch corrects it.
Please commit if the patch is OK. I do not have commit access.
Regards,
Pitchumani
2014-05-29 Pitchumani Sivanupandi
* config/avr/avr-mcus.def
The following patch PR61325. The details can be found on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61325
The patch was bootstrapped and tested on x86/x86-64.
Committed as rev. 211060 to gcc-4.9 branch and as rev.211061 to trunk.
2014-05-29 Vladimir Makarov
PR rtl-optimizat
I've just committed this as revision 211059, with the change of adding a _1
suffix to the names of all the new tests (as per standard testsuite convention).
All passed on arm-none-eabi and armeb-none-eabi.
Cheers, Alan
Ramana Radhakrishnan wrote:
On Wed, Apr 23, 2014 at 9:32 PM, Alan Lawrence
The _mm_pause intrinsic is defined in xmmintrin.h. Right now using it
with -m32 with the default -march option gives an error:
/home/iant/foo.c: In function ‘f’:
/home/iant/gcc/go-install/lib/gcc/x86_64-unknown-linux-gnu/4.10.0/include/xmmintrin.h:1238:1:
error: inlining failed in call to always
> On May 29, 2014, at 10:09 AM, "H.J. Lu" wrote:
>
>> On Thu, May 29, 2014 at 9:23 AM, wrote:
>>
>>
On May 29, 2014, at 9:13 AM, "H.J. Lu" wrote:
> On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
>> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
>>> On Wed,
> Jan Hubicka writes:
> >> Richard Sandiford wrote the original section anchors implementation,
> >> so he would be a good person to comment about the interaction between
> >> aliases and section anchors.
> >
> > Thanks! Richard, does this patch seem sane?
>
> Looks good to me in principle, but w
On Thu, May 29, 2014 at 9:23 AM, wrote:
>
>
>> On May 29, 2014, at 9:13 AM, "H.J. Lu" wrote:
>>
>>> On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
> On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
>> On 07/11/2011 05:54
Patch retaining vfmaq_n_f64 attached, updated gcc/ChangeLog:
* config/aarch64/arm_neon.h (vmlaq_n_f64, vmlsq_n_f64, vrsrtsq_f64,
vcge_p8, vcgeq_p8, vcgez_p8, vcgez_u8, vcgez_u16, vcgez_u32, vcgez_u64,
vcgezq_p8, vcgezq_u8, vcgezq_u16, vcgezq_u32, vcgezq_u64, vcgezd_u64,
> On May 29, 2014, at 9:13 AM, "H.J. Lu" wrote:
>
>> On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
>>> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
> On 07/11/2011 05:54 PM, H.J. Lu wrote:
>
> The key is the
>
On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
>> On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
>>> On 07/11/2011 05:54 PM, H.J. Lu wrote:
The key is the
>
> XEXP (x, 1) == convert_memory_address_addr_space
Hi all,
I noticed that in some of our move patterns the movw instruction is given the
mov_reg type rather than the
mov_imm type that all other uses of movw have. This patch fixes that.
Scanning through our pipeline descriptions I see that mov_imm is treated the
same way as mov_reg everywhere a
On 26/05/14 19:19 +0400, Konstantin Serebryany wrote:
It does look useful but I'm concerned about a proliferation of
container checks, we already have the libstdc++ Debug Mode
and I'd
like to see some of the lightweight checks from the Google branch
added to trunk too.
Me too, but these checks a
Hi Honza,
I can confirm that with your commit r211045 the
arm-none-linux-gnueabi{hf} builds are OK now. Thanks for the fix.
Yufeng
On 05/28/14 22:56, Jan Hubicka wrote:
Any update?
I've managed to generate a simple test case from
libstdc++-v3/src/c++98/strstream.cc which reproduces the iss
Hi,
On 05/29/2014 03:34 PM, Jason Merrill wrote:
On 05/28/2014 01:06 PM, Paolo Carlini wrote:
Now, I got this "insane" idea: would it make sense to simply invert the
substitutions (args and return) unconditionally?
If we're going to change the order, I want to do it in a more correct,
rather
On 05/28/2014 01:06 PM, Paolo Carlini wrote:
Now, I got this "insane" idea: would it make sense to simply invert the
substitutions (args and return) unconditionally?
If we're going to change the order, I want to do it in a more correct,
rather than differently wrong, way. DR 1227 clarified th
The fact that some region appears in "m"
doesn't mean the inline asm actually accesses it, it could not touch it at
all, or only some part of it.
Do we have precise semantics of "m" written somewhere?
My understanding was that even though asm may not touch buffer at all
(like e.g. in our tests)
This adds another set of qualifiers to aarch64-builtins.c, and removes more
casts from arm_neon.h, for the suqadd, ushl, urshl, urshr_n, ushll_n, and sshl
intrinsics.
gcc/ChangeLog:
* gcc/config/aarch64/aarch64-builtins.c
(aarch64_types_binop_ssu_qualifiers): New static data.
This adds three new sets of qualifiers to aarch64-builtins.c, and uses the
already-present-but-unused USHIFTIMM.
gcc/ChangeLog:
* gcc/config/aarch64/aarch64-builtins.c
(aarch64_types_binop_uus_qualifiers,
aarch64_types_shift_to_unsigned_qualifiers,
aarch64_types_
The __builtin_ functions registered by aarch64_init_simd_builtins use signed
and/or unsigned types according to the qualifiers defined in aarch64-builtins.c
and used in aarch64-simd-builtins.def. These __builtin functions are then used
in arm_neon.h, with explicit casts converting between the si
On 05/29/14 06:07, Richard Sandiford wrote:
Can't really approve it, but it looks obviously correct to me.
Thanks for the fix.
Is that something you'd like to see changed?
Jeff
On 05/29/14 05:27, Tom de Vries wrote:
On 10-05-14 22:24, Richard Sandiford wrote:
/* A set of flags on a symbol_ref that are, in some respects,
redundant with
information derivable from the tree decl associated with this
symbol.
@@ -1791,7 +1794,9 @@ #define SYMBOL_REF_CONSTANT(RTX) \
Tom de Vries writes:
> On 10-05-14 22:24, Richard Sandiford wrote:
>> /* A set of flags on a symbol_ref that are, in some respects, redundant
>> with
>> information derivable from the tree decl associated with this symbol.
>> @@ -1791,7 +1794,9 @@ #define SYMBOL_REF_CONSTANT(RTX) \
>>
On 05/29/2014 11:22 AM, Eric Botcazou wrote:
>> Yes. We already know that this is better than the current docs.
>> Let's check it in.
>
> As far as I can see you did it, but didn't add a ChangeLog entry (so David
> isn't properly credited with the rewrite)?
Fixed.
Thanks,
Andrew.
On 10-05-14 22:24, Richard Sandiford wrote:
/* A set of flags on a symbol_ref that are, in some respects, redundant with
information derivable from the tree decl associated with this symbol.
@@ -1791,7 +1794,9 @@ #define SYMBOL_REF_CONSTANT(RTX) \
this information to avoid recomputing
Actually I do not think that this is good idea to use constraints in a such
arbitrary way. By setting constraints user takes responsibility on himself.
So even if full inline asm support will be done one day, I do think that
checking memory constraints will be still exist.
It is the same situation
Hi,
This patch allows to perform function versioning when some structures are not
available yet. It is required to make clones for Pointer Bounds Checker right
after SSA build.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2014-05-29 Ilya Enkovich
* tree-inline.c
Hi,
This patch allows to recognize instrumented call to special function by using
the original function name for recognition.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2014-05-29 Ilya Enkovich
* calls.c (special_function_p): Use original decl name
when a
Hi,
This patch tries to keep bounds initial values when it may be needed. Even if
initial value is not fully known (e.g. we know only low bound) it still may
help to remove some redundant checks.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2013-05-29 Ilya Enkovich
Richard Earnshaw writes:
> On 27/05/14 16: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:
>
>> asm-struct-1.c test looks like a false positive though - the code does not
>> access any invalid memory, it only does a harmless pointer cast.
It is not. Because st1 have smaller size than st2:
struct st1 {
int a[110];
}
struct st2 {
int a[111];
};
And asm constrain was declared as:
> Yes. We already know that this is better than the current docs.
> Let's check it in.
As far as I can see you did it, but didn't add a ChangeLog entry (so David
isn't properly credited with the rewrite)?
--
Eric Botcazou
On Thu, 19 Jul 2012 14:47:54 +0100
Julian Brown wrote:
> On Thu, 19 Jul 2012 13:54:57 +0100
> Paul Brook wrote:
>
> > > But, that means EABI-conformant callers are also perfectly
> > > entitled to sign-extend half-float values before calling our
> > > helper functions (although GCC itself won't
On Wed, May 28, 2014 at 05:33:44PM +0400, Marat Zakirov wrote:
> Here's a patch for optional Asan instrumentation of inline assembly.
>
> This version scans gimple for GIMPLE_ASMs and performs usual instrumentation
> of arguments with memory constraints ("m", "o", etc.) with fixed size.
That does
On Thu, May 29, 2014 at 11:38 AM, Dominique Dhumieres
wrote:
>> Probably, alpha is not the only one that fails this assumption.
>
> Indeed! see the thread starting at
> https://gcc.gnu.org/ml/fortran/2014-05/msg00127.html
>
> Could you test the following patch
>
> --- ../_clean/gcc/testsuite/gfort
Cool, we don't have this in LLVM-ASan, but we have plans to instrument
inline asm soon (not just constraints).
asm-struct-1.c test looks like a false positive though - the code does
not access any invalid memory, it only does a harmless pointer cast.
On Wed, May 28, 2014 at 10:36 PM, Konstantin
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> "Thomas Preud'homme" writes:
>
> > By the way, I couldn't understand how you reached the value
> > 0x44434241. Can you explain me?
>
> Each byte is composed of the first 7 bits of the original byte.
Sorry, it seems I wasn't very awake when
On 27/05/14 16: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:
>
> int f1 (int x, int y) { return
On Wed, May 28, 2014 at 6:49 PM, Mike Stump wrote:
> On May 28, 2014, at 7:27 AM, Richard Earnshaw wrote:
>>
>> Speed of implementation. We're gradually replacing these with proper
>> builtins, but that takes a lot more work.
>
> As an owner of a port with more builtins that yours, I can offer a
> Probably, alpha is not the only one that fails this assumption.
Indeed! see the thread starting at
https://gcc.gnu.org/ml/fortran/2014-05/msg00127.html
Could you test the following patch
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
2014-05-24 16:17:53.0 +020
Mike Stump writes:
> On May 28, 2014, at 7:27 AM, Richard Earnshaw wrote:
> >
> > Speed of implementation. We're gradually replacing these with proper
> > builtins, but that takes a lot more work.
>
> As an owner of a port with more builtins that yours, I can offer a
> technological solution to
"Thomas Preud'homme" writes:
> By the way, I couldn't understand how you reached the value
> 0x44434241. Can you explain me?
Each byte is composed of the first 7 bits of the original byte.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 4
On 29-05-14 00:42, Bill Schmidt wrote:
Tom, the final version of this patch that you committed breaks bootstrap
on powerpc64le-linux-gnu. The problem is that all uses of the variable
i are guarded by #ifdef STACK_REGS, but the declaration of i is
unconditional. We get an unused variable warning
Hello!
> With the following patch, gfortran can be regtested with -flto
> with no failure, but pr54852 and pr60061.
-! { dg-final { scan-assembler-times "myBindC" 1 { target { ! {
hppa*-*-hpux* } } } } }
-! { dg-final { scan-assembler-times "myBindC,%r2" 1 { target {
hppa*-*-hpux* } } } }
+! { dg
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
>
> This adds a full byte of padding between each bitfield. If you want a
> single padding bit you should use :1, but you also need to update the
> test to check for 0x44434241 (0x88868482 is impossible, since that
> requires at least 8 bits p
Jan Hubicka writes:
>> Richard Sandiford wrote the original section anchors implementation,
>> so he would be a good person to comment about the interaction between
>> aliases and section anchors.
>
> Thanks! Richard, does this patch seem sane?
Looks good to me in principle, but with:
> + s
56 matches
Mail list logo
