public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/61978] New: implement blacklist for sanitizer
@ 2014-07-31 16:27 gcc at dpinol dot com
2014-07-31 20:34 ` [Bug sanitizer/61978] " jakub at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: gcc at dpinol dot com @ 2014-07-31 16:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
Bug ID: 61978
Summary: implement blacklist for sanitizer
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at dpinol dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
clang has a -fsanitize-blacklist for this
thanks
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug sanitizer/61978] implement blacklist for sanitizer
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
@ 2014-07-31 20:34 ` jakub at gcc dot gnu.org
2014-08-01 8:28 ` kcc at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-07-31 20:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is intentionally not implemented, you should mark functions you don't want
to sanitize in the source, not on the side, so just use the attribute for it.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug sanitizer/61978] implement blacklist for sanitizer
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
2014-07-31 20:34 ` [Bug sanitizer/61978] " jakub at gcc dot gnu.org
@ 2014-08-01 8:28 ` kcc at gcc dot gnu.org
2014-08-01 10:59 ` gcc at dpinol dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: kcc at gcc dot gnu.org @ 2014-08-01 8:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #2 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Yea. This has been discussed a couple of times before.
using an attribute in the source is clearly the preferable way.
Unfortunately, it is not always technically possible, so we *have* to use the
blacklists.
The major use cases:
a) third_party code that can not be easily modified
b) needs to blacklist an entire source directory
c) blacklist should be applied to a type, not a function
In Chromium we have these:
http://src.chromium.org/viewvc/chrome/trunk/src/tools/memory/tsan_v2/ignores.txt?revision=279695
http://src.chromium.org/viewvc/chrome/trunk/src/tools/msan/blacklist.txt?revision=284946
http://src.chromium.org/viewvc/chrome/trunk/src/tools/ubsan_vptr/blacklist.txt?revision=285951
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/instrumented_libraries/blacklists/asan/libglib2.0-0.txt?revision=282959
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/instrumented_libraries/blacklists/msan/libx11-6.txt?revision=282959
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug sanitizer/61978] implement blacklist for sanitizer
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
2014-07-31 20:34 ` [Bug sanitizer/61978] " jakub at gcc dot gnu.org
2014-08-01 8:28 ` kcc at gcc dot gnu.org
@ 2014-08-01 10:59 ` gcc at dpinol dot com
2014-08-01 11:02 ` kcc at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: gcc at dpinol dot com @ 2014-08-01 10:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #3 from Daniel Pinol <gcc at dpinol dot com> ---
I agree with Kostya.
I get an error within Qt, and I cannot modify its source code. Another option
would be having a flag for not aborting execution when an error is detected (as
in valgrind)
I tried adding the no_sanitize_address attribute to the method which eventually
calls the problematic function, but it did not work.
Is it possible to reopen a ticket until a solution for these kind of problems
is addressed?
thanks
#if defined(__has_feature)
# if __has_feature(address_sanitizer)
__attribute__((no_sanitize_address))
# endif
#endif
void triggerLang(ReemWindow &win, config::Language const &lang)
==15711==ERROR: AddressSanitizer: global-buffer-overflow on address 0x09de51cc
at pc 0xb7263661 bp 0xbfd89638 sp 0xbfd8961c
READ of size 21 at 0x09de51cc thread T0
#0 0xb7263660 in __interceptor_memcmp
../../.././libsanitizer/asan/asan_interceptors.cc:325
#1 0xb513b25b (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1a925b)
#2 0xb513bffa (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1a9ffa)
#3 0xb513cc7a in QTranslator::translate(char const*, char const*, char
const*) const (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1aac7a)
#4 0xb513cd13 in QTranslator::translate(char const*, char const*, char
const*, int) const (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1aad13)
#5 0xb511bc16 in QCoreApplication::translate(char const*, char const*, char
const*, QCoreApplication::Encoding, int)
(/opt/qtsdk-4.85/lib/libQtCore.so.4+0x189c16)
#6 0xb511c0a9 in QCoreApplication::translate(char const*, char const*, char
const*, QCoreApplication::Encoding)
(/opt/qtsdk-4.85/lib/libQtCore.so.4+0x18a0a9)
#7 0x950803f in Ui_VideoWindow::retranslateUi(QWidget*)
/home/dani/svn/robot/gcc491-sanitizer/src/interaction/gui/touchscreen/ReemH/videoWindow/ui_VideoWindow.h:267
#8 0x94f9cea in
pal::gui::VideoWindow::TriggerLanguageChanged(pal::config::Language const&)
/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/videoWindow/VideoWindow.cpp:146
#9 0x982afe4 in
pal::gui::ReemWidget::triggerLanguageChanged(pal::config::Language const&)
/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemWidget.cpp:476
#10 0x982b18a in
pal::gui::ReemWidget::triggerLanguageChanged(pal::config::Language const&)
/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemWidget.cpp:511
#11 0x92daab5 in pal::gui::triggerLang(pal::gui::ReemWindow&,
pal::config::Language const&)
/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/ReemWindow.cpp:315
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug sanitizer/61978] implement blacklist for sanitizer
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
` (2 preceding siblings ...)
2014-08-01 10:59 ` gcc at dpinol dot com
@ 2014-08-01 11:02 ` kcc at gcc dot gnu.org
2014-08-01 11:06 ` kcc at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: kcc at gcc dot gnu.org @ 2014-08-01 11:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #4 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Note that the blacklist can not disable the checking inside the memcmp
interceptor. But it will disable instrumenting globals in QT, so
if this is a global from QT (you did not post the full log) you will not see
the error.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug sanitizer/61978] implement blacklist for sanitizer
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
` (3 preceding siblings ...)
2014-08-01 11:02 ` kcc at gcc dot gnu.org
@ 2014-08-01 11:06 ` kcc at gcc dot gnu.org
2014-08-01 11:13 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: kcc at gcc dot gnu.org @ 2014-08-01 11:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #5 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Also check if strict_memcmp=0 helps you.
https://code.google.com/p/address-sanitizer/wiki/Flags
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug sanitizer/61978] implement blacklist for sanitizer
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
` (4 preceding siblings ...)
2014-08-01 11:06 ` kcc at gcc dot gnu.org
@ 2014-08-01 11:13 ` jakub at gcc dot gnu.org
2014-08-01 13:17 ` gcc at dpinol dot com
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-01 11:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Daniel Pinol from comment #3)
> #if defined(__has_feature)
> # if __has_feature(address_sanitizer)
> __attribute__((no_sanitize_address))
> # endif
> #endif
> void triggerLang(ReemWindow &win, config::Language const &lang)
is not adding the attribute at all. GCC doesn't support the clangism
__has_feature. Just add the attribute unconditionally, uknown attributes just
cause a warning, and 4.8+ supports that attribute.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug sanitizer/61978] implement blacklist for sanitizer
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
` (5 preceding siblings ...)
2014-08-01 11:13 ` jakub at gcc dot gnu.org
@ 2014-08-01 13:17 ` gcc at dpinol dot com
2014-08-01 14:08 ` kcc at gcc dot gnu.org
2015-04-01 9:43 ` manu at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: gcc at dpinol dot com @ 2014-08-01 13:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #7 from Daniel Pinol <gcc at dpinol dot com> ---
thank you everybody for your great feedback!
@kostya: I provide here the full log. Even removing the #if's, it still aborts.
strict_memcmp=0 worked like a charm. Thanks!
I guess there's no way to just report the errors but not abort execution,
right?
0x09de51cc is located 52 bytes to the left of global variable '*.LC2' from
'/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/videoWindow/VideoWindow.cpp'
(0x9de5200) of size 1
'*.LC2' is ascii string ''
0x09de51cc is located 0 bytes to the right of global variable '*.LC1' from
'/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/videoWindow/VideoWindow.cpp'
(0x9de51c0) of size 12
'*.LC1' is ascii string 'VideoWindow'
SUMMARY: AddressSanitizer: global-buffer-overflow
../../.././libsanitizer/asan/asan_interceptors.cc:325 __interceptor_memcmp
Shadow bytes around the buggy address:
0x213bc9e0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x213bc9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x213bca00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x213bca10: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
0x213bca20: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
=>0x213bca30: 00 00 00 00 00 00 00 00 00[04]f9 f9 f9 f9 f9 f9
0x213bca40: 01 f9 f9 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9
0x213bca50: 00 00 01 f9 f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9
0x213bca60: 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x213bca70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x213bca80: 00 01 f9 f9 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Contiguous container OOB:fc
ASan internal: fe
==19590==ABORTING
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug sanitizer/61978] implement blacklist for sanitizer
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
` (6 preceding siblings ...)
2014-08-01 13:17 ` gcc at dpinol dot com
@ 2014-08-01 14:08 ` kcc at gcc dot gnu.org
2015-04-01 9:43 ` manu at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: kcc at gcc dot gnu.org @ 2014-08-01 14:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
--- Comment #8 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Daniel Pinol from comment #7)
> thank you everybody for your great feedback!
>
> @kostya: I provide here the full log. Even removing the #if's, it still
> aborts. strict_memcmp=0 worked like a charm. Thanks!
Good. Formally this is a bug, but in most cases not a very harmful one.
So, just continue using strict_memcmp=0
>
> I guess there's no way to just report the errors but not abort execution,
> right?
Right, asan exits on first error.
(First entry in FAQ:
https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#FAQ)
>
>
> 0x09de51cc is located 52 bytes to the left of global variable '*.LC2' from
> '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/
> videoWindow/VideoWindow.cpp' (0x9de5200) of size 1
> '*.LC2' is ascii string ''
> 0x09de51cc is located 0 bytes to the right of global variable '*.LC1' from
> '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/
> videoWindow/VideoWindow.cpp' (0x9de51c0) of size 12
> '*.LC1' is ascii string 'VideoWindow'
> SUMMARY: AddressSanitizer: global-buffer-overflow
> ../../.././libsanitizer/asan/asan_interceptors.cc:325 __interceptor_memcmp
> Shadow bytes around the buggy address:
> 0x213bc9e0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
> 0x213bc9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x213bca00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x213bca10: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
> 0x213bca20: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
> =>0x213bca30: 00 00 00 00 00 00 00 00 00[04]f9 f9 f9 f9 f9 f9
> 0x213bca40: 01 f9 f9 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9
> 0x213bca50: 00 00 01 f9 f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9
> 0x213bca60: 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
> 0x213bca70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x213bca80: 00 01 f9 f9 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Heap right redzone: fb
> Freed heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack partial redzone: f4
> Stack after return: f5
> Stack use after scope: f8
> Global redzone: f9
> Global init order: f6
> Poisoned by user: f7
> Contiguous container OOB:fc
> ASan internal: fe
> ==19590==ABORTING
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug sanitizer/61978] implement blacklist for sanitizer
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
` (7 preceding siblings ...)
2014-08-01 14:08 ` kcc at gcc dot gnu.org
@ 2015-04-01 9:43 ` manu at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: manu at gcc dot gnu.org @ 2015-04-01 9:43 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6100 bytes --]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu.org
--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Stewart Martin-Haugh from comment #9)
> Hi,
> I see this marked as WONTFIX - still, the use-cases that Kostya identifies
> are valid, I think. Would anyone be able to implement a patch, or suggest
> roughly how this might work?
Although existing GCC devs may not find this feature interesting enough to
implement it themselves, a nice, small patch properly submitted together with a
convincingly argued rationale may get accepted. It seems this feature is being
used not only by Chromium but also by LibreOffice, and many GCC users would
still like to keep using GCC for building those programs.
Many features that were initially rejected have been later accepted (e.g.,
color diagnostics). It just needs someone to get behind the idea and push for
it in the right way.
>From gcc-bugs-return-482474-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 01 09:44:39 2015
Return-Path: <gcc-bugs-return-482474-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 38388 invoked by alias); 1 Apr 2015 09:44:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 38056 invoked by uid 48); 1 Apr 2015 09:44:35 -0000
From: "terry.guo at arm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65648] New: [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
Date: Wed, 01 Apr 2015 09:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: terry.guo at arm dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-65648-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg00026.txt.bz2
Content-length: 3032
https://gcc.gnu.org/bugzilla/show_bug.cgi?ide648
Bug ID: 65648
Summary: [5 Regression] Bad code due to IRA fails to recognize
the clobber in parallel
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 35200
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id5200&actioníit
test case
When compile attached case with command:
arm-none-eabi-gcc -march=armv6-m -mthumb -Os x.c -S
The gcc generates bad code as below:
main:
push {r0, r1, r2, r4, r5, r6, r7, lr}
ldr r4, .L5
movs r5, #0
ldr r0, [r4, #8]
add r1, sp, #4
rsbs r2, r0, #0
adcs r2, r2, r0
subs r3, r2, r3 //r3 is used but not initialized
The instruction to initialize r3 is removed due to IRA failed to recognize the
clobber in reload pass. Before the reload pass, we have three instructions like
below:
(insn 12 11 14 2 (parallel [
(set (reg:SI 128)
(eq:SI (reg:SI 110 [ D.4914 ])
(const_int 0 [0])))
(clobber (reg:SI 129))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(expr_list:REG_UNUSED (reg:SI 129)
(nil)))
(insn 20 19 22 2 (set (reg:SI 135)
(plus:SI (plus:SI (reg:SI 136)
(reg:SI 137))
(geu:SI (reg:SI 131 [ D.4914 ])
(reg:SI 134 [ c ])))) x.c:23 764 {thumb1_addsi3_addgeu}
(expr_list:REG_DEAD (reg:SI 137)
(expr_list:REG_DEAD (reg:SI 136)
(expr_list:REG_DEAD (reg:SI 134 [ c ])
(expr_list:REG_DEAD (reg:SI 131 [ D.4914 ])
(nil))))))
(insn 22 20 23 2 (set (reg:SI 138)
(minus:SI (reg:SI 128)
(reg:SI 135))) x.c:23 720 {thumb1_subsi3_insn}
(expr_list:REG_DEAD (reg:SI 135)
(expr_list:REG_DEAD (reg:SI 128)
(nil))))
After the reload pass, those instructions are wrongly turned into:
(insn 20 53 58 2 (set (reg:SI 3 r3 [135])
(plus:SI (plus:SI (reg:SI 3 r3 [137])
(reg:SI 2 r2 [136]))
(geu:SI (reg:SI 7 r7 [orig:131 D.4914 ] [131])
(reg:SI 6 r6 [153])))) x.c:23 764 {thumb1_addsi3_addgeu}
(nil))
(insn 58 20 55 2 (parallel [
(set (reg:SI 2 r2 [128])
(eq:SI (reg:SI 0 r0 [orig:110 D.4914 ] [110])
(const_int 0 [0])))
(clobber (reg:SI 3 r3 [129]))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(nil))
(note 55 58 22 2 NOTE_INSN_DELETED)
(insn 22 55 23 2 (set (reg:SI 3 r3 [138])
(minus:SI (reg:SI 2 r2 [128])
(reg:SI 3 r3 [135]))) x.c:23 720 {thumb1_subsi3_insn}
(nil))
However the later pass can recognize the clobber in insn 58 and will remove the
insn 20 because the r3 defined in insn 20 is clobbered by insn 58.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-04-01 9:43 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-31 16:27 [Bug sanitizer/61978] New: implement blacklist for sanitizer gcc at dpinol dot com
2014-07-31 20:34 ` [Bug sanitizer/61978] " jakub at gcc dot gnu.org
2014-08-01 8:28 ` kcc at gcc dot gnu.org
2014-08-01 10:59 ` gcc at dpinol dot com
2014-08-01 11:02 ` kcc at gcc dot gnu.org
2014-08-01 11:06 ` kcc at gcc dot gnu.org
2014-08-01 11:13 ` jakub at gcc dot gnu.org
2014-08-01 13:17 ` gcc at dpinol dot com
2014-08-01 14:08 ` kcc at gcc dot gnu.org
2015-04-01 9:43 ` manu at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).