https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84250
--- Comment #3 from Maxim Ostapenko ---
(In reply to Martin Liška from comment #2)
> Maxim I've just seen your patch:
> https://github.com/google/sanitizers/issues/912#issuecomment-363525012
>
> Would it be possible to merge a solution to GCC tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81697
--- Comment #5 from Maxim Ostapenko ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81923
--- Comment #5 from Maxim Ostapenko ---
(In reply to Maxim Ostapenko from comment #4)
> Created attachment 42071 [details]
> Untested fix
>
> The patch I'm testing now. It works on attached testcase.
Yeeks, this patch is wrong, especially for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81923
--- Comment #4 from Maxim Ostapenko ---
Created attachment 42071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42071&action=edit
Untested fix
The patch I'm testing now. It works on attached testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81923
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861
Maxim Ostapenko changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861
--- Comment #6 from Maxim Ostapenko ---
Created attachment 41990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41990&action=edit
Untested fix
The problem is that LTO doesn't propagate changed
ix86_stack_protector_guard_reg value:
6654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861
--- Comment #3 from Maxim Ostapenko ---
(In reply to Uroš Bizjak from comment #1)
> You didn't specify compile flags, but using:
>
> -O2 -fstack-protector-strong -fsanitize=address, I get:
Sorry, here they are:
$ /home/max/build/master/gcc/xg
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: m.ostapenko at samsung dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81697
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
Maxim Ostapenko changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80798
--- Comment #1 from Maxim Ostapenko ---
Created attachment 41372
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41372&action=edit
Trivial fix
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: m.ostapenko at samsung dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Not sure anybody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027
--- Comment #4 from Maxim Ostapenko ---
(In reply to Michael Thayer from comment #3)
> Seems my mistake. I think the ASAN library was still getting loaded
> dynamically. Now I have the following problem, which I think means that
> code (constru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663
--- Comment #7 from Maxim Ostapenko ---
Created attachment 40646
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40646&action=edit
Fix 2
Iain, could you test the following patch? This one is likely to be applied
upstream.
As a side note, LL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663
--- Comment #6 from Maxim Ostapenko ---
(In reply to Maxim Ostapenko from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > Have you raised this with compiler-rt upstream already?
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #28 from Maxim Ostapenko ---
(In reply to Jakub Jelinek from comment #27)
> I think the problem is in the vnode->dynamically_initialized handling, as
> well as in get_translation_unit_decl being totally unreliable.
> When LTO merges V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #26 from Maxim Ostapenko ---
(In reply to Maxim Ostapenko from comment #24)
> (In reply to Tobias Burnus from comment #23)
> > (In reply to Tobias Burnus from comment #22)
> > > As I recently did some incremental builds, I will retry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #24 from Maxim Ostapenko ---
(In reply to Tobias Burnus from comment #23)
> (In reply to Tobias Burnus from comment #22)
> > As I recently did some incremental builds, I will retry it after a full
> > bootstrap.
>
> Didn't make a dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #21 from Maxim Ostapenko ---
(In reply to Tobias Burnus from comment #20)
> Created attachment 40574 [details]
> New still failing test case (tar.gz), slightly modifying the previous one
>
> (In reply to chefmax from comment #19)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #14 from Maxim Ostapenko ---
(In reply to Richard Biener from comment #13)
> (In reply to Maxim Ostapenko from comment #12)
> > Created attachment 40525 [details]
> > Untested fix 2.
> >
> > The patch I'm testing now.
>
> DECL_SOURC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
Maxim Ostapenko changed:
What|Removed |Added
Attachment #40514|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #11 from Maxim Ostapenko ---
(In reply to Maxim Ostapenko from comment #10)
> Yeah, but it seems that lto doesn't propagate source location either:
>
> /* Output info about new location into bitpack BP.
>After outputting bitpack,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #10 from Maxim Ostapenko ---
Yeah, but it seems that lto doesn't propagate source location either:
/* Output info about new location into bitpack BP.
After outputting bitpack, lto_output_location_data has
to be done to output a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #8 from Maxim Ostapenko ---
(In reply to Jakub Jelinek from comment #7)
> Comment on attachment 40514 [details]
> Untested fix 1.
>
> But DECL_SOURCE_FILE is not the main input file of the TU that contains it,
> if e.g. a variable is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #6 from Maxim Ostapenko ---
Created attachment 40514
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40514&action=edit
Untested fix 1.
The fix I'm testing now. With this patch trivial example works and attached
testcase doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79042
Maxim Ostapenko changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: m.ostapenko at samsung dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532
--- Comment #7 from Maxim Ostapenko ---
Created attachment 40197
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40197&action=edit
Fix
Right.
Attached patch fixes build error (perhaps all sparc stuff should go upstream,
because I think we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532
--- Comment #6 from Maxim Ostapenko ---
(In reply to jos...@codesourcery.com from comment #5)
> On Tue, 29 Nov 2016, m.ostapenko at samsung dot com wrote:
>
> > /home/max/src/glibc/resolv/ns_print.c:99: undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532
--- Comment #3 from Maxim Ostapenko ---
(In reply to Matthias Klose from comment #2)
> glibc 2.24 and linux 4.8.7.
Could you also share how you configure Glibc? Do you use native or cross build?
I'm asking because Glibc 2.24 fails to build for m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307
--- Comment #9 from Maxim Ostapenko ---
Can we close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #47 from Maxim Ostapenko ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #45)
> > --- Comment #44 from Maxim Ostapenko ---
> [...]
> >> Otherwise the definition of SANITIZER_OS_TRACE results in
> >> libsanitizer/sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #44 from Maxim Ostapenko ---
(In reply to Jack Howarth from comment #41)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #39)
> > > --- Comment #36 from Jack Howarth ---
> > > Created attachment 40044 [details]
> > > -->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #28 from Maxim Ostapenko ---
So, perhaps I can commit it (from #15) as Jakub suggested to restore GCC
bootstrap for now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77827
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307
--- Comment #6 from Maxim Ostapenko ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Maxim Ostapenko from comment #4)
> > But LLVM doesn't support shared UBSan runtime (the only one supported is
> > ASan) and AFAIK there aren't any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307
--- Comment #4 from Maxim Ostapenko ---
(In reply to Jakub Jelinek from comment #3)
> Sure, it doesn't affect gcc emitted code unless somebody calls those
> directly, but perhaps say llvm compiled code using the shared libubsan.so.
But LLVM doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #15 from Maxim Ostapenko ---
Created attachment 40012
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40012&action=edit
Untested fix 2.
Ok, thanks.
I'm attaching a second short-term fix for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #13 from Maxim Ostapenko ---
(In reply to Rainer Orth from comment #11)
> (In reply to Jakub Jelinek from comment #5)
> > extern char **environ;
> > #endif
> >
> > -#if defined(__has_include) && __has_include()
> > +#if defined(__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #8 from Maxim Ostapenko ---
(In reply to Dominique d'Humieres from comment #7)
> > Attaching untested fix.
> > Dominique, could you try it?
>
> Allow for ~2 hours.
Or better Jakub's fix, it looks cleaner.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #6 from Maxim Ostapenko ---
Created attachment 40007
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40007&action=edit
Untested fix.
Attaching untested fix.
Dominique, could you try it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #4 from Maxim Ostapenko ---
(In reply to Iain Sandoe from comment #3)
> (In reply to Maxim Ostapenko from comment #1)
> > Eh, mine.
> >
> > typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange,
> > it seems that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982
--- Comment #11 from Maxim Ostapenko ---
Created attachment 39882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39882&action=edit
Untested fix
Untested fix (works for me with attached testcase).
To sum up:
1) dlopen grabs a __GI___pthre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982
--- Comment #10 from Maxim Ostapenko ---
(In reply to Pawel Sikora from comment #9)
> (In reply to Maxim Ostapenko from comment #8)
>
> > Hm, perhaps environment issue. What version of Glibc do you use?
>
> glibc-2.23.1-10.fc24.x86_64
Reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982
--- Comment #8 from Maxim Ostapenko ---
(In reply to Pawel Sikora from comment #7)
> (In reply to Maxim Ostapenko from comment #6)
> > The attached testcase works for me with current trunk GCC:
> >
> > max@max:/tmp/bug$ make
> > rm -f m *.so
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63299
Maxim Ostapenko changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: m.ostapenko at samsung dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480
Maxim Ostapenko changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480
--- Comment #3 from Maxim Ostapenko ---
Thanks, will post the fix in ML soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480
--- Comment #1 from Maxim Ostapenko ---
The problem appears for arm target only, x86 is fine.
$ armv7l-tizen-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=armv7l-tizen-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/max/install/armv7l-tizen
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: m.ostapenko at samsung 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
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445
--- Comment #5 from Maxim Ostapenko ---
Can we use dlvsym for versioned symbols (recvmsg, sendmsg, etc) in the
wrappers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291
--- Comment #13 from Maxim Ostapenko ---
Created attachment 38620
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38620&action=edit
mozconfig
This .mozconfig with current trunk clang 3.9.0. The source code I've downloaded
from here:
$ hg c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291
--- Comment #10 from Maxim Ostapenko ---
I've build Firefox locally with clang with optimizations disabled
(CFLAGS="-fsanitize=address -fsanitize-recover=address -O0") and got pretty the
same backtrace:
==12707==ERROR: AddressSanitizer: stack-bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70712
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624
--- Comment #12 from Maxim Ostapenko ---
Should be fixed on trunk and gcc-6-branch. Older branches don't need the patch,
because they don't contain 'dyldVersionNumber' in libsanitizer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70474
--- Comment #5 from Maxim Ostapenko ---
Eh, just forgot about this one, sorry. Will post the patch shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70541
--- Comment #4 from Maxim Ostapenko ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Maxim Ostapenko from comment #1)
> > @@ -2060,7 +2067,20 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
> >return true;
> > }
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70541
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70474
--- Comment #1 from Maxim Ostapenko ---
Created attachment 38143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38143&action=edit
Proposed patch.
Does this patch fix the problem?
74 matches
Mail list logo
