Re: how to modify gcc to compile a[b] differently

[Игорь Пашев]

2015-04-01 12:19 GMT+03:00 Richard Biener :
> You probably want to do this in the frontends.

And one of them is C++ :-)

GCC 4.9 internal compiler error

[Игорь Пашев]

Hi all!

It was found that OA fails to build with GCC 4.9 on amd64 [1]
I can confirm this with r3094 on bare metal too.

# gcc --version
gcc-4.9.real (Debian 4.9.1-14) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I can imaging that this is a bug in OpenAxiom, but GCC should not crash.

GCC complains on this line
https://sourceforge.net/p/open-axiom/code/HEAD/tree/trunk/src/include/storage.H#l273

Quoting [1]:
> g++ -DHAVE_CONFIG_H -I. -I../../../src/syntax -I../../config  
> -I../../../src/include -I../../x86_64-pc-linux-gnu/include 
> -D_FORTIFY_SOURCE=2 -m64 -D_GNU_SOURCE  -std=c++11 -g -O2 
> -fstack-protector-strong -Wformat -Werror=format-security -O2 -Wall -c -o 
> libsyntax_a-sexpr.o `test -f 'sexpr.cc' || echo 
> '../../../src/syntax/'`sexpr.cc
> In file included from ../../x86_64-pc-linux-gnu/include/open-axiom/sexpr:47:0,
>  from ../../../src/syntax/sexpr.cc:39:
> ../../x86_64-pc-linux-gnu/include/open-axiom/storage: In instantiation of 'T* 
> OpenAxiom::Memory::Factory::make(const Args& ...) [with Args = 
> {std::vector OpenAxiom::Sexpr::Syntax*> >, bool}; T = OpenAxiom::Sexpr::ListSyntax]':
> ../../../src/syntax/sexpr.cc:341:37:   required from here
> ../../x86_64-pc-linux-gnu/include/open-axiom/storage:275:52: internal 
> compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2066
>  return new(this->allocate(1)) T{args...};
> ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> Preprocessed source stored into /tmp/cc6mQYS6.out file, please attach this to 
> your bugreport.
> make[3]: *** [libsyntax_a-sexpr.o] Error 1




[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761549

Re: Rename unwind.h to unwind-gcc.h

[Игорь Пашев]

AFAIK GCC's unwind.h installed into GCC's private directory, e. g.
/usr/lib/gcc/x86_64-pc-solaris2.11/4.8/include/unwind.h

Is there any real problem?

Re: Why aren't installed binaries stripped?

[Игорь Пашев]

2013/10/30 FX :
> OK, great. Any reason why it should not be the “default” install?

Then we need "make install-nostrip" ;-)

Re: put ELF reloc section against section with template function instantiation in the same COMDAT group

[Игорь Пашев]

2013/7/8 Andrew Pinski :
> I think GCC's behavior is depend on the assembler which is being used.
>  So if you used Sun's assembler it would have placed it in the same
> COMDAT group.  Meaning this is really a GNU binutils issue rather than
> a GCC one.

Thank you.

I believe GCC on Solaris is using GNU as and Sun ld, don't know about Sun CC.

I would appreciate if anyone could explain what is the impact of
including or not including
relocation entries in the same COMDAT group.

put ELF reloc section against section with template function instantiation in the same COMDAT group

[Игорь Пашев]

Hi, all.

First off, I know that I'm posting to GCC list :-)
And I'm looking for competent opinions.

I'm working on CLang/LLVM issue [1].
Clang doesn't put section with relocation entries against section
with templated function instantiation in the same COMDAT group.
AFAIK GCC does not do it too, Solaris CC does.

Is GCC's behavior intentional? Does GCC rely on the linker?

I'm not sure what questions are correct, so appreciate any comments .



[1] http://llvm.org/bugs/show_bug.cgi?id=12843