[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[echristo at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693



Eric Christopher  changed:



   What|Removed |Added



 CC||echristo at gmail dot com



--- Comment #13 from Eric Christopher  2013-01-17 
22:17:16 UTC ---

You can use DYLD_PRINT_BINDINGS to find out which __cxa_allocate_exception call

is being used, it'll also give you the addresses so you can make sure that the

right one is being called as you step through.

[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense

[echristo at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490

--- Comment #2 from Eric Christopher  ---
Why does it seem like a bad decision? Endianness can be separate from OS (or
bare metal) so I don't see how outputting the macro as a per-cpu define is a
bad thing.

[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense

[echristo at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490

--- Comment #4 from Eric Christopher  ---
I disagree for bare metal that including endian is the right way, but agree
that __BYTE_ORDER__ is the right way to do this in general.

Thanks Jakub.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[echristo at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888

--- Comment #23 from Eric Christopher  ---
So, I think Jakub's solution is strictly better here as it allows intermixing
of asan and non-asan code. It'll involve a bit of work in llvm's middle end to
keep track of symbol type to make sure to emit padding as we hit the backend,
but as long as we make sure to have full symbols for each variable it should be
fine on platforms like OS X where we have linkers that split sections based on
type of section and symbols in the section. It's an endless string of corner
cases, but as long as we're careful it'll probably work.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[echristo at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888

--- Comment #24 from Eric Christopher  ---
For the record btw, I don't believe there's a reason why the linker couldn't
split up the data section by knowing the size of the variable so it's worth
being very careful here - there be dragons and things could break. I don't have
any better ideas at the moment though.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[echristo at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888

--- Comment #26 from Eric Christopher  ---
Sure. Not the general case for other targets though.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[echristo at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888

--- Comment #28 from Eric Christopher  ---
Ah, but not every platform is ELF :)

ld64 has the flexibility to do this with Mach-O. As I said, I don't have any
better ideas at the moment, but warning that it is possible to break.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[echristo at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888

--- Comment #30 from Eric Christopher  ---
That might be reasonable. As far as I know ld64 doesn't do that yet, but I know
it's been thought about.