* [PATCH] gcc/ubsan.c: Extend 'pretty_name' space to avoid memory overflow
@ 2014-11-17 2:54 Chen Gang
2014-11-17 7:38 ` Marek Polacek
0 siblings, 1 reply; 6+ messages in thread
From: Chen Gang @ 2014-11-17 2:54 UTC (permalink / raw)
To: Jeff Law; +Cc: Joseph S. Myers, rth, gcc-patches List
According to the next code, 'pretty_name' may need additional bytes more
than 16. For simplify thinking and being extensible in future, extent it
to 256 bytes, directly.
It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
2014-11-17 Chen Gang <gang.chen.5i5j@gmail.com>
* ubsan.c (ubsan_type_descriptor): Extend 'pretty_name' space to
avoid memory overflow.
---
gcc/ubsan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ubsan.c b/gcc/ubsan.c
index 41cf546..12b05cd 100644
--- a/gcc/ubsan.c
+++ b/gcc/ubsan.c
@@ -376,7 +376,7 @@ ubsan_type_descriptor (tree type, enum ubsan_print_style pstyle)
tname = "<unknown>";
/* Decorate the type name with '', '*', "struct", or "union". */
- pretty_name = (char *) alloca (strlen (tname) + 16 + deref_depth);
+ pretty_name = (char *) alloca (strlen (tname) + 256 + deref_depth);
if (pstyle == UBSAN_PRINT_POINTER)
{
int pos = sprintf (pretty_name, "'%s%s%s%s%s%s%s",
--
1.9.3
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gcc/ubsan.c: Extend 'pretty_name' space to avoid memory overflow
2014-11-17 2:54 [PATCH] gcc/ubsan.c: Extend 'pretty_name' space to avoid memory overflow Chen Gang
@ 2014-11-17 7:38 ` Marek Polacek
2014-11-17 8:40 ` Jakub Jelinek
0 siblings, 1 reply; 6+ messages in thread
From: Marek Polacek @ 2014-11-17 7:38 UTC (permalink / raw)
To: Chen Gang; +Cc: Jeff Law, Joseph S. Myers, rth, gcc-patches List
On Mon, Nov 17, 2014 at 06:40:26AM +0800, Chen Gang wrote:
> According to the next code, 'pretty_name' may need additional bytes more
> than 16. For simplify thinking and being extensible in future, extent it
> to 256 bytes, directly.
I think + 128 bytes should be enough for everyone.
Marek
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gcc/ubsan.c: Extend 'pretty_name' space to avoid memory overflow
2014-11-17 7:38 ` Marek Polacek
@ 2014-11-17 8:40 ` Jakub Jelinek
2014-11-17 9:24 ` Marek Polacek
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2014-11-17 8:40 UTC (permalink / raw)
To: Marek Polacek; +Cc: Chen Gang, Jeff Law, Joseph S. Myers, rth, gcc-patches List
On Mon, Nov 17, 2014 at 08:16:32AM +0100, Marek Polacek wrote:
> On Mon, Nov 17, 2014 at 06:40:26AM +0800, Chen Gang wrote:
> > According to the next code, 'pretty_name' may need additional bytes more
> > than 16. For simplify thinking and being extensible in future, extent it
> > to 256 bytes, directly.
>
> I think + 128 bytes should be enough for everyone.
I disagree.
Consider:
typedef char A[1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1];
A a;
int foo (int j)
{
a[j][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0] = 1;
}
You need 1159 bytes in that case. Easily to construct testcase that needs
arbitrary amount.
I think easiest would be to rewrite the code so that it uses pretty_printer
to construct the string, grep asan.c for asan_pp . Or obstacks, but you don't
have a printer to print integers into it easily.
if (dom && TREE_CODE (TYPE_MAX_VALUE (dom)) == INTEGER_CST)
pos += sprintf (&pretty_name[pos], HOST_WIDE_INT_PRINT_DEC,
tree_to_uhwi (TYPE_MAX_VALUE (dom)) + 1);
else
/* ??? We can't determine the variable name; print VLA unspec. */
pretty_name[pos++] = '*';
looks wrong anyway, as not all integers fit into uhwi.
Guess you could use wide_int to add 1 there and pp_wide_int.
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gcc/ubsan.c: Extend 'pretty_name' space to avoid memory overflow
2014-11-17 8:40 ` Jakub Jelinek
@ 2014-11-17 9:24 ` Marek Polacek
2014-11-17 11:42 ` Chen Gang
0 siblings, 1 reply; 6+ messages in thread
From: Marek Polacek @ 2014-11-17 9:24 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Chen Gang, Jeff Law, Joseph S. Myers, rth, gcc-patches List
On Mon, Nov 17, 2014 at 08:38:19AM +0100, Jakub Jelinek wrote:
> On Mon, Nov 17, 2014 at 08:16:32AM +0100, Marek Polacek wrote:
> > On Mon, Nov 17, 2014 at 06:40:26AM +0800, Chen Gang wrote:
> > > According to the next code, 'pretty_name' may need additional bytes more
> > > than 16. For simplify thinking and being extensible in future, extent it
> > > to 256 bytes, directly.
> >
> > I think + 128 bytes should be enough for everyone.
>
> I disagree.
> Consider:
> typedef char A[1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1];
> A a;
>
> int foo (int j)
> {
> a[j][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0] = 1;
> }
> You need 1159 bytes in that case. Easily to construct testcase that needs
> arbitrary amount.
Ah, I haven't looked at the UBSAN_PRINT_ARRAY case.
> I think easiest would be to rewrite the code so that it uses pretty_printer
> to construct the string, grep asan.c for asan_pp . Or obstacks, but you don't
> have a printer to print integers into it easily.
> if (dom && TREE_CODE (TYPE_MAX_VALUE (dom)) == INTEGER_CST)
> pos += sprintf (&pretty_name[pos], HOST_WIDE_INT_PRINT_DEC,
> tree_to_uhwi (TYPE_MAX_VALUE (dom)) + 1);
> else
> /* ??? We can't determine the variable name; print VLA unspec. */
> pretty_name[pos++] = '*';
> looks wrong anyway, as not all integers fit into uhwi.
> Guess you could use wide_int to add 1 there and pp_wide_int.
Ok.
Marek
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gcc/ubsan.c: Extend 'pretty_name' space to avoid memory overflow
2014-11-17 9:24 ` Marek Polacek
@ 2014-11-17 11:42 ` Chen Gang
2014-11-20 15:34 ` Chen Gang
0 siblings, 1 reply; 6+ messages in thread
From: Chen Gang @ 2014-11-17 11:42 UTC (permalink / raw)
To: Marek Polacek, Jakub Jelinek
Cc: Jeff Law, Joseph S. Myers, rth, gcc-patches List
What you said sound reasonable to me.
I shall try to send patch v2 within this week (use pretty_printer).
Thanks.
On 11/17/14 16:15, Marek Polacek wrote:
> On Mon, Nov 17, 2014 at 08:38:19AM +0100, Jakub Jelinek wrote:
>> On Mon, Nov 17, 2014 at 08:16:32AM +0100, Marek Polacek wrote:
>>> On Mon, Nov 17, 2014 at 06:40:26AM +0800, Chen Gang wrote:
>>>> According to the next code, 'pretty_name' may need additional bytes more
>>>> than 16. For simplify thinking and being extensible in future, extent it
>>>> to 256 bytes, directly.
>>>
>>> I think + 128 bytes should be enough for everyone.
>>
>> I disagree.
>> Consider:
>> typedef char A[1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][
1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1];
>> A a;
>>
>> int foo (int j)
>> {
>> a[j][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0] = 1;
>> }
>> You need 1159 bytes in that case. Easily to construct testcase that needs
>> arbitrary amount.
>
> Ah, I haven't looked at the UBSAN_PRINT_ARRAY case.
>
>> I think easiest would be to rewrite the code so that it uses pretty_printer
>> to construct the string, grep asan.c for asan_pp . Or obstacks, but you don't
>> have a printer to print integers into it easily.
>> if (dom && TREE_CODE (TYPE_MAX_VALUE (dom)) == INTEGER_CST)
>> pos += sprintf (&pretty_name[pos], HOST_WIDE_INT_PRINT_DEC,
>> tree_to_uhwi (TYPE_MAX_VALUE (dom)) + 1);
>> else
>> /* ??? We can't determine the variable name; print VLA unspec. */
>> pretty_name[pos++] = '*';
>> looks wrong anyway, as not all integers fit into uhwi.
>> Guess you could use wide_int to add 1 there and pp_wide_int.
>
> Ok.
>
> Marek
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gcc/ubsan.c: Extend 'pretty_name' space to avoid memory overflow
2014-11-17 11:42 ` Chen Gang
@ 2014-11-20 15:34 ` Chen Gang
0 siblings, 0 replies; 6+ messages in thread
From: Chen Gang @ 2014-11-20 15:34 UTC (permalink / raw)
To: Marek Polacek, Jakub Jelinek
Cc: Jeff Law, Joseph S. Myers, rth, gcc-patches List
On 11/17/14 18:52, Chen Gang wrote:
>
> What you said sound reasonable to me.
>
> I shall try to send patch v2 within this week (use pretty_printer).
>
> Thanks.
>
> On 11/17/14 16:15, Marek Polacek wrote:
>> On Mon, Nov 17, 2014 at 08:38:19AM +0100, Jakub Jelinek wrote:
>>
>>> I think easiest would be to rewrite the code so that it uses pretty_printer
>>> to construct the string, grep asan.c for asan_pp . Or obstacks, but you don't
>>> have a printer to print integers into it easily.
>>> if (dom && TREE_CODE (TYPE_MAX_VALUE (dom)) == INTEGER_CST)
>>> pos += sprintf (&pretty_name[pos], HOST_WIDE_INT_PRINT_DEC,
>>> tree_to_uhwi (TYPE_MAX_VALUE (dom)) + 1);
>>> else
>>> /* ??? We can't determine the variable name; print VLA unspec. */
>>> pretty_name[pos++] = '*';
>>> looks wrong anyway, as not all integers fit into uhwi.
>>> Guess you could use wide_int to add 1 there and pp_wide_int.
I have finish use pretty_print instead of normal sprintf, but for above
case, after I tried to use wide_int, it can not pass testsuite, please
help check whether what I have done is correct or not:
For "make check-gcc RUNTESTFLAGS=ubsan.exp".
- Simply replace is OK:
pp_printf (&pretty_name, HOST_WIDE_INT_PRINT_DEC,
tree_to_uhwi (TYPE_MAX_VALUE (dom)) + 1);
- But use pp_wide_int for wide_int, will cause issue:
pp_wide_int(&pretty_name, wi::add (wi::max_value (dom), 1),
TYPE_SIGN (TREE_TYPE (dom)));
- The related issues are:
Running /upstream/gcc-new-x86/gcc/testsuite/gcc.dg/ubsan/ubsan.exp ...
FAIL: c-c++-common/ubsan/bounds-2.c -O0 output pattern test
FAIL: c-c++-common/ubsan/bounds-2.c -O1 output pattern test
FAIL: c-c++-common/ubsan/bounds-2.c -O2 output pattern test
FAIL: c-c++-common/ubsan/bounds-2.c -O3 -fomit-frame-pointer output pattern test
FAIL: c-c++-common/ubsan/bounds-2.c -O3 -fomit-frame-pointer -funroll-loops output pattern test
FAIL: c-c++-common/ubsan/bounds-2.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions output pattern test
FAIL: c-c++-common/ubsan/bounds-2.c -O3 -g output pattern test
FAIL: c-c++-common/ubsan/bounds-2.c -Os output pattern test
FAIL: c-c++-common/ubsan/bounds-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test
FAIL: c-c++-common/ubsan/bounds-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -O0 output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -O1 output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -O2 output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -O3 -fomit-frame-pointer output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -O3 -fomit-frame-pointer -funroll-loops output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -O3 -g output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -Os output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test
FAIL: c-c++-common/ubsan/bounds-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -O0 output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -O1 output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -O2 output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -O3 -fomit-frame-pointer output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -O3 -fomit-frame-pointer -funroll-loops output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -O3 -g output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -Os output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test
FAIL: c-c++-common/ubsan/bounds-7.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-11-20 15:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-17 2:54 [PATCH] gcc/ubsan.c: Extend 'pretty_name' space to avoid memory overflow Chen Gang
2014-11-17 7:38 ` Marek Polacek
2014-11-17 8:40 ` Jakub Jelinek
2014-11-17 9:24 ` Marek Polacek
2014-11-17 11:42 ` Chen Gang
2014-11-20 15:34 ` Chen Gang
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).