On 01/15/2016 06:53 PM, vivek pandya wrote:
Hello GCC Developers,
Are 'Profile Guided Code Positioning' algorithms mentioned in
http://dl.acm.org/citation.cfm?id=93550 this paper ( Pettis and Hanse
) implemented in gcc ?
If yes kindly help me with code file location in gcc source tree.
There's
On 01/15/2016 08:44 PM, vivek pandya wrote:
Thanks Yury for
https://gcc.gnu.org/ml/gcc-patches/2011-09/msg01440.html this link.
It implements procedure reordering as linker plugin.
I have some questions :
1 ) Can you point me to some documentation for "how to write plugin
for linkers " I am I hav
On 05/11/2016 04:18 PM, Martin Liška wrote:
Hello.
I've been working on use-after-scope sanitizer enablement in the GCC compiler
([1]) and
as I've read following submit request ([2]), the LLVM compiler started to
utilize following option:
-mllvm -asan-use-after-scope=1
My initial attempt was
code whereas it would be great if ARM backend
could improve generic RTL code
but it achieves significant improvement on ARM without hurting other
platforms.
So my questions are:
* is this kind of target-specific tweaking acceptable in middle-end?
* if not - what would be a better opt
Andrew wrote:
> Does the patch series at located at:
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01407.html
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01405.html
> Fix this code generation issue? I suspect it does and improves more
> than just the above code.
No, they don't help as is.
-
Andrew wrote:
I think it would good to figure out how to improve this code gen
with the above patches rather than changing asan.
I suspect it might easy to expand them to handle this case too.
True, let me take a closer look and get back to you. When will this is
expected to land in trunk bt
Andrew Pinski wrote:
> Yury Gribov wrote:
>> Andrew Pinski wrote:
>>> Yury Gribov wrote:
>>>> I've recently noticed that GCC generates suboptimal code
>>>> for Asan on ARM targets. E.g. for a 4-byte memory access check
>>>
>>> D
Christophe,
> Indeed, when testing on my laptop, execution tests fail because
> libsanitizer wants to allocated 8GB of memory (I am using qemu as
> execution engine).
Is this 8G of RAM? If yes - I'd be curious to know which part of
libsanitizer needs so much memory.
-Y
Is this 8G of RAM? If yes - I'd be curious to know which part of
libsanitizer needs so much memory.
Here is what I have in gcc.log:
==12356==ERROR: AddressSanitizer failed to allocate 0x21000
(8589938688) bytes at address ff000 (errno: 12)^M
==12356==ReserveShadowMemoryRange failed while
On 07/30/2014 11:56 AM, Richard Biener wrote:
On Tue, Jul 29, 2014 at 8:35 PM, David Malcolm wrote:
>At Cauldron on the Sunday morning there was a Release Management BoF
>session, replacing the specRTL talk (does anyone know what happened to
>the latter?)
>
>One of the topics was bug triage, and
On 08/16/2014 04:37 AM, Manuel López-Ibáñez wrote:
On the compile farm, ASAN tests seem to fail a lot like:
FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern
test, is ==31166==ERROR: AddressSanitizer failed to allocate
0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (
On 08/18/2014 09:42 AM, Yury Gribov wrote:
On 08/16/2014 04:37 AM, Manuel López-Ibáñez wrote:
On the compile farm, ASAN tests seem to fail a lot like:
FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern
test, is ==31166==ERROR: AddressSanitizer failed to allocate
0xdfff0001000
On 08/18/2014 06:36 PM, Alexander Potapenko wrote:
Added Sanitizer folks. Frankly it'd be cool if dumping PIDs and addresses
could be turned off.
Could you please name a reason for that?
Reproducibility?
-Y
On 09/04/2014 11:12 AM, Tom de Vries wrote:
> I ran into this non-reproducible failure while testing a non-bootstrap
> build on x86_64:
> ...
> PASS: g++.dg/ubsan/align-2.C -Os (test for excess errors)
Added UBSan folks.
Can this be related to http://llvm.org/bugs/show_bug.cgi?id=20721 ? It
On 09/09/2014 10:51 AM, VandeVondele Joost wrote:
> Attached is an extended version of the patch,
> it brings a 100% improvement in make -j32 -k check-gcc
First of all, many thanks for working on this.
+# ls -1 | ../../../contrib/generate_tcl_patterns.sh 300
"dg.exp=gfortran.dg/"
How does t
On 09/09/2014 06:14 PM, VandeVondele Joost wrote:
I certainly don't want to claim that the patch I have now is perfect,
it is rather an incremental improvement on the current setup.
I'd second this. Writing patterns manually seems rather inefficient and
error-prone
(not undoable of course but
On 09/09/2014 06:33 PM, Jakub Jelinek wrote:
On Tue, Sep 09, 2014 at 06:27:10PM +0400, Yury Gribov wrote:
On 09/09/2014 06:14 PM, VandeVondele Joost wrote:
I certainly don't want to claim that the patch I have now is perfect,
it is rather an incremental improvement on the current setup.
Hi all,
Kernel Asan patches are currently being discussed in LKML. One of the
points raised during review was that KAsan requires GCC 5.0 which is
presumably unstable (e.g. compilation of kernel modules has been broken
for two months due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848).
On 09/18/2014 01:57 PM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
Kernel Asan patches are currently being discussed in LKML. One of the points
raised during review was that KAsan requires GCC 5.0 which is presumably
unstable (e.g. compilation of kernel
Hi all,
Current semantics of memory constraints in GCC inline asm (i.e. "m",
"v", etc.) is somewhat loosy in that it tells GCC that asm code _may_
access given amount of bytes but is not guaranteed to do so. This is
(ab)used by e.g. glibc (and also some pieces of kernel):
__STRING_INLINE void
On 09/18/2014 03:09 PM, Yury Gribov wrote:
Hi all,
Current semantics of memory constraints in GCC inline asm (i.e. "m",
"v", etc.) is somewhat loosy in that it tells GCC that asm code _may_
access given amount of bytes but is not guaranteed to do so. This is
(ab)used by
On 09/18/2014 03:16 PM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 03:09:34PM +0400, Yury Gribov wrote:
Current semantics of memory constraints in GCC inline asm (i.e. "m", "v",
etc.) is somewhat loosy in that it tells GCC that asm code _may_ access
given amount of bytes b
On 09/18/2014 05:36 PM, Jeff Law wrote:
On 09/18/14 05:19, Yury Gribov wrote:
Would that modifier mean that the inline asm is unconditionally reading
resp. writing that memory? "m"/"=m" right now is always about might
read or might write, not must.
Yes, that's what I
On 09/18/2014 09:33 PM, Dmitry Vyukov wrote:
What is the number of cases it will fix for kasan?
Re-added kernel people again.
AFAIR silly instrumentation that assumed all memory accesses in inline
asm are must-accesses (instead of may-accesses) resulted in only one
false positive. We haven't
On 09/24/2014 12:31 PM, Richard Biener wrote:
On Wed, Sep 24, 2014 at 9:43 AM, David Wohlferd wrote:
Hans-Peter Nilsson: I should have listened to you back when you raised
concerns about this. My apologies for ever doubting you.
In summary:
- The "trick" in the docs for using an arbitrarily
On 09/30/2014 07:15 PM, Christophe Lyon wrote:
Hello,
After I've recently enabled Address Sanitizer for AArch64 in GCC, I'd
like to enable Leak Sanitizer.
I'd like to know what are the requirements wrt testing it? IIUC there
are no lsan tests in the GCC testsuite so far.
Should I just test a f
On 10/01/2014 10:39 PM, Kostya Serebryany wrote:
On Wed, Oct 1, 2014 at 11:38 AM, Toon Moene wrote:
On 10/01/2014 08:00 PM, Kostya Serebryany wrote:
-gcc folks.
Why not use clang then?
It offers many more nice features.
What's the Fortran front-end called for clang (or do you really think
On 10/02/2014 11:35 AM, Jakub Jelinek wrote:
On Thu, Oct 02, 2014 at 11:30:50AM +0400, Yury Gribov wrote:
On 10/01/2014 10:39 PM, Kostya Serebryany wrote:
On Wed, Oct 1, 2014 at 11:38 AM, Toon Moene wrote:
On 10/01/2014 08:00 PM, Kostya Serebryany wrote:
-gcc folks.
Why not use clang then
On 10/06/2014 03:09 PM, Daniel Doron wrote:
Hi,
I am sending this bug report here because I can't register an account
in bugzilla...
gcc version: gcc-linaro-4.9-2014.09 (I checked also the main repo git,
the code is the same)
kernel: 2.6.37
"home/daniel/Downloads/.build/src/gcc-custom/libsanit
On 09/18/2014 01:57 PM, Jakub Jelinek wrote:
> On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
>> Kernel Asan patches are currently being discussed in LKML. One of
the points>> raised during review was that KAsan requires GCC 5.0 which
is presumably
>> unstable
On 10/14/2014 03:19 PM, Dmitry Vyukov wrote:
On Tue, Oct 14, 2014 at 3:07 PM, Yury Gribov wrote:
On 09/18/2014 01:57 PM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
Kernel Asan patches are currently being discussed in LKML. One of the
points>>
On 10/30/2014 01:27 PM, Richard Biener wrote:
Well, VRP is not path-insensitive - it is the value-ranges we are able
to retain after removing the ASSERT_EXPRs VRP inserts.
Why can't you do the ASAN optimizations in the VRP transform phase?
I think this is not Asan-specific: Marat's point was t
On 10/30/2014 04:19 PM, Marat Zakirov wrote:
On 10/30/2014 02:32 PM, Jakub Jelinek wrote:
On Thu, Oct 30, 2014 at 02:16:04PM +0300, Yury Gribov wrote:
On 10/30/2014 01:27 PM, Richard Biener wrote:
Well, VRP is not path-insensitive - it is the value-ranges we are able
to retain after removing
On 11/11/2014 05:15 PM, Jakub Jelinek wrote:
There are also some unsafe code in functions
ubsan_expand_si_overflow_addsub_check, ubsan_expand_si_overflow_mul_check
which uses get_range_info to reduce checks number. As seen before vrp usage
for sanitizers may decrease quality of error detection.
[CC-ing sanitizer team.]
On 11/12/2014 08:02 AM, Andrew Pinski wrote:
With some configurations (looks like out of tree testing more than in
tree testing), all of ubsan and asan tests fail due to the
libsanitizer using coloring and that confuses the dejagnu pattern
matching.
Right, we fix new e
On 11/12/2014 11:45 AM, Marek Polacek wrote:
On Wed, Nov 12, 2014 at 11:42:39AM +0300, Yury Gribov wrote:
On 11/11/2014 05:15 PM, Jakub Jelinek wrote:
There are also some unsafe code in functions
ubsan_expand_si_overflow_addsub_check, ubsan_expand_si_overflow_mul_check
which uses
On 11/12/2014 04:26 PM, Jakub Jelinek wrote:
But, if -O0 isn't too slow for them, having unnecessary bloat even at -O2
is bad the same. But not using VRP at all, you are giving up all the cases
where you know something won't overflow because you e.g. sign extend
or zero extend from some smaller
On 11/12/2014 04:26 PM, Jakub Jelinek wrote:
On Wed, Nov 12, 2014 at 12:58:37PM +0300, Yury Gribov wrote:
On 11/12/2014 11:45 AM, Marek Polacek wrote:
On Wed, Nov 12, 2014 at 11:42:39AM +0300, Yury Gribov wrote:
On 11/11/2014 05:15 PM, Jakub Jelinek wrote:
There are also some unsafe code in
On 01/29/2015 08:32 PM, Richard Henderson wrote:
On 01/29/2015 02:08 AM, Paul Shortis wrote:
I've ported GCC to a small 16 bit CPU that has single bit shifts. So I've
handled variable / multi-bit shifts using a mix of inline shifts and calls to
assembler support functions.
The calls to the asm
On 01/30/2015 11:16 AM, Matthew Fortune wrote:
Yury Gribov writes:
On 01/29/2015 08:32 PM, Richard Henderson wrote:
On 01/29/2015 02:08 AM, Paul Shortis wrote:
I've ported GCC to a small 16 bit CPU that has single bit shifts. So
I've handled variable / multi-bit shifts using a mix
On 03/24/2015 03:20 PM, Jonathan Wakely wrote:
On Mon, Mar 23, 2015 at 06:14:30PM -0500, David Kunsman wrote:
Hello, I was just reading through the current projects wiki page and I
noticed how out of date pretty much all of them are. So I was
planning on doing "spring cleaning" by going down th
> Does someone use addresssanitizer in other platform (i386/x64/arm/ppc)
> suffer this problem?
Hi Jean,
Yes, we do see this error on ARM. Full description and suggested patch
are available at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543
I'm curious whether suggested patch is going to wor
> Yes, we do see this error on ARM.
Here is another instance of the same bug:
http://permalink.gmane.org/gmane.comp.debugging.address-sanitizer/531
> Full description and suggested patch are available at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543
> I'm curious whether suggested patch
> Hi Yury, try to use the patch for asan.c to see if it solve your problem.
I tried but unfortunately it did not work for me. Could you try the
patch suggested in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543
(I've attached it) when you have time? This was verified against gcc
testsuite on
> "copy_to_mode_reg (Pmode, XEXP (shadow_mem, 0))" would be more direct.
> But it looks good to me with that change FWIW.
Thanks, Richard. Note that Jakub has proposed an optimized patch on
gcc-patches ML (in Re: [PATCH] Invalid unpoisoning of stack redzones on
ARM).
-Y
> If you're referring to mudflap (Frank Eigler's work),
> ...
> It never reached a point where interoperability across objects with
and without mudflap instrumentation worked
Jeff,
Could you add more details? E.g. I don't see how mudflap
interoperability is different from AdressSanitizer whic
Hi all,
We have recently ran into a performance/code size regression on ARM
targets after transition from GCC 4.7 to GCC 4.8 (this regression is
also present in 4.9).
The following code snippet uses Linux-style compiler barriers to protect
memory writes:
#define barrier() __asm__ __volat
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a good starting point though.
Though with
Richard wrote:
> volatile __asm__("":::"memory")
>
> is a memory barrier and a barrier for other volatile instructions.
AFAIK asm without output arguments is implicitly marked as volatile. So
it may not be needed in barrier() at all.
-Y
>> Asms without outputs are automatically volatile. So there ought be
zero change
>> with and without the explicit use of the __volatile__ keyword.
>
> That’s what the documentation says but it wasn’t actually true
> as of a couple of releases ago, as I recall.
Looks like 2005:
$ git annotate
What is volatile instructions? Can you give us an example?
Check volatile_insn_p. AFAIK there are two classes of volatile instructions:
* volatile asm
* unspec volatiles (target-specific instructions for e.g. protecting
function prologues)
-Y
You must use autoconf 2.65, exactly.
Perhaps we could update
http://gcc.gnu.org/wiki/Regenerating_GCC_Configuration ?
-Y
>> You must use autoconf 2.65, exactly.
> configure.ac:27: error: Please use exactly Autoconf 2.64 instead of 2.69.
Hm...
-Y
53 matches
Mail list logo
