Jakub Jelinek writes:
> 2012-11-12 Jakub Jelinek
>
> * asan.c (report_error_func): Set DECL_IGNORED_P, don't touch
> DECL_ASSEMBLER_NAME.
> (asan_init_func): Likewise.
> (asan_finish_file): Use void * instead of __asan_global * as
> type of __asan_{,un}register_gl
On 2012.11.12 at 19:02 +0100, Jakub Jelinek wrote:
> On Mon, Nov 12, 2012 at 06:13:08PM +0100, Markus Trippelsdorf wrote:
> > Another ICE:
> >
> > % cat test.ii
> > int i;
> >
> > % g++ -faddress-sanitizer -c -g -O1 test.ii
> > test.ii:1:7: internal compiler error: Segmentation fault
> > int
On Mon, Nov 12, 2012 at 06:13:08PM +0100, Markus Trippelsdorf wrote:
> Another ICE:
>
> % cat test.ii
> int i;
>
> % g++ -faddress-sanitizer -c -g -O1 test.ii
> test.ii:1:7: internal compiler error: Segmentation fault
> int i;
>^
The RECORD_TYPE doesn't have lang specific payload al
Another ICE:
% cat test.ii
int i;
% g++ -faddress-sanitizer -c -g -O1 test.ii
test.ii:1:7: internal compiler error: Segmentation fault
int i;
^
0xa5cb5f crash_signal
/home/markus/gcc/gcc/toplev.c:334
inconsistent DWARF line number info
0x4cf588 cp_classify_record
/home
Jakub Jelinek writes:
> The bug is elsewhere, the following patch should fix this
> (and I've reordered the assignments according to the call arg
> number, so that it is more readable at the same time).
> Ok for trunk?
>
> 2012-11-12 Jakub Jelinek
>
> * asan.c (instrument_builtin_call) :
On Mon, Nov 12, 2012 at 04:45:55PM +0100, Tobias Burnus wrote:
> First, I have a small hyphen fix patch, which is on top of your
> merge branch. (The "asan" branch itself is okay.)
This patch is preapproved with appropriate ChangeLog entry.
Thanks.
> --- invoke.texi.orig2012-11-12 15:41:31.00
Dodji Seketeli wrote:
I believe the neqw series of patches I have juste posted address this
issue.
Thanks a lot for your merging work! I am really looking forward to have
it available on the trunk!
I guess that your updated patch fixes the issue as it incorporates
Jakub's patch. (I have not
Tobias Burnus writes:
> The attached test case ICEs (segfault) both on the asan branch and on
> the trunk with Dodji's patches:
Thank you for reporting this.
I believe the neqw series of patches I have juste posted address this
issue.
To ease the testing, you can check out an updated git tree
On Sat, Nov 10, 2012 at 07:54:34PM +0100, Tobias Burnus wrote:
> 2012-11-10 Tobias Burnus
> Jakub Jelinek
>
> * asan.c (maybe_instrument_builtin_call): Set *iter
> to gsi for the call at the end.
> (transform_statements): Leave loop when gsi_end_p.
But IMHO it
Tobias Burnus wrote:
I spoke too early. With the updated patch, there is no ICE, but one
crashes for the following valid program with:
But with my original patch, it works.
To recap: My "if (gsi_end_p (i)) break;" (cf. [1]) fixes my original
issue (ICE for fail31.ii; [1]) and gives the correc
Tobias Burnus wrote:
So untested:
Thanks for the patch! It fixed the problem half way: It fixes the
second issue I had (fail10.ii,
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00791.html ).
However, it didn't fix the original problem: As the call for strlen
directly returns, it never reach
Jakub Jelinek wrote:
--- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100
+++ gcc/asan.c 2012-11-09 21:26:00.0 +0100
@@ -1362,6 +1362,8 @@ transform_statements (void)
instrument_assignment (&i);
else if (is_gimple_call (s))
maybe_instrument_call (
On Fri, Nov 09, 2012 at 09:36:53PM +0100, Tobias Burnus wrote:
> * I still have to do an all-language bootstrap and regtesting,
> though the latter is probably pointless as there is currently not a
> single -fasan test case.
> --- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100
> +++ gcc/asa
Tobias Burnus wrote:
The attached test case ICEs (segfault) both on the asan branch and on
the trunk with Dodji's patches:
I found another ICE - this time without a patch.
[That's with the patch, which I posted in this thread. Without, one
seems to run into the problem I tried to fix with the
14 matches
Mail list logo
