http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #4 from Alexey Samsonov ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Alexey Samsonov from comment #2)
> > We found it convenient to run fork+exec early at program startup. It can
> > also be slightly dangerous to call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #3 from Jakub Jelinek ---
(In reply to Alexey Samsonov from comment #2)
> We found it convenient to run fork+exec early at program startup. It can
> also be slightly dangerous to call fork() in multi-threaded program (even
> though we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59144
Bug ID: 59144
Summary: weird behavior when dealing with too complicated
templates and class hierarchy
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59127
Jeffrey A. Law changed:
What|Removed |Added
CC||sch...@linux-m68k.org
--- Comment #5 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59109
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #2 from Alexey Samsonov ---
(In reply to Jakub Jelinek from comment #0)
> I've noticed that libasan/liblsan now start external llvm-symbolizer for all
> programs just in case they would be buggy, that looks like a very bad idea
> to me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
--- Comment #23 from __vic ---
What actual status of this bug is? Is it fixed or still not?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59143
--- Comment #1 from Jürgen Reuter ---
The problem is back in 4.8, 4.7, 4.6.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59143
Bug ID: 59143
Summary: Problem with array dimension in polymorphic types
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #21 from dave.anglin at bell dot net ---
On 14-Nov-13, at 12:26 PM, bergner at gcc dot gnu.org wrote:
> Dave, can you try this patch to see if it cleans up the errors
> you're seeing?
Patch cleans up the errors.
Dave
--
John David
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56902
--- Comment #3 from Cong Hou ---
How do you generate the final operations in vectorized code?
I just submitted a patch on this issue. The patch supports non-isomorphic
operations with the restriction that all operations on even/odd elements still
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59142
--- Comment #1 from João M. S. Silva ---
Created attachment 31223
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31223&action=edit
compressed preprocessed source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59142
Bug ID: 59142
Summary: internal compiler error while compiling OpenCV 2.4.7
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930
--- Comment #1 from Paul Pluzhnikov ---
Re-confirmed with current trunk:
g++ (GCC) 4.9.0 20131114 (experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58940
--- Comment #1 from Paul Pluzhnikov ---
Re-confirmed with current trunk:
g++ (GCC) 4.9.0 20131114 (experimental)
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Possibly related to PR58940
Google ref: b/11696404
Confirmed with current trunk:
g++ (GCC) 4.9.0 20131114 (experimental)
g++ -c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59140
Bug ID: 59140
Summary: [C++11] Bogus "error: use of deleted function ..."
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59118
Paolo Carlini changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Severity|ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59131
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
er-install/gcc-r204770-install
--enable-languages=c,c++ --enable-multilib
Thread model: posix
gcc version 4.9.0 20131114 (experimental) (GCC)
-linux-gnu
Configured with: /users/regehr/z/compiler-source/gcc/configure
--prefix=/users/regehr/z/compiler-install/gcc-r204770-install
--enable-languages=c,c++ --enable-multilib
Thread model: posix
gcc version 4.9.0 20131114 (experimental) (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56764
--- Comment #5 from congh at gcc dot gnu.org ---
Author: congh
Date: Thu Nov 14 21:51:07 2013
New Revision: 204825
URL: http://gcc.gnu.org/viewcvs?rev=204825&root=gcc&view=rev
Log:
2013-11-14 Cong Hou
Backport from mainline
2013-11-14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59021
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #15 from Uroš Bizjak ---
Whops, wrong PR number in ChangeLog entry.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #14 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Nov 14 21:26:09 2013
New Revision: 204823
URL: http://gcc.gnu.org/viewcvs?rev=204823&root=gcc&view=rev
Log:
Backport from mainline
2013-11-10 Uros Bizjak
* mod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59021
--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Nov 14 21:26:09 2013
New Revision: 204823
URL: http://gcc.gnu.org/viewcvs?rev=204823&root=gcc&view=rev
Log:
Backport from mainline
2013-11-10 Uros Bizjak
* mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
janus at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.7.2
Summary|endles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
janus at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.6.2
--- Comment #6 from janus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
janus at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2013-11-14 00:00:00 |2013-11-13 0:00
Known to w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59137
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target Miles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59127
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59137
Bug ID: 59137
Summary: Miscompilation at -O1 on mips/mipsel
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57887
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57887
--- Comment #6 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Nov 14 20:16:51 2013
New Revision: 204818
URL: http://gcc.gnu.org/viewcvs?rev=204818&root=gcc&view=rev
Log:
/cp
2013-11-14 Paolo Carlini
PR c++/57887
* parser.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59122
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Thu Nov 14 18:28:43 2013
New Revision: 204801
URL: http://gcc.gnu.org/viewcvs?rev=204801&root=gcc&view=rev
Log:
PR sanitizer/59122
* asan.c (asan_emit_stack_protection): Ensure -fs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59099
--- Comment #3 from Martin Jambor ---
Hi, I have to leave today but I've posted some information about my
progress with an untested fix to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01649.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #20 from Jakub Jelinek ---
If I remove the
#include
it still compiles just fine here on Fedora 19, looks like only the
linux/mroute.h
ioctls are instrumented.
Anyway, sounds to me like this badly needs autoconf and HAVE_LINUX_MROUTE6_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58963
--- Comment #4 from Andrew Pinski ---
(In reply to Cong Hou from comment #3)
> Suppose there is a third-party complex library, which is written in the same
> way as . Then GCC could not recognize that as complex type, and
> will not use builtin ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #19 from Peter Bergner ---
Someone on my team reported that our internal bootstrap tester is still
failing. It is failing due to the linux/mroute6.h header file not existing.
Our builds are occurring on SLES10 and RHEL5 and that kern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58963
--- Comment #3 from Cong Hou ---
Suppose there is a third-party complex library, which is written in the same
way as . Then GCC could not recognize that as complex type, and will
not use builtin calls to calculate multiplication and division.
So
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #18 from dave.anglin at bell dot net ---
On 11/14/2013 12:26 PM, bergner at gcc dot gnu.org wrote:
> Dave, can you try this patch to see if it cleans up the errors you're seeing?
I will try it later today when I get home.
Dave
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #2 from Dmitry Gorbachev ---
Another testcase:
= 8< =
extern char *bar[17];
int foo(int argc, char **argv)
{
int i;
int n = 0;
for (i = 0; i < argc; i++)
n++;
for (i = 0; i < argc; i++)
argv[
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #17 from Peter Bergner ---
(In reply to Peter Bergner from comment #16)
> (In reply to dave.anglin from comment #15)
> > As of revision 204772, there are still problems on hppa-linux.
>
> Does the following patch fix them? I don't kn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59122
--- Comment #3 from Peter Bergner ---
(In reply to Peter Bergner from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > This seems to work for me in the cross, but it is a hack in any case (before
> > and now with the patch).
>
> I'll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #23 from Jakub Jelinek ---
Created attachment 31221
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31221&action=edit
gcc49-pr59061.patch
Untested patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
--- Comment #13 from Tom Tromey ---
I was debugging this today:
https://sourceware.org/bugzilla/show_bug.cgi?id=15975
... and ran across this PR again.
GCC is still emitting a virtual destructor with no indication of
its vtable element location:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
Kostya Serebryany changed:
What|Removed |Added
CC||glider at google dot com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
Bug ID: 59136
Summary: llvm-symbolizer shouldn't be started always
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: saniti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59094
--- Comment #3 from Dmitry Gorbachev ---
(In reply to Balaji V. Iyer from comment #2)
> Can you please confirm if the following patch works for you?
Yes, the patch works.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59135
Bug ID: 59135
Summary: Incorrect ambiguity in constexpr function overloads
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087
--- Comment #8 from Marc Glisse ---
(In reply to Ed Smith-Rowland from comment #7)
> g++ is working as intended.
Thanks a lot for the investigation. Do you think the error message: "unable to
find numeric literal operator" could additionally poin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087
--- Comment #7 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
OK, it took me a while to remember this (even though I put it in myself).
By default, g++ -std=c++11/1y intercepts numeric suffixes for C++11
user-defined literals.
By default g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59122
--- Comment #2 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #1)
> This seems to work for me in the cross, but it is a hack in any case (before
> and now with the patch).
I'll give your patch a try, thanks.
> What I need is som
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #22 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #21)
> (In reply to Kostya Serebryany from comment #20)
> > > I our simulation code, it looks like the overhead for leak checking is
> > > about
> > > 20%. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #16 from Peter Bergner ---
(In reply to dave.anglin from comment #15)
> As of revision 204772, there are still problems on hppa-linux.
Does the following patch fix them? I don't know whether it creates more
problems than it solves, b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #44 from Bernd Edlinger ---
Hi Richard,
this 59143 issue is very similar to what Sandra encountered with her patch.
but it is not volatile in that example.
I can not reproduce that on the ARM.
But I think it is possible that the othe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #21 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #20)
> > I our simulation code, it looks like the overhead for leak checking is about
> > 20%. I haven't done very careful measurements yet, since this is mor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #20 from Kostya Serebryany ---
> I our simulation code, it looks like the overhead for leak checking is about
> 20%. I haven't done very careful measurements yet, since this is more or
> less what we're willing to pay to integrate the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #19 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #18)
> I don't think we've measured pure-lsan slowdown, but I expect it to be small.
> asan/lsan bring in a different allocator (malloc/free).
> We tried to m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59133
Richard Biener changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
Target Mil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #18 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #17)
> (In reply to Sergey Matveev from comment #16)
> >
> > Under the current behavior -fsanitize=address,leak is equivalent to
> > -fsanitize=address.
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59133
--- Comment #2 from Yuri Rumyantsev ---
It is worth noting that -m32 option is also essential for reproducing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59134
Bug ID: 59134
Summary: Infinite loop between store_fixed_bit_field and
store_split_bit_field with STRICT_ALIGNMENT
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59133
--- Comment #1 from Yuri Rumyantsev ---
Created attachment 31219
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31219&action=edit
test-case to reproduce
Need to be compiled with -m32 -march=core-avx2 -O3 -ffast-math options to
reproduce ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59133
Bug ID: 59133
Summary: [4.9 regression] ICE after r204219 on SPEC2006
435.gromacs.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59132
Bug ID: 59132
Summary: Missing aggressive-loop-optimisation warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #17 from Joost VandeVondele
---
(In reply to Sergey Matveev from comment #16)
>
> Under the current behavior -fsanitize=address,leak is equivalent to
> -fsanitize=address.
>
> We've considered other options, such as making -fsanitiz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59127
--- Comment #3 from Jeffrey A. Law ---
Most likely it is. However, the actual failure message is different, so until
I verify the fix addresses both instances, let's keep this open.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #16 from Sergey Matveev ---
(In reply to Kostya Serebryany from comment #11)
> > Easily doable of course, but we should create liblsan as shared
> > library in that case too. What combination of those do you allow? I mean,
> > is
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59131
Bug ID: 59131
Summary: Compiler segfaults while generating code to save local
variables in transactional section
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59127
--- Comment #2 from Andrew Pinski ---
I think this is a dup of bug 59109.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59130
Bug ID: 59130
Summary: Inline(d) or static functions not registered in
transactional clone table
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #15 from Andrew Pinski ---
(In reply to Kostya Serebryany from comment #7)
> >
> > Additionally, it seems important to have -g -fno-omit-frame-pointer in the
> > options. Maybe gcc should add these options for best 'user experience',
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57756
--- Comment #7 from Yuri Rumyantsev ---
Created attachment 31217
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31217&action=edit
Additioanl patch for r203634.
See my comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57756
Yuri Rumyantsev changed:
What|Removed |Added
CC||ysrumyan at gmail dot com
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #6 from Jonatha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59129
--- Comment #1 from Richard Biener ---
I think this is a already fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59125
--- Comment #3 from Richard Biener ---
It doesn't work that easily. But we could "refine" a folding result without
actually doing the folding by adding an additional argument to the builtin
which serves as a (sofar) known maximum/minimum value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #17 from Evgeniy Stepanov ---
(In reply to Yury Gribov from comment #16)
> (In reply to Evgeniy Stepanov from comment #15)
> > No need, I'm fixing it now.
>
> Sorry for bothering but is this in compiler-rt trunk yet?
Sorry, I forgot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #16 from Yury Gribov ---
(In reply to Evgeniy Stepanov from comment #15)
> No need, I'm fixing it now.
Sorry for bothering but is this in compiler-rt trunk yet?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59129
Bug ID: 59129
Summary: assert fail for tree.c:4150
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087
--- Comment #6 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Strangely, head works: http://melpon.org/wandbox/permlink/CnsddYRxUohlCGF1
Although mine still gets the error.
I did something that might have helped for 4.9. If I can prove tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #14 from Alexey Samsonov ---
(In reply to Kostya Serebryany from comment #13)
> > Why don't you use libbacktrace for that? It is not GPL, so Apple and other
>
> I *think* we evaluated libbacktrace over 2 years ago and
> discarded fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59128
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59128
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
--- Comment #12 from Yury Gribov ---
(In reply to Evgeniy Stepanov from comment #8)
> ... one of the ASan interceptors
> that does ENSURE_ASAN_INITED().
> Arguably, all interceptors should do it.
Can we force all interceptors to do this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
--- Comment #11 from Yury Gribov ---
(In reply to Evgeniy Stepanov from comment #10)
> We don't intercept signal() on Android
This is just an implementation detail, this fails just as well:
$ cat repro.c
#include
#include
#include
int m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59128
Bug ID: 59128
Summary: I use #define to set ALPHA to a constant and then (for
convenience) define ALPHA2 = ALPHA*ALPHA
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
Kostya Serebryany changed:
What|Removed |Added
CC||samsonov at google dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2013-11-13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #9 from Walter Mascarenhas ---
1) I just wrote that Richard's paragraph, IN ITSELF,
does not explain why things are as they are. I did not
write that there aren't other reasons to justify the
standard's decisions.
2) As I wrote, GCC d
-gnu
Configured with: /home/jweil/gcc49/trunk/configure --program-suffix=-4.9
--enable-checking=release --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,fortran --disable-bootstrap --disable-multilib
Thread model: posix
gcc version 4.9.0 20131114 (experimental) [trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #12 from Jakub Jelinek ---
(In reply to Kostya Serebryany from comment #9)
> We have work-in-progress to make the symbolizer in-process as opposed to
> the current one that is out-of-process (uses pipes):
> https://code.google.com/p/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #11 from Kostya Serebryany ---
> > I am not an expert in the gcc build system so this will have to be done by
> > someone else. Also, I am heavily frightened by the amount of differences
> > between the clang and gcc builds of libsan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #10 from Jakub Jelinek ---
(In reply to Kostya Serebryany from comment #7)
> > > Clang supports -fsanitize=leak which simply links a standalone lsan
> > > library
> > > (no instrumentation at compile time required).
> > > Perhaps gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #9 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #8)
> (In reply to Kostya Serebryany from comment #7)
> > -fno-omit-frame-pointer: that may or may not be a good idea, I don't know.
>
> I seem to need it to g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59127
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59122
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
Summary|libsanitizer me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #8 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #7)
> -fno-omit-frame-pointer: that may or may not be a good idea, I don't know.
I seem to need it to get good backtraces (i.e. full stack, line numbers etc.)
1 - 100 of 116 matches
Mail list logo
