ASAN test failures make compare_tests useless

On the compile farm, ASAN tests seem to fail a lot like: FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==31166==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) ==31166==ReserveShadowMemoryRange failed w

Re: LTO inhibiting dwarf lexical blocks output

> So... I've been getting my feet wet with LTO and debugging and I > noticed a seemingly unrelated yet annoying problem. On x86-64, > gcc.dg/guality/pr48437.c fails when run in LTO mode. > > I've compared the dwarf output with and without LTO, and I noticed > that the DW_TAG_lexical_block is miss

Re: LTO inhibiting dwarf lexical blocks output

On Fri, Aug 15, 2014 at 10:08:38PM +0200, Steven Bosscher wrote: > On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote: > > So... I've been getting my feet wet with LTO and debugging and I noticed a > > seemingly unrelated yet annoying problem. On x86-64, > > gcc.dg/guality/pr48437.c fails when

Re: LTO inhibiting dwarf lexical blocks output

Isn't the only real solution: to generate this kind of DIEs earlier (maybe already immediately after parsing) and stream them? Ultimately yes, and that's what I hope to work on, but I was mostly curious because at stream out time, the information *is* there, and we silently dropped it. Ald

Re: LTO inhibiting dwarf lexical blocks output

On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote: > So... I've been getting my feet wet with LTO and debugging and I noticed a > seemingly unrelated yet annoying problem. On x86-64, > gcc.dg/guality/pr48437.c fails when run in LTO mode. Eh, sorry I can't actually answer your question but, e

LTO inhibiting dwarf lexical blocks output

So... I've been getting my feet wet with LTO and debugging and I noticed a seemingly unrelated yet annoying problem. On x86-64, gcc.dg/guality/pr48437.c fails when run in LTO mode. I've compared the dwarf output with and without LTO, and I noticed that the DW_TAG_lexical_block is missing from

What are open tasks about GIMPLE loop optimizations?

Dear GCC Developers, Nobody answers my question below, so perhaps something wrong with my email :) So let me clarify in more details what I’m asking about. I’ve made some very very very basic evaluation of GCC code ([1]) and started to think about concrete task to contribute to GCC (language and

Re: Trying to fix #61880, what characters are valid in assembler/symbol names

On Fri, Aug 15, 2014 at 12:48 AM, Alexander Shopov wrote: > > The symbol/assembler name (I do not know what is the right word) that > is generated in the .h header file is: > extern int Cgoexp_Dummy (int p0) > __asm__("cgo_problem_example_com_demo.Cgoexp_Dummy"); > > The symbol that exists in the

Re: Is escaping of a temp variable valid?

On Fri, Aug 15, 2014 at 10:45 AM, Joey Ye wrote: > Running into an unexpected result with GCC with following case, but > not sure if it is a valid C++ case. > > #define nullptr 0 > enum nonetype { none }; > > template > class class_zoo { > public: > const T *data; > int length; > > c

Is escaping of a temp variable valid?

Running into an unexpected result with GCC with following case, but not sure if it is a valid C++ case. #define nullptr 0 enum nonetype { none }; template class class_zoo { public: const T *data; int length; class_zoo (nonetype) : data (nullptr), length (0) {} class_zoo (const

Trying to fix #61880, what characters are valid in assembler/symbol names

Hi everyone, I am trying to fix #61880 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 but will need some guidance as I am a complete newbie. The problem is concerns gccgo and the way the binaries it generates link with the rest of the objects. I have given a really tiny test case in the bug,