One of the nice features of the ELFv2 ABI is that stack frames are
smaller compared to ELFv1. We don't allocate a parameter save area
unless we actually use it. However, for variable argument lists, we
kept the simple va_list type which is a pointer to the memory location
of the next parameter.
Jan Hubicka hubi...@ucw.cz 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:
+
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 per
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* } } } }
+! {
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
Thomas Preud'homme thomas.preudho...@arm.com 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
Mike Stump mikest...@comcast.net writes:
On May 28, 2014, at 7:27 AM, Richard Earnshaw rearn...@arm.com 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
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
On Wed, May 28, 2014 at 6:49 PM, Mike Stump mikest...@comcast.net wrote:
On May 28, 2014, at 7:27 AM, Richard Earnshaw rearn...@arm.com 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
On 27/05/14 16:07, Richard Sandiford 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 that it worked for simple tests
From: Andreas Schwab [mailto:sch...@linux-m68k.org]
Thomas Preud'homme thomas.preudho...@arm.com 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
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
On Thu, May 29, 2014 at 11:38 AM, Dominique Dhumieres
domi...@lps.ens.fr 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
---
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 doesn't
On Thu, 19 Jul 2012 14:47:54 +0100
Julian Brown jul...@codesourcery.com wrote:
On Thu, 19 Jul 2012 13:54:57 +0100
Paul Brook p...@codesourcery.com wrote:
But, that means EABI-conformant callers are also perfectly
entitled to sign-extend half-float values before calling our
helper
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
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:
:
Richard Earnshaw rearn...@arm.com writes:
On 27/05/14 16:07, Richard Sandiford 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.
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
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 ilya.enkov...@intel.com
* calls.c (special_function_p): Use original
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 ilya.enkov...@intel.com
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
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
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.
Tom de Vries tom_devr...@mentor.com 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
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) \
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
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
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,
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.
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),
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
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
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
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
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
On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 07/11/2011 05:54 PM, H.J. Lu wrote:
The key is the
XEXP (x, 1) ==
On May 29, 2014, at 9:13 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 07/11/2011
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 Thu, May 29, 2014 at 9:23 AM, pins...@gmail.com wrote:
On May 29, 2014, at 9:13 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Jul 13, 2011 at 9:13
Jan Hubicka hubi...@ucw.cz 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
On May 29, 2014, at 10:09 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, May 29, 2014 at 9:23 AM, pins...@gmail.com wrote:
On May 29, 2014, at 9:13 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Jul 13, 2011 at
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
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
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 vmaka...@redhat.com
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 pitchuman...@atmel.com
*
On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote:
Hi!
On Mon, 26 May 2014 18:53:22 +0800, Arseny Solokha asolo...@gmx.com 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
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
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,
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
---
Fixed.
Thanks!
--
Eric Botcazou
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,
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
53 matches
Mail list logo
