[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #209 from Peter Bisroev --- (In reply to dave.anglin from comment #206) > Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and > cc1plus? Hi Dave, Sorry for the delayed response. I have tried linker option "-Wl,-O" but it does not seem to make any difference. I used gcc 4.7.4 compiled with --enable-comdat option as per my comment 181 and get the same number of PCREL21B errors as before. I wonder if HPs linker does garbage collection after it deals with all the relocations first. Looks like we might have to get the fix into GNU AS first to get PCREL60B working. I will try to look into how we can get this done hopefully next weekend. Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Peter Bisroev changed: What|Removed |Added CC||peter.bisroev at groundlabs dot co ||m --- Comment #207 from Peter Bisroev --- (In reply to dave.anglin from comment #206) > Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and > cc1plus? Hi Dave, sorry for the delayed response. That is a good catch, I missed that option before. I will be able to test this out this weekend. Will let you know asap. Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #205 from Peter Bisroev --- Hi Dave, I have submitted bug 25599 (https://sourceware.org/bugzilla/show_bug.cgi?id=25599) to binutils with a slightly simplified test case and CCed you as well. Additionally, I was also able to verify that current binutils (2.34), can now be compiled with our bootstrapped gcc 4.7.4 (I was not able to do so using aCC before). So hopefully once the bug is fixed we can continue testing it here. Thanks again for your help! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #204 from Peter Bisroev --- (In reply to dave.anglin from comment #203) > On 2020-02-25 12:56 a.m., peter.bisroev at groundlabs dot com wrote: > > Now looking at the main.o generated by gcc, the relocation seems to be as > > expected but the relocation address seems to be off: > > -- > > 20: 04 00 00 00 01 00 [MLX] nop.m 0x0 > > 21: PCREL60Bhello > > 26: 00 00 00 00 00 00 brl.call.sptk.many b0=20 > > > > 2c: 08 00 00 d0 > > -- > > > > As can be seen above, GNU as is telling HP's ld to do the relocation at > > 0x21, > > which falls into slot 1 and 0. However the relocation needs to be done at > > 0x26 > > to cover slots 2 and 1. > Comparing with HP as, it looks to me like the relocation should be at 0x22 > and that's why > the preceding nop.m instruction is being clobbered. > > Would you file a binutils bug report with the main.s gcc source? It looks > like gcc doesn't > generate brl branches and this never got tested. You can add me to the cc > list. Thank you Dave, you are 100% correct, it needs to be at 0x22. I was looking at the same screen for too long yesterday. Anyway, I have manually patched my object to use 0x22 as reloc offset as well as another brl related offset to a weakfunc() and everything linked and worked perfectly. -- ... 4000950: 04 00 00 00 01 00 [MLX] nop.m 0x0 4000956: 00 00 00 00 00 00 brl.call.sptk.many b0=40009d0 400095c: 88 00 00 d0 ... 4000970: 04 00 00 00 01 00 [MLX] nop.m 0x0 4000976: 00 00 00 00 00 00 brl.call.sptk.many b0=4000ac0 400097c: 58 01 00 d0 ... -- I will file a bug with binutils. Thanks again for catching my offset mistake. --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #202 from Peter Bisroev --- (In reply to dave.anglin from comment #201) > On 2020-02-22 4:33 p.m., peter.bisroev at groundlabs dot com wrote: > > They both seem to be ELF32 > Maybe run failing program under gdb to find faulting instruction. Compare > with executable that works. Hi Dave, Well, decoding IA-64 instruction bundles by hand is not fun :) But at least we know what is going on here now. Looking at main.o generated by aCC, the relocation is as expected: -- 30: 05 00 00 00 01 00 [MLX] nop.m 0x0 32: PCREL60Bhello 36: 00 00 00 00 00 00 brl.call.dptk.many b0=30 ;; 3c: 08 00 00 d2 -- Once ld takes care of relocation everything is as expected as well: -- 40009b0: 05 00 00 00 01 00 [MLX] nop.m 0x0 40009b6: 00 00 00 00 00 00 brl.call.dptk.many b0=4000a40 ;; 40009bc: 98 00 00 d2 -- I've decoded this instruction bundle by hand and verified that immediate value is 0x90 (0x9 << 4) which matches our relative offset of 0x4000a40−0x40009b0 as expected. Now looking at the main.o generated by gcc, the relocation seems to be as expected but the relocation address seems to be off: -- 20: 04 00 00 00 01 00 [MLX] nop.m 0x0 21: PCREL60Bhello 26: 00 00 00 00 00 00 brl.call.sptk.many b0=20 2c: 08 00 00 d0 -- As can be seen above, GNU as is telling HP's ld to do the relocation at 0x21, which falls into slot 1 and 0. However the relocation needs to be done at 0x26 to cover slots 2 and 1. Now looking at the linked binary we are getting the following: -- 4000950: 04 00 00 00 00 00 [MLX] break.m 0x0 4000956: 00 40 00 00 00 00 brl.call.sptk.many b0=4000950 <_end+0xc3ff0908> 400095c: 08 00 00 d0 -- As can be seen above, the slot 0 instruction changed from nop.m to break.m, and this is where we are getting the illegal instruction. In this linked binary, hello() is located at 0x40009d0. So based on this, we expect the offset to be 0x80 (0x40009d0 - 0x4000950). So the expected immediate value for brl.call should be 0x08 (0x80>>4). I decided to double check that HP's ld is doing this relocation properly but at the wrong offset requested by GNU as. Based on our relocation offset of 0x21, I have interpreted slots 1 and 0 by hand as if they were slots 2 and 1. Once we do that, we get the immediate value of 0x08 as expected. The nop.m changes to break.m because ld cleared bits of imm39 (bits 20-58) that form the 60 bit immediate. Based on the above, unless I am mistaken, it looks like a bug in GNU as. Once I get a bit of time this week I will try to look through it to see what is going on there. Just out of curiosity, I have also tried to patch the reloc offset to 0x26 in the object file just to see what happens :). After that, objdump shows expected relocation offset. However HP's linker dies with bus error when I try to link the executable. But I think we are making some progress here. What do you think? Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #200 from Peter Bisroev --- (In reply to dave.anglin from comment #199) > On 2020-02-22 4:09 p.m., peter.bisroev at groundlabs dot com wrote: > > Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but > > when > > I try to run the binary I get an "Illegal instruction" and a core dump. The > > illegal instruction seems to be the brl. I know almost nothing of IA-64 > > assembly, so will read up a bit more and try to figure out what is going on > > there. > That suggests to me that HP's aCC generates 64-bit ELF code and gcc > generates 32-bit code. > Compare header info of the two executable files with readelf. > > I'm not sure why we are struggling with the 32-bit runtime. They both seem to be ELF32 -- $ readelf -h hello ELF Header: Magic: 7f 45 4c 46 01 02 01 01 01 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI:UNIX - HP-UX ABI Version: 1 Type: EXEC (Executable file) Machine: Intel IA-64 Version: 0x1 Entry point address: 0x4000980 Start of program headers: 52 (bytes into file) Start of section headers: 69184 (bytes into file) Flags: 0x8, 32-bit Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 12 Size of section headers: 40 (bytes) Number of section headers: 37 Section header string table index: 36 $ readelf -h hello-gcc ELF Header: Magic: 7f 45 4c 46 01 02 01 01 01 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI:UNIX - HP-UX ABI Version: 1 Type: EXEC (Executable file) Machine: Intel IA-64 Version: 0x1 Entry point address: 0x4000930 Start of program headers: 52 (bytes into file) Start of section headers: 67824 (bytes into file) Flags: 0x8, 32-bit Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 12 Size of section headers: 40 (bytes) Number of section headers: 34 Section header string table index: 33 -- I am looking for any other differences now.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #198 from Peter Bisroev --- (In reply to dave.anglin from comment #196) > If you create a second object file with a second instance of hello, the > linker should not > complain about the second definition of hello since it is weak. It would > complain about > two global instances. Hi Dave, I have created a new object hello2.o, and when I tried to link I got -- "ld: Duplicate symbol "hello" in files hello.o and hello2.o " -- Then I realized that in hello.s hello is defined as ".global hello". Changing that to '.weak hello', reassembling and relinking all worked. I guess this confirms what I have seen in comment 187. So this seems to work as expected. This worked both with aCC and gcc. > Could you test whether the "brl" branch works? Simply take your main.s file > and edit the branch > to hello. This should show whether the assembler can handle it. If it > assembles, look at relocation > and see if program will link. I took main.s generated by aCC. Made the following changes: -- $ diff main-aCC.s main-aCC-weak-brl.s 7c7 < .global hello --- > .weak hello 41c41 < br.call.dptk.many rp = hello# ;; // B [main.cc: 10/5] --- > brl.call.dptk.many rp = hello# ;; // B [main.cc: 10/5] -- Reassembled with HP's as, relinked and the test ran fine. With this change when hello was global PCREL21B relocation was used. When I changed hello to weak, PCREL21B was still used. When I changed this to weak with a brl, PCREL60B was used. I have then tried to do a similar thing with main.s generated by gcc. -- $ diff main-gcc.s main-gcc-brl.s 19c19 < br.call.sptk.many b0 = hello# --- > brl.call.sptk.many b0 = hello# -- Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but when I try to run the binary I get an "Illegal instruction" and a core dump. The illegal instruction seems to be the brl. I know almost nothing of IA-64 assembly, so will read up a bit more and try to figure out what is going on there. Please let me know if I have missed anything. Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #195 from Peter Bisroev --- Hi Dave, I was doing a bit more searching and found this doc from HP, "Solaris to HP-UX Porting Guide" (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.475.5577=rep1=pdf). I know it is not from hpe.com but seems to be an official HP document HP-UX 11i v2 and later. Anyway, on page 56, it states: -- In Solaris, symbols can be set with a pragma to be weak, which means that these symbols are always overridden by any global definition. If an undefined weak symbol is never satisfied by a global definition, it is set to 0 before the program starts execution. HP_SECONDARY_DEF symbols are similar to Solaris weak symbols, but there are some differences. You can use the _HP_SECONDARY_DEF pragma to connect a weak and a strong definition (for example, _fopen and fopen). The weak definition can be overridden by other strong definitions. -- I guess that confirms your statement about sdef. On page 85, it states: -- The ELF file format provides support for global, local, and weak symbols. Creating these symbols requires support from the compiler. The HP C and HP C++ compilers do not provide support for weak symbols. The HP-UX 11i v2 and later assembler (/usr/ccs/bin/as) provides support using the .weak directive. Example 7-3 “Weak Function Binding Using ASM” defines weakfunc to be a weak binding to func. Details on the assembler can be found in the Itanium Architecture Assembly Language Reference Guide. -- I guess that confirms your suspicion that aCC does not support weak symbols and my results that .weak is supported by HP's assembler. --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #194 from Peter Bisroev --- (In reply to dave.anglin from comment #193) > I presume that if you compile main.cc with g++, hello() becomes weak. You > could test with a second instance of hello. Yes, sorry forgot to mention that. When I compile with gcc hello() becomes weak as expected. One question though, what do you mean with the second instance of hello? > It is clear aCC doesn't support although I think HP as and ld do with some > caveats. HP's weak > support evolved from secondary definition symbols (sdef). This was never > well documented and > the use we make of these symbols on 32-bit pa came from looking at HP's > linker code. > > I'm thinking that the call to printf goes through PLT because it is resolved > in a shared library. This theory makes sense based on my testing so far. > The R_IA64_PCREL21B relocation works except for code size issues. HP ld > doesn't remove unnecessary > weak instances and for some reason it doesn't do calls to weak functions > through the PLT when they > aren't resolved in a shared library. > > So, I think we either need to use a long branch (brl) to weak functions or > we need to change the define > of MAKE_DECL_ONE_ONLY to avoid the use of weak. We can try replacing weak > functions with comdat > functions, etc. Currently, we have > > #define MAKE_DECL_ONE_ONLY(DECL) (DECL_WEAK (DECL) = 1) > > The latter is probably the better solution as it will result in smaller > code, but it's trickier. I'm not sure about > using brl in the 32-bit hpux runtime. > > Dave The comdat testing that I have performed in comment 181 and comment 185 by forcing the use of comdat with --enable-comdat definitely made things better as we got a significant reduction in PCREL21B linking errors. However some still remained. Is it because the use of --enable-comdat did not apply to all the code (such as libraries), or even when usage of comdat is forced, HP's ld still keeps unnecessary instances around? Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #192 from Peter Bisroev ---
(In reply to dave.anglin from comment #191)
> On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
> The problem seems to be that HP ld doesn't handle the PCREL21B relocation
> correctly when it refers
> to a weak function (i.e., it doesn't direct the call through the PLT). At
> the same time, weak references
> don't seem to work with aCC.
>
> As far as I can tell, the PCREL21B is generated by gas in
> gas/config/tc-ia64.c at line 5919. You could try
> changing it to PCREL21BI to see if that helps (run binutils testsuite before
> installing) but the change doesn't
> seem correct. We might need to generate a 32-bit branch to weak functions
> in gcc.
Hi Dave, thanks for the hint! I have patched by binutils 2.32 as shown in the
diff below.
--
*** ./gas/config/tc-ia64.c.orig Fri Feb 21 23:52:59 2020
--- ./gas/config/tc-ia64.c Fri Feb 21 23:54:04 2020
***
*** 5919,5925
else if (opnd == IA64_OPND_TGT25b)
fix->code = BFD_RELOC_IA64_PCREL21M;
else if (opnd == IA64_OPND_TGT25c)
! fix->code = BFD_RELOC_IA64_PCREL21B;
else if (opnd == IA64_OPND_TGT64)
fix->code = BFD_RELOC_IA64_PCREL60B;
else
--- 5919,5925
else if (opnd == IA64_OPND_TGT25b)
fix->code = BFD_RELOC_IA64_PCREL21M;
else if (opnd == IA64_OPND_TGT25c)
! fix->code = BFD_RELOC_IA64_PCREL21BI;
else if (opnd == IA64_OPND_TGT64)
fix->code = BFD_RELOC_IA64_PCREL60B;
else
--
After recompiling binutils gas failed only two more unit tests than before:
--
FAIL: ia64 tls
FAIL: ia64 relocations
--
After looking at both of these I guess it is expected as both of them expect
PCREL21B instead of PCREL21BI.
I have then attempted to recompile gcc 4.7.4 with this patched gas.
Unfortunately that fails during linking when xgcc tries to build
hpux64/libgcc_s.so.0.tmp in 64bit mode during stage 1. An example of an error
is:
--
ld: Unsatisfied symbol"calloc" in file "emutls_s.o": Expect to be defined in
the load module.
--
Taking a quick look at emutls_s.o I can see the expected reallocation
--
$ readelf -r ./ia64-hp-hpux11.31/hpux64/libgcc/emutls_s.o | grep calloc
04d2 00220079 R_IA64_PCREL21BI calloc + 0
--
But I have not dug dipper as to why the HP linker is unhappy there. Please let
me know if you want me to do so.
> It would be useful to find out why weak doesn't work with aCC.
I wanted to see if there is some offical docs on this from HP.
Going through aCC's programmers guide
(https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US=emr_na-c05054285)
for my version of aCC ("HP C/aC++ B3910B A.06.29 [Oct 18 2016]", "as: HP
Itanium Assembler B.11.31 (HP-UX/itanium)", "ld: 92453-07 linker ld HP
Itanium(R) B.12.65 IPF/IPF"). I cannot find anything relevant to 'weak' in
section 3, or generally in that reference guide.
"Intel(R) Itanium(R) Architecture Assembly Language Reference Guide"
(https://software.intel.com/sites/default/files/m/d/4/1/d/8/asm_lan.pdf) does
mention weak symbols. This is also the same syntax that HP's as seems to
accept.
However in "HP-UX Linker and Libraries User Guide"
(https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US=a00055697en_us)
on page 59, for nm, it states:
--
Distinguish between weak and global symbols by appending * to the key letterof
weak symbols.
--
So it looks like HP's as and ld should support weak symbols so I have decided
to test it.
--
// main.cc
extern "C" {
void hello() __attribute__ ((weak));
}
int main() {
hello();
return 0;
}
--
--
// hello.s
// Adapted from "Hello World" Function Without
// Unwind Directives from Intel Itanium Architecture
// Assembly Language Reference Guide.
.section .rdata, "a", "progbits"
.align 8
.STRING1:
stringz "Hello World!!!\n"
.text
.global hello
.proc hello
hello: alloc loc2 = ar.pfs, 0, 4, 1, 0
mov loc3 = sp
mov loc1 = b0
addl out0 = @ltoff(.STRING1), gp
;;
ld8 out0 = [out0]
mov loc0 = gp
br.call.sptk.many b0 = printf
;;
mov gp = loc0
mov ar.pfs = loc2
mov b0 = loc1
mov sp = loc3
br.ret.sptk.many b0
.endp hello
.weak printf
.type printf, @function
--
--
$ aCC +w -g0 +O0 +d -c -o main.o main.cc
$ aCC +w -g0 +O0 +d -S -
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #190 from Peter Bisroev --- (In reply to dave.anglin from comment #189) > On 2020-02-16 4:21 p.m., John David Anglin wrote: > > On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote: > >> I have not had a chance to look through these in great detail, will do this > >> later today, but some things I've noticed (not sure how important they are > >> yet): > >> - aCC seems to use PCREL21BI relocations while GCC PCREL21B. > > That may be the clue. With GNU ld, only PCREL21BI goes through PLT. Need > > to look at when > > GNU as uses PCREL21BI instead of PCREL21B. I believe this selection is > > done in assembler. > Sorry, only PCREL21B goes through PLT. PCREL21BI is for local (internal) > calls. Hi Dave, I apologize for the delay in response, been a busy week so far. However I should be able to take a look at this further tomorrow. As per your recommendation I will try and find out when GNU as generates PCREL21BI relocations instead of PCREL21B. I am assuming this is what we want in order to match aCC behavior, right? Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #187 from Peter Bisroev ---
(In reply to dave.anglin from comment #183)
> On 2020-02-15 12:49 a.m., peter.bisroev at groundlabs dot com wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
> >
> > --- Comment #180 from Peter Bisroev
> > ---
> > (In reply to dave.anglin from comment #177)
> >> On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
> >>> I have tried playing around with weak using aCC, however even though it
> >>> accepts
> >>> both attribute and pragma (and complains if you misspell "weak"), both
> >>> compiler
> >>> and linker seem to ignore it. But I might have made some mistake there,
> >>> will
> >>> double check tonight.
> >> Did you look at .s output? You could also test a simple program with a
> >> weak
> >> function
> >> in two objects.
> > Sorry Dave, not 100% sure what kind of test you are talking about. Something
> > like this?
> > --
> > // func0.cpp
> >
> > int func0(int) __attribute__((weak));
> > int func0(int arg) {
> > return arg + 1;
> > }
> >
> > // main.cpp
> >
> > int func0(int) __attribute__((weak));
> > int func0(int arg) {
> > return arg + 10;
> > }
> >
> > int main(int argc, char * argv[]) {
> > return func0(argc);
> > }
> > --
> >
> Yes. Does it link okay?
Hi Dave,
No it does not link, the error I get is "ld: Duplicate symbol "func0(int)" in
files test0.o and func0.o". However it links perfectly fine when compiled with
GCC.
I have attached the results of the test above and another basic C++ one using
an inline virtual method in attachment 47847. In there you will find three
directories for results with aCC, gcc 4-7-4 and gcc 4.7.4 built with
--enable-comdat.
Additionally, in each directory you will find a build.log of how exactly was
the test built, as well as *.objdump disassembly and other info and *.readelf
dumps.
I have not had a chance to look through these in great detail, will do this
later today, but some things I've noticed (not sure how important they are
yet):
- aCC seems to use PCREL21BI relocations while GCC PCREL21B.
- When objdumping C++ test1 for comdat enabled gcc, I get "objdump: test1
symbol number 48 references nonexistent SHT_SYMTAB_SHNDX section".
Will come back to this a little later today.
Thanks!
--peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #186 from Peter Bisroev --- Created attachment 47847 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47847=edit Basic compiler tests v00
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #185 from Peter Bisroev --- (In reply to dave.anglin from comment #184) > On 2020-02-15 12:56 a.m., peter.bisroev at groundlabs dot com wrote: > > So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3 > > stage bootstrap went fine (running 'make check' now). Using that tried to > > bootstrap 4.9.4 again. We are getting a lot less PCREL21B relocation issues > > when linking cc1plus. For example: > So, it looks like we have garbage collection for COMDAT functions but not > for weak functions. I finished running 'make check' tests for gcc 4.7.4 that was compiled with --enable-comdat. I get exactly the same results as before, exactly the same tests pass and fail that you have reviewed previously. So I guess we can say this build works as good as the one without --enable-comdat. The difference however is in reduced number of PCREL21B errors as show in my comment before. Additionally I have tried compiling 8.3.0 with comdat enabled 4.7.4 (just like I tried with 4.9.4). In this case we also get a significantly reduced number of PCREL21B errors. For example, originally for cc1plus, we went from 569 errors to 58. > I think we need to look at branch types - "br.call.sptk.many" versus > "br.call.dptk.many". I suspect using > the latter would fix the PCREL21B relocation issues. Sorry for my lack of knowledge here, would you be able to explain this a bit more if you get a chance? I looked up IA-64 arch manual, and the diff between these two branch types is that '.sptk' one uses static taken prediction strategy and '.dptk' uses dynamic taken prediction strategy. The mechanics here make sense to me but I am not sure I understand how they relate to the relocation issue here. Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #181 from Peter Bisroev --- (In reply to Peter Bisroev from comment #179) > (In reply to dave.anglin from comment #178) > > The configure test didn't find support for COMDAT groups even though aCC and > > HP ld > > support them. So, there's likely something incompatible with the default > > support for COMDAT > > groups. > > > > Could you look at configure test and see why it fails? > > Looking at configure in 4.9.4, there are two COMDAT related tests. > > First test "checking assembler for .nsubspa comdat" fails when it tries to > assemble: > -- > .SPACE $TEXT$ > .NSUBSPA $CODE$,COMDAT > -- > The errors are: > -- > conftest.s:2: Error: unknown pseudo-op: `.nsubspa' > conftest.s:1: Error: .space specifies non-absolute value > -- > Looking through gas manual it looks like '.nsubspa' and that variation of > '.space' are only supported for HPPA. > > The second test "checking assembler for COMDAT group support (GNU as)" > passes when it tries to assemble: > -- > .section .text,"axG",@progbits,.foo,comdat > -- > > However just below this check, configure looks for GNU linker, and if one > not found, disables COMDAT group support even though the second test passed. > > However `--enable-comdat` configure flag seems to override this behavior. I > will try to recompile 4.7.4 with it to see what happens. > > Thanks! So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3 stage bootstrap went fine (running 'make check' now). Using that tried to bootstrap 4.9.4 again. We are getting a lot less PCREL21B relocation issues when linking cc1plus. For example: With --enable-comdat: ld: The value 0xfdfd38c0 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x92 in section index 139 of file libbackend.a[gcse.o] ld: The value 0xfdfea070 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x22 in section index 402 of file libbackend.a[gimple.o] Without --enable-comdat: ld: The value 0xfdf6d810 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 74 of file libbackend.a[function.o] ld: The value 0xfdeeb8b0 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 79 of file libbackend.a[function.o] ld: The value 0xfdfd81f0 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 60 of file libbackend.a[gimple.o] ld: The value 0xfdf562a0 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 65 of file libbackend.a[gimple.o] ld: The value 0xfde4c890 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x22 in section index 207 of file libbackend.a[gimple.o] ld: The value 0xfde4ae90 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x22 in section index 212 of file libbackend.a[gimple.o] ld: The value 0xfdf81640 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 59 of file libbackend.a[gimple-expr.o] ld: The value 0xfde83ea0 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x22 in section index 21 of file libbackend.a[gimple-iterator.o] ld: The value 0xfde82940 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x22 in section index 26 of file libbackend.a[gimple-iterator.o] ld: The value 0xfdf96310 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 85 of file libbackend.a[gimple-fold.o] ld: The value 0xfde8cde0 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x22 in section index 106 of file libbackend.a[gimple-fold.o] ld: The value 0xfde8b440 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x22 in section index 111 of file libbackend.a[gimple-fold.o] ld: The value 0xfdec46b0 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x22 in section index 172 of file libbackend.a[gimple-pretty-print.o] ld: The value 0xfdff2690 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0xc2 in section index 91 of file libbackend.a[ipa-inline-analysis.o] ld: The value 0xfdfed180 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x172 in section index 96 of file libbackend.a[ipa-inline-analysis.o] ld: The value 0xfdfec950 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x842 in section index 96 of file libbackend.a[ipa-inline-analysis.o] ld: The value 0xfdfec8b0 does not fit when applying the relocation
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #180 from Peter Bisroev ---
(In reply to dave.anglin from comment #177)
> On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
> > I have tried playing around with weak using aCC, however even though it
> > accepts
> > both attribute and pragma (and complains if you misspell "weak"), both
> > compiler
> > and linker seem to ignore it. But I might have made some mistake there, will
> > double check tonight.
> Did you look at .s output? You could also test a simple program with a weak
> function
> in two objects.
Sorry Dave, not 100% sure what kind of test you are talking about. Something
like this?
--
// func0.cpp
int func0(int) __attribute__((weak));
int func0(int arg) {
return arg + 1;
}
// main.cpp
int func0(int) __attribute__((weak));
int func0(int arg) {
return arg + 10;
}
int main(int argc, char * argv[]) {
return func0(argc);
}
--
Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #179 from Peter Bisroev --- (In reply to dave.anglin from comment #178) > The configure test didn't find support for COMDAT groups even though aCC and > HP ld > support them. So, there's likely something incompatible with the default > support for COMDAT > groups. > > Could you look at configure test and see why it fails? Looking at configure in 4.9.4, there are two COMDAT related tests. First test "checking assembler for .nsubspa comdat" fails when it tries to assemble: -- .SPACE $TEXT$ .NSUBSPA $CODE$,COMDAT -- The errors are: -- conftest.s:2: Error: unknown pseudo-op: `.nsubspa' conftest.s:1: Error: .space specifies non-absolute value -- Looking through gas manual it looks like '.nsubspa' and that variation of '.space' are only supported for HPPA. The second test "checking assembler for COMDAT group support (GNU as)" passes when it tries to assemble: -- .section .text,"axG",@progbits,.foo,comdat -- However just below this check, configure looks for GNU linker, and if one not found, disables COMDAT group support even though the second test passed. However `--enable-comdat` configure flag seems to override this behavior. I will try to recompile 4.7.4 with it to see what happens. Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #176 from Peter Bisroev --- (In reply to dave.anglin from comment #174) > On 2020-02-13 2:44 p.m., dave.anglin at bell dot net wrote: > > The first thing to note is aCC doesn't use weak. Instead, it uses COMDAT > > sections. Probably, HP ld does support > > weak but it's unlikely there is support for linkonce sections. See defines > > in > > config/pa/som.h. There we implimented > > one only support using the linker's COMDAT support. > Is HAVE_COMDAT_GROUP defined in auto-host.h? For both 4.9.4 and 8.3.0, gcc/auto-host.h contains only one reference to that: /* Define 0/1 if your assembler and linker support COMDAT groups. */ #ifndef USED_FOR_TARGET #define HAVE_COMDAT_GROUP 0 #endif
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #175 from Peter Bisroev --- (In reply to dave.anglin from comment #173) > On 2020-02-13 1:11 p.m., peter.bisroev at groundlabs dot com wrote: > > If I try to compare this to aCC dump in attachment 47840 [details], I do > > not see any > > calls to weak. Equivalent section to the above dump in gimple-expr.s > > (_Z18tree_operand_checkPK9tree_nodeiPKciS3_) can be found on line 9007, also > > gimple-expr.o.objdump on line 2099. I believe the place where with gcc we > > expect to see a call to tree_operand_length() through PCREL21B reloc, aCC > > does > > similar thing in gimple-expr.s line 9098 (gimple-expr.o.objdump line 2181). > I looked at the definition and branches to > _Z18tree_operand_checkPK9tree_nodeiPKciS3_ > in the gimple-expr.s file that you uploaded. > > We have the following: > > .type _Z18tree_operand_checkPK9tree_nodeiPKciS3_,@function > .global _Z18tree_operand_checkPK9tree_nodeiPKciS3_ > > .size _Z18tree_operand_checkPK9tree_nodeiPKciS3_, 784 > // Routine [id=0064] ( tree_operand_check ) > > // === > .secalias .abe$170.text, ".text" > .section .abe$170.text = "axC", "progbits", .abe$comdat0010 > .align 16 > .proc _Z18tree_operand_checkPK9tree_nodeiPKciS3_ > ..L0: > // $start ARid768 = ;; // A > > ..L2: > _Z18tree_operand_checkPK9tree_nodeiPKciS3_:: > .prologue > // $entry ARid770, S:r32, S:r33, S:r34, S:r35, S:r36 = ;; // > A [tree.h: 3177/1] > //file/line/col tree.h/3177/1 > .save ar.pfs, r39 > alloc r39 = ar.pfs, 5, 4, 5, 0 // M [tree.h: 3177/1] > > br.ret.dptk.many rp ;; // B [tree.h: 3181/3] > > ..L1: > // $end ;; // A > > .endp _Z18tree_operand_checkPK9tree_nodeiPKciS3_ > > nop.m 0 // M > nop.i 0 // I > nop.m 0 // M > nop.m 0 // M > br.call.dptk.many rp = _Z18tree_operand_checkPK9tree_nodeiPKciS3_# > ;; // B [gimple-expr.c: 658/3] > add r9 = 0, r8 // M [gimple-expr.c: > 658/3] > > .secalias .abe$comdat0010, > "_Z18tree_operand_checkPK9tree_nodeiPKciS3_" > > The first thing to note is aCC doesn't use weak. Instead, it uses COMDAT > sections. Probably, HP ld does support > weak but it's unlikely there is support for linkonce sections. See defines > in config/pa/som.h. There we implimented > one only support using the linker's COMDAT support. > > Regarding the call to _Z18tree_operand_checkPK9tree_nodeiPKciS3_, this is > preceeded by a bunch of nops. This is > probably to allow linker to modify call should it select a different > instance of _Z18tree_operand_checkPK9tree_nodeiPKciS3_. Thank you for the explanation Dave! I have tried playing around with weak using aCC, however even though it accepts both attribute and pragma (and complains if you misspell "weak"), both compiler and linker seem to ignore it. But I might have made some mistake there, will double check tonight.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #172 from Peter Bisroev ---
Hi Dave,
(In reply to dave.anglin from comment #168)
> There seems to be something broken regarding stub insertion for calls to
> weak functions. Are we
> using the correct branch form for calls to weak? There doesn't seem to be a
> problem with branches
> to functions that aren't defined in the module.
>
> Could you try compiling sancov.c from gcc-8 with aCC in C++ mode. Use -S to
> get assembler output.
> What happens to weak calls (e.g., the one I pointed out previously)?
Unfortunately as mentioned in comment 165 I was unable to get aCC to compile
sancov.c from gcc 8.3.0 or use HP's assember with gcc generated .s output.
However I was able to reproduce the same relocation issue when attempting to
compile gcc 4.9.4 and at the same time was able to compile one of the
problematic files (gimple-expr.c) with aCC as well.
I have attached relevant results as you have requested in attachment 47828. But
I did not see the relevant functions appearing in object file compiled with aCC
(attachment 47829). I took a look at it a bit more last night and realized that
the code that was causing relocation issues with gcc was not compiled in when
using aCC. After a bit of mucking around with aCC to approximate compilations
options to as close as possible to gcc ones (so -O0, no inlining, target arhc,
etc...) and enabling gnu mode and a few defines allowed me to compile the
relevant parts in to the object. You can see the .o and .s from aCC as well as
a few more dumps in attachment 47840.
Just to make sure I do not waste your time, I tried to get some info for you
from the gcc dumps (attachment 47828) as you have previously requested for
sancov.c (please let me know if I made any mistakes there).
Original linker error was:
ld: The value 0xfdf81640 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 59 of file
libbackend.a[gimple-expr.o]
Looking for section 59's name and confirming with readlef:
$ elfdump -C -D 59 -h gimple-expr.o
gimple-expr.o:
*** Section Header ***
Idx: 59
Section: .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
Type:PBIT Flags: -- EA-
Vaddr: 0x Offset: 0xcd50
Size:0x0240 Link:
Info: Align: 0x0010
Entsize: 0x
$ readelf -S -W gimple-expr.o | grep '\[59\]'
[59] .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_ PROGBITS
00cd50 000240 00 AX 0 0 16
Dumping relocations for this section:
$ objdump -r -j .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
gimple-expr.o
gimple-expr.o: file format elf32-ia64-hpux-big
RELOCATION RECORDS FOR
[.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_]:
OFFSET TYPE VALUE
0071 LTOFF22X .rodata
0080 LDXMOV.rodata
0082 LTOFF22X .rodata+0x0188
0090 LDXMOV.rodata+0x0188
0092 PCREL21B _Z10expr_checkPK9tree_nodePKciS3_
0102 PCREL21B .text
01d2 PCREL21B _Z25tree_operand_check_failediPK9tree_nodePKciS3_
And we can see the PCREL21B relocation at offset 0x102 there.
And here is a disassembly of this section showing the same PCREL21B relocation
at the same offset. If I understand the code correctly than that should be a
call to tree_operand_length() at that offset.
$ objdump -d -C -S -t -r -j
.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_ gimple-expr.o
gimple-expr.o: file format elf32-ia64-hpux-big
SYMBOL TABLE:
ld .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
wF .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
0240 tree_operand_check(tree_node const*, int, char const*, int, char
const*)
Disassembly of section
.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_:
:
}
inline const_tree *
tree_operand_check (const_tree __t, int __i,
const char *__f, int __l, const char *__g)
{
0: 00 30 39 12 80 05 [MII] alloc r38=ar.pfs,14,9,0
6: 70 02 30 00 42 80 mov r39=r12
c: 01 65 fc 8c adds r12=-48,r12
10: 01 00 00 00 01 00 [MII] nop.m 0x0
16: 50 02 00 62 00 00 mov r37=b0
1c: 05 08 00 84 mov r40=r1;;
20: 0b 70 c0 4f 3f 23 [MMI] adds r14=-16,r39;;
26: 00 00 39 20 23 c0 st4 [r14]=r32
2c: 41 3f fd 8c adds r14=-12,r39;;
30: 02 00 84 1c 90 11
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #171 from Peter Bisroev --- Comment on attachment 47839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47839 GCC 4.9.4 gimple-expr.c dump (aCC) Obsoleted by attachment 47840 as in this attachment inlining with aCC was not fully disabled.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Peter Bisroev changed: What|Removed |Added Attachment #47839|0 |1 is obsolete|| --- Comment #170 from Peter Bisroev --- Created attachment 47840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47840=edit GCC 4.9.4 gimple-expr.c dump (aCC) V3
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Peter Bisroev changed: What|Removed |Added Attachment #47829|0 |1 is obsolete|| --- Comment #169 from Peter Bisroev --- Created attachment 47839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47839=edit GCC 4.9.4 gimple-expr.c dump (aCC)
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #167 from Peter Bisroev --- (In reply to dave.anglin from comment #166) > The problem is is the branch offset is too big. I believe GNU ld will > create a PLTOFF > entry in the PLT to handle this, but that's not happening with HP ld. > > In pa, we have have the -mlong-calls option which avoids these pc-relative > branches. > > It would be helpful to know how aCC avoids this problem. ... > It's the branch distance distance that's the main problem. Weak functions > are available > in C but they are much more common in C++. Thank you for the explanation Dave, Tonight I have been trying to find a test case where this problem can be reproduced with gcc and then compiled with aCC. Unfortunately no luck so far. With objdump I can see PCREL21B relocations in my .o files. However after the final linking, disassembly shows direct short branch if the distance is small enough and a call through a stub with brl.few if the distance is large enough. I have almost no experience with IA-64 arch, but this behavior seems expected to me. I will keep trying. Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #165 from Peter Bisroev --- Hi Dave, (In reply to dave.anglin from comment #162) > On 2020-02-12 10:38 a.m., peter.bisroev at groundlabs dot com wrote: > > The exact HP linker errors from linking cc1, cc1plus and lto1 were (I was > > compiling in parallel): > > > > ld: The value 0xfdc6eaf0 does not fit when applying the relocation > > PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file > > libbackend.a[sancov.o] > > The value doesn't fit in 21 bits. > > The relocations are introduced by the assembler. You might check if the HP > assembler can assemble sancov.s and see what type of relocations are used. > You can run readelf on .o to see relocations. Unfortunately I was not able to assemble sancov.s using HPs assembler due to too many syntax errors. So I tried to find something that can be compiled with aCC. This might be a wrong approach but it was quick to test out so decided to give it a go :) > It looks like the problem is branches to weak functions. I went back to gcc 4.9.4 and tried doing stage1 bootstrap with '-O0'. As expected, we got the same error (only relevant one shown for gimple-expr.c): ld: The value 0xfdf81640 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 59 of file libbackend.a[gimple-expr.o] The dump for gimple-expr.c Unless I am mistaken, from the dump in attachment 47828 it is a weak relocation. I was then able to compile the same file but with aCC and attached results (including an elfdump) in attachment 47829. Unless I am mistaken, weak relocations are not being used. Is this something expected? Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #164 from Peter Bisroev --- Created attachment 47829 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47829=edit GCC 4.9.4 gimple-expr.c dump (aCC)
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #163 from Peter Bisroev --- Created attachment 47828 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47828=edit GCC 4.9.4 gimple-expr.c dump (gcc)
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #161 from Peter Bisroev --- Hi Dave, I have added attachment 47824 (sancov.dump.tar.xz) containing .o, .s and RTL dumps as you have requested. It is for the compilation of gcc/sancov.c in gcc 8.3.0 using 4.7.4 as a host compiler. The exact compilation command line was: /home/pbisroev/local/aCC/32/gcc-4.7.4-self-bootstrap/bin/g++ -std=gnu++98 \ -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -D_XOPEN_SOURCE_EXTENDED -g -O0 \ -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall \ -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format \ -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long \ -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H \ -I. -I. -I/home/pbisroev/src/gcc-8.3.0/gcc \ -I/home/pbisroev/src/gcc-8.3.0/gcc/. \ -I/home/pbisroev/src/gcc-8.3.0/gcc/../include \ -I/home/pbisroev/src/gcc-8.3.0/gcc/../libcpp/include \ -I/home/pbisroev/local/aCC/32/include \ -I/home/pbisroev/local/aCC/32/include \ -I/home/pbisroev/local/aCC/32/include \ -I/home/pbisroev/src/gcc-8.3.0/gcc/../libdecnumber \ -I/home/pbisroev/src/gcc-8.3.0/gcc/../libdecnumber/dpd \ -I../libdecnumber -I/home/pbisroev/src/gcc-8.3.0/gcc/../libbacktrace \ -o sancov.o -MT sancov.o -MMD -MP -MF ./.deps/sancov.TPo \ /home/pbisroev/src/gcc-8.3.0/gcc/sancov.c \ -save-temps -da The exact HP linker errors from linking cc1, cc1plus and lto1 were (I was compiling in parallel): ld: The value 0xfdc6eaf0 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file libbackend.a[sancov.o] ld: The value 0xfd8bf620 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file libbackend.a[sancov.o] ld: The value 0xfdd8c540 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file libbackend.a[sancov.o] Please let me know if there is anything missing. Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #160 from Peter Bisroev --- Created attachment 47824 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47824=edit .o, .s and RTL dumps
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #159 from Peter Bisroev --- (In reply to dave.anglin from comment #157) > On 2020-02-11 12:27 p.m., peter.bisroev at groundlabs dot com wrote: > > Just to confirm though, using gcc 4.7.4 that I have previously compiled with > > aCC that adequately passed 'make check' tests, bootstrap gcc 4.7.4 with > > default > > build flags for STAGE1. Observe PCREL21B errors and manually recompile > > affected > > .c with "-save-temps -da". Is that correct? > Right, we want to build stage1 with -O0. You can rebuild 4.7.4 or any other > gcc version > that demonstrates the PCREL21B error. Keep the build log so you can copy > the compile > options for the failing object. > > > > Do you want to apply any patches to 4.7.4 or compile original code as I have > > done previously? > No. We need to figure out why 4.7.4 generates incorrect PCREL21B > relocations. Then, > maybe we patch it. Understood, thank you Dave. Will do that tonight.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #158 from Peter Bisroev --- (In reply to dave.anglin from comment #156) > On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote: > > However the above can be compiled with -O0 with the same compiler. So I > > changed > > my build line to use -O0 as well: > > -- > > gmake \ > > STAGE1_CFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \ > > STAGE1_CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \ > > STAGE1_TFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \ > > BOOT_CFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \ > > CFLAGS_FOR_TARGET='-g -O0 -D_XOPEN_SOURCE_EXTENDED' bootstrap > Regarding the _XOPEN_SOURCE_EXTENDED define, I changed the PA-RISC backend > to automatically > enable the XOPEN extensions. See pa-hpux11.h. This makes the HP-UX c++ > environment closer to > Linux. Will take a look, thanks! > I doubt you need to define STAGE1_TFLAGS. Likewise for CFLAGS_FOR_TARGET. > You may want BOOT_CXXFLAGS. Actually this is what I tried first. However during configure inside libraries -O2 was still being used. So I just threw everything in there to see what happens :)
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #155 from Peter Bisroev --- (In reply to dave.anglin from comment #154) > On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote: > > We already know that we currently cannot compile stage1 with -O0 as it > > causes > > binaries to become huge and we get PCREL21B errors that were already > > described > > here from HP's linker. > I believe this issue needs to be fixed in bootstrap compiler. If I go back > to the initial report, we had: > > ld: The value 0xfdf68820 does not fit when applying the relocation > PCREL21B for symbol ".text" at offset 0x102 in section index 74 of > file libbackend.a[function.o] > > We need to go back and recompile function.c. Add "-save-temps -da". This > will generate .s file and rtl dumps. Thank you Dave, I think I should be able to do that later on tonight. Just to confirm though, using gcc 4.7.4 that I have previously compiled with aCC that adequately passed 'make check' tests, bootstrap gcc 4.7.4 with default build flags for STAGE1. Observe PCREL21B errors and manually recompile affected .c with "-save-temps -da". Is that correct? Do you want to apply any patches to 4.7.4 or compile original code as I have done previously? > I suspect the value above needs to be zero extended rather than pointer > extended. As soon as I've read that, that error started to make sense :) Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #153 from Peter Bisroev ---
Hi Everyone, just wanted to give you an update on where I am at the moment.
Unfortunately I did not have much time to dig into this more, but last night
while trying to figure out what is causing those ICEs at the end of stage1 I
noticed something interesting.
All of the below is in reference to gcc 8.3.0 being bootstrapped with 4.7.4.
8.3.0 is patched with the patches from comment#72 and comment #63 as suggested
by Dave and EML. Technically these are the subset of the patches provided by
the The Written Word. However using the rest of patches from The Written Word's
patch set did not seem to make a difference in my testing so far so I am trying
to keep the changes to the minimum for the moment (please let me know if this
is a wrong approach).
We already know that we currently cannot compile stage1 with -O0 as it causes
binaries to become huge and we get PCREL21B errors that were already described
here from HP's linker. If I compile stage1 with -Os or -O2, I get ICEs at the
end of stage1 from cc1 during selftesting. I will look into this more,
hopefully tonight, 'make selftest-gdb' is really convenient here.
However while digging around selftesting, I noticed if I compile stage1 with
-O1, self tests pass without issues. Furthermore, if I run the self test build
command:
--
/home/pbisroev/src/build/./gcc/xgcc \
-B/home/pbisroev/src/build-O1/./gcc/ \
-xc -nostdinc /dev/null -S -o /dev/null \
-fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests
--
With any optimization flag, -O[s012], all self tests pass as long as -O1 is set
in STAGE1_CFLAGS. If I then further restrict optimization to -O1 to libraries
as well (at least from how it appears to work now), build fails at 'Configuring
stage 1 in ia64-hp-hpux11.31/libgcc' while trying to test compile something
simple as below:
--
/* confdefs.h */
#define PACKAGE_NAME "GNU C Runtime Library"
#define PACKAGE_TARNAME "libgcc"
#define PACKAGE_VERSION "1.0"
#define PACKAGE_STRING "GNU C Runtime Library 1.0"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL "http://www.gnu.org/software/libgcc/;
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
--
However the above can be compiled with -O0 with the same compiler. So I changed
my build line to use -O0 as well:
--
gmake \
STAGE1_CFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \
STAGE1_CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \
STAGE1_TFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \
BOOT_CFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \
CFLAGS_FOR_TARGET='-g -O0 -D_XOPEN_SOURCE_EXTENDED' bootstrap
--
And now I get much further, specifically the error I get is
--
/home/pbisroev/src/build/./gcc/xgcc -shared-libgcc
-B/home/pbisroev/src/build/./gcc -nostdinc++
-L/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/src
-L/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/src/.libs
-L/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs
-B/home/pbisroev/local/aCC/32/gcc-8.3.0/ia64-hp-hpux11.31/bin/
-B/home/pbisroev/local/aCC/32/gcc-8.3.0/ia64-hp-hpux11.31/lib/ -isystem
/home/pbisroev/local/aCC/32/gcc-8.3.0/ia64-hp-hpux11.31/include -isystem
/home/pbisroev/local/aCC/32/gcc-8.3.0/ia64-hp-hpux11.31/sys-include -g -O0
-D_XOPEN_SOURCE_EXTENDED -x c++-header -nostdinc++ -g -O2 -I
/home/pbisroev/local/aCC/32/include
-I/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31
-I/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include
-I/home/pbisroev/src/gcc-8.3.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/home/pbisroev/src/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h \
-o ia64-hp-hpux11.31/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/ios:41,
from
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/istream:38,
from
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/sstream:38,
from
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/complex:45,
from
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/ccomplex:39,
from
/home/pbisroev/src/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h:52:
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/bits/localefwd.h:113:34:
error: macro "isblank" passed 2 arguments, but takes just 1
isblank(_CharT, const locale&);
...
In file included from
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/bits/basic_ios.h:37,
from
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/ios:44,
from
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/istream:38,
from
/home/pbisroev/src/build/ia64-hp-hpux11.31/libstdc++-v3/include/sstream:38,
from
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #152 from Peter Bisroev --- (In reply to David Malcolm from comment #151) > (In reply to Peter Bisroev from comment #139) > > [...] > > > I am not sure how these selftests work yet but will take a look into them to > > see if we can reproduce a reliable minimal test case. > > FWIW, I added the selftest framework to gcc, in the hopes that failing early > in a minimal reproducer is better than having lots of DejaGnu failures later > on. > > "make selftest-gdb" is a precanned way to debug things, though I don't know > how well it will work for your configuration. Hi David, thank you for this information, it is actually really helpful to understand where this is comming from. I was actually able to get GNU GDB and Python working so 'make selftest-gdb' turned out to be really handy!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #149 from Peter Bisroev --- (In reply to The Written Word from comment #148) > (In reply to The Written Word from comment #144) > > We have a build running that seems to be going well. We are using gcc-4.9.4 > > to build 8.3.0. I will attach the current patch set we are building against. > > We're running into the same issues as encountered in comment#74. I think > this is because of our patch to address PR66319 so I am attempting a build > without it. We will then probably run into the problem in comment#76 but > I'll try to fix that manually and continue the build. Did you build your 4.9.4 or you are using a pre-built one? I am trying to build 4.9.4 using my 4.7.4 but at the end of stage1 I get -- conftest.c:15:3: internal compiler error: Illegal instruction -- This is a similar error as described in comment#21. Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #147 from Peter Bisroev --- (In reply to The Written Word from comment #145) > Created attachment 47799 [details] > gcc-8.3.0 patches v2 > > v2 of our patch set. Thank you The Written Word. However I still get an ICE failure with selftests as before, although at a different place. I notice you said that you are bootstrapping with 4.9.4 and I am with 4.7.4. I will try to get 4.9.4 bootstrapped with 4.7.4 and see if that makes any difference. I will also try troubleshooting suggested by Dave. Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #140 from Peter Bisroev --- (In reply to EML from comment #138) > I think you need the patch from comment 63 as well Hi EML, I apologize, was meant to respond to you directly but put everything in one response under comment#139 to keep everything together. Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #139 from Peter Bisroev --- (In reply to dave.anglin from comment #137) > You need to at least apply patch from comment#72. This fixes regression > from 4.7.x. You should also > consider the last patch set from The Written Word. It was stated that it's > possible to get a full bootstrap > with it although there are issues. (In reply to dave.anglin from comment #138) > I think you need the patch from comment 63 as well Thank you for the suggestions Dave. I have applied patch from comment#72 and the behavior did not change. With default make command: gmake -j8 bootstrap \ STAGE1_CFLAGS="-D_XOPEN_SOURCE_EXTENDED" \ STAGE1_CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED" I get PCREL21B errors during linking as were shown previously. When using -Os with STAGE1_CFLAGS and STAGE1_CXXFLAGS I get internal compiler error as described in my comment#135. I also took a look at the last patch set in attachment 46623 from The Written Word in comment#94 as you have suggested. It actually contains the patches that you have already mentioned: - the patch from comment#72 in r214747-regression.patch - the patch from comment#63 in PR60465-regression.patch So I applied this entire patch set and with default make command as above, I get exactly the same thing as before, PCREL21B errors during linking of stage1. If I compile stage 1 with -Os or -O2 I get internal compiler error as described above. However my ICEs seem to happen at a different stage of compilation than what has been reported already. It is essentially this command: /home/pbisroev/src/build/./gcc/xgcc \ -B/home/pbisroev/src/build/./gcc/ \ -xc -nostdinc /dev/null -S -o /dev/null \ -fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests Which eventually calls cc1 that ICEs: /home/pbisroev/src/build/./gcc/cc1 -quiet -nostdinc -v \ -iprefix /home/pbisroev/src/build/gcc/../lib/gcc/ia64-hp-hpux11.31/8.3.0/ \ -isystem /home/pbisroev/src/build/./gcc/include \ -isystem /home/pbisroev/src/build/./gcc/include-fixed \ /dev/null -quiet -dumpbase null -auxbase-strip /dev/null \ -version \ -fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests \ -o /dev/null I am not sure how these selftests work yet but will take a look into them to see if we can reproduce a reliable minimal test case. However this is what I see in GDB for now: (gdb) r Starting program: /home/pbisroev/src/build/./gcc/cc1 -quiet -nostdinc -iprefix /home/pbisroev/src/build/gcc/../lib/gcc/ia64-hp-hpux11.31/8.3.0/ -isystem /home/pbisroev/src/build/./gcc/include -isystem /home/pbisroev/src/build/./gcc/include-fixed /dev/null -quiet -dumpbase null -auxbase-strip /dev/null -version -fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests GNU C17 (GCC) version 8.3.0 (ia64-hp-hpux11.31) compiled by GNU C version 4.7.4, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C17 (GCC) version 8.3.0 (ia64-hp-hpux11.31) compiled by GNU C version 4.7.4, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 6ad5ed57899a8ef4c993d4479438 Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x79e7a40 in () (gdb) bt #0 0x79e7a40 in () warning: Attempting to unwind past bad PC 0x79e7a40 #1 0x6c81c20 in vector_builder::try_npatterns(unsigned int)+0x2a0 () #2 0x6c821d0 in vector_builder::finalize() +0x390 () #3 0x59e9b70:0 in tree_vector_builder::build()+0x30 () #4 0x5a69240:0 in () #5 0x5a8b6b0:0 in selftest::tree_c_tests()+0x7b0 () #6 0x642a510:0 in selftest::run_tests()+0x190 () #7 0x52e68e0:0 in toplev::run_self_tests()+0x60 () #8 0x52e8760:0 in toplev::main(int,char**)+0x1be0 () #9 0x64d4eb0:0 in main+0x70 () (gdb) Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #136 from Peter Bisroev ---
(In reply to Peter Bisroev from comment #135)
> #
> ##
> FAIL: .file file names
...
> $ objdump -t ./file.o
>
> ./file.o: file format elf64-x86-64
>
> SYMBOL TABLE:
> ldf *ABS* ~tilde
> ld .text .text
> ld .data .data
> ld .bss .bss
> ldf *ABS* hash#
> ldf *ABS* lower
> ldf *ABS* UPPER
> ldf *ABS* :colon
> ldf *ABS* /dir/file.s
> ldf *ABS* [brackets]
> ldf *ABS* {braces}
> ldf *ABS* slash/data
> ldf *ABS* file.s
> #
Sorry forgot to mention that this dump in the first failed test in the previous
comment is from amd64 Linux for comparison.
Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #135 from Peter Bisroev ---
Hi Dave,
I just had a chance to do some testing tonight. So attempting to bootstrap
8.3.0 in stock configuration gives PCREL21B style errors in stage1 as have been
shown before. If I compile stage1 with '-O2' only, stage1 compiles, but
straight away we get
--
/home/pbisroev/src/build/./gcc/xgcc -B/home/pbisroev/src/build/./gcc/ -xc
-nostdinc /dev/null -S -o /dev/null
-fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault
--
I did not spend much time on this now as per your recommendation we are
concentrating on GNU as errors. Out of curiosity, I compiled binutils 2.24 and
2.25.1, the version prior to gcc 4.7.4 release and the version after. For the
most part, same tests fail even then.
(In reply to dave.anglin from comment #134)
> On 2020-02-02 8:50 p.m., peter.bisroev at groundlabs dot com wrote:
> > The tests are from are binutils-2.32.
> >
> > - gas.log
> > FAIL: .file file names
> > FAIL: .file file names ordering
> > FAIL: .equ redefinitions (ELF)
> > FAIL: .set with expression
> > FAIL: good .bss / .struct data allocation directives
> > FAIL: gas/elf/missing-build-notes
> > FAIL: ia64 xdata (ilp32)
> > FAIL: ia64 unwind descriptors
> >
> > - binutils.log (they look like gas related failures)
> > FAIL: assembler generated build notes
> > FAIL: --localize-hidden test 1
> > FAIL: readelf -S bintest
> I would suggest filing binutils bug reports for the above fails. Possibly,
> some just need xfails.
> Look at each test.
Unfortunately I did not have the time to file those reports but will try to do
so on the weekend.
> The gas fails are more important than the binutils fails. The .equ, .set
> and .bss fails may be important.
So I took a brief look at these now. They seem to fall into two categories, elf
and ia64 related. The results of these are shown below. A lot of elf related
tests seem to fail on missing symbols in absoluted sections. However I did not
dig into this much further yet. Will try to do this on the weekend.
But from the test failures below, do you think this is something that we need
to resolve with binutils team first before trying to get gcc bootstrapped?
Thanks!
###
FAIL: .file file names
Test file: binutils-2.32/gas/testsuite/gas/elf/file.d
$ ../as-new -o tmpdir/file.o ./gas/elf/file.s
$ ../../binutils/objdump -t tmpdir/file.o
tmpdir/file.o: file format elf32-ia64-hpux-big
SYMBOL TABLE:
ld .text .text
ld .data .data
ld .bss .bss
$ objdump -t ./file.o
./file.o: file format elf64-x86-64
SYMBOL TABLE:
ldf *ABS* ~tilde
ld .text .text
ld .data .data
ld .bss .bss
ldf *ABS* hash#
ldf *ABS* lower
ldf *ABS* UPPER
ldf *ABS* :colon
ldf *ABS* /dir/file.s
ldf *ABS* [brackets]
ldf *ABS* {braces}
ldf *ABS* slash/data
ldf *ABS* file.s
###
FAIL: .file file names ordering
Test file: binutils-2.32/gas/testsuite/gas/elf/file-2.d
$ ../as-new -o tmpdir/file-2.o ./gas/elf/file-2.s
$ ../../binutils/objdump -t tmpdir/file-2.o
tmpdir/file-2.o: file format elf32-ia64-hpux-big
SYMBOL TABLE:
ld .text .text
ld .data .data
ld .bss .bss
l .text local1
l .text local2
l .text local3
# Below is a dump from amd64 Linux for comparison.
$ objdump -t file-2.o
file-2.o: file format elf64-x86-64
SYMBOL TABLE:
ldf *ABS* file-2.s
ld .text .text
ld .data .data
ld .bss .bss
l .text local1
ldf *ABS* aux-1.s
l .text local2
ldf *ABS* aux-2.s
l .text local3
###
FAIL: .equ r
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #133 from Peter Bisroev --- (In reply to dave.anglin from comment #132) > This has been reported before on net. Maybe you should try using flex > library. > It provides the above symbols in its library.. Building binutils with flex library resolved this issue even when building with aCC and ar and ranlib seem to work OK now. > You could try rebuilding binutils with your gcc-4.7.4 build and see how it > works out. > Run the testsuite. I actually did this with aCC and gcc-4.7.4 that was just built and ran the testsuite. With both aCC and gcc-4.7.4 the exact same tests failed. Namely: The tests are from are binutils-2.32. - gas.log FAIL: .file file names FAIL: .file file names ordering FAIL: .equ redefinitions (ELF) FAIL: .set with expression FAIL: good .bss / .struct data allocation directives FAIL: gas/elf/missing-build-notes FAIL: ia64 xdata (ilp32) FAIL: ia64 unwind descriptors - binutils.log (they look like gas related failures) FAIL: assembler generated build notes FAIL: --localize-hidden test 1 FAIL: readelf -S bintest Are any of these tests critical and would you want me to look at them in more detail? > To me, the g++ test results are reasonable. So, I would suggest you try > building gcc-8 or trunk with gcc-4.7.4. Got it, thanks. Will test on gcc-8.3.0. Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #131 from Peter Bisroev --- (In reply to dave.anglin from comment #130) > > In the meantime, I wanted to ask you. Is it OK for me to add to the PATH > > directory containing binutils-2.32 compiled with aCC prior to bootstrapping > > GCC > > 4.7.4? For bootstrapping I have provided actual utilities to configure > > script > > directly with a flag such as `--with-as`. Currently this directory contains: > > addr2line > > ar > > as > > c++filt > > elfedit > > gprof > > nm > > objcopy > > objdump > > ranlib > > readelf > > size > > strings > > strip > > As expected ld is missing from the above as on HPUX we need to use HP's > > linker. > > But what about the rest of the binaries? Will using them over comparable HP > > ones cause any issues? I am asking as I have had issues with using binutils > > provided binaries over system based ones when bootstrapping gcc on AIX. > Yes. I do it all the time. I also configure with "--with-gnu-as > --with-as=/opt/gnu/bin/as". Yes, I always use --with-as and --with-gnu-as on this platform. However after putting binutils as the first entry in the PATH, the build failed as soon as ar from binutils got invoked. After a bit of digging around looks like my ar and ranlib binaries from binutils are not working properly. For example: $ ./ar --help /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module '/usr/lib/hpux32/libl.so.1'. Killed But those symbols are present in libl.so from what I can see. For now I am still using HP's ar and ranlib, will take a look into what is going on with binutils ar and ranlib a bit later. > There is more info in the "testsuite" directory. For example, for the c > tests, look in > /gcc/testsuite/gcc/gcc.log. There similar log files for every > language and > library. Yep, I saw those the other day but thank you for the confirmation that I am looking at the right files. Anyway, today I have rerun the "gmake -j8 check-c check-c++" so that tests can find objdump, etc... Now a lot more tests have passed. The new results have been sent to gcc-testresults mailing list and you can find them here: https://gcc.gnu.org/ml/gcc-testresults/2020-02/msg00150.html For the reference, the previous test result is here: https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01318.html As you can see from the last test run, with objdump and other binutils in the PATH, the weak and hidden test failures that were seen in the original test run are not present anymore. So is there anything that we want to take a look at at the moment from the remaining failed tests? Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #129 from Peter Bisroev --- (In reply to dave.anglin from comment #127) > On 2020-01-25 9:16 p.m., peter.bisroev at groundlabs dot com wrote: > > As can be seen above, stage1 binaries are just under 9 times the size of > > final > > -O2 compiled binaries. I believe you have mentioned that this is due the > > use of > > -O0 for stage1 compilation. But is such increase as seen above expected? > The stage1 sizes are much larger than I would have expected. However, I > wouldn't worry > about it since the compiler can rebuild itself. There must be a long > pattern in ia64.md that's > used a lot. > > Let's focus on issues important for c++. Understood, thank you for the explanation. Will concentrate on getting updated test results as per my prior comment. Will get back to you as soon as I have them. Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #128 from Peter Bisroev --- (In reply to dave.anglin from comment #125) > On 2020-01-25 7:59 p.m., peter.bisroev at groundlabs dot com wrote: > > Please let me know what you would like me to try next. > Let's look at testsuite log in /gcc/testsuite/gcc. This should show > problem with weak. > For example, > UNRESOLVED: gcc.dg/weak/weak-1.c > > Also look at a hidden failure to see what's wrong with .hidden. > > Dave At this point I have noticed that the objdump could not be executed while running tests. Adding binutils-2.32 that I have compiled earlier to the PATH allowed all the weak tests to pass. I obviously made some mistake running $ make check-c check-c++ initially, so I just kicked of another test run to see what the results will be using this command $ gmake -j8 check-c check-c++ RUNTESTFLAGS="-v" Will update you once I get the results. In the meantime, I wanted to ask you. Is it OK for me to add to the PATH directory containing binutils-2.32 compiled with aCC prior to bootstrapping GCC 4.7.4? For bootstrapping I have provided actual utilities to configure script directly with a flag such as `--with-as`. Currently this directory contains: addr2line ar as c++filt elfedit gprof nm objcopy objdump ranlib readelf size strings strip As expected ld is missing from the above as on HPUX we need to use HP's linker. But what about the rest of the binaries? Will using them over comparable HP ones cause any issues? I am asking as I have had issues with using binutils provided binaries over system based ones when bootstrapping gcc on AIX. The other question I wanted to ask, is my make check command above acceptable or is there a better way to run these tests and get more information? Thank you! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #126 from Peter Bisroev --- (In reply to dave.anglin from comment #123) > Just for reference, these are the stage1 sizes for cc1 and cc1plus on hpux: > gcc-10: > -bash-4.4$ /opt/gnu/bin/size cc1 cc1plus >textdata bss dec hex filename > 552249045591924 360896 611777243a57f7c cc1 > 613758665977916 363928 677177104094a4e cc1plus > > gcc-9: > -bash-4.4$ /opt/gnu/bin/size cc1 cc1plus >textdata bss dec hex filename > 432134354681964 366408 482618072e06aaf cc1 > 466949684986436 369184 5205058831a3a9c cc1plus > > On linux, the final -O2 file sizes are about 17M. The ia64 linux sizes are > about 35M. > > Don't know why ia64 sizes are huge. (In reply to dave.anglin from comment #123) > Don't know why ia64 sizes are huge. Hi Dave, these are the sizes from my tests. They seem to be a little smaller than yours except for one (please see below) for some reason. These are the sizes for my 32bit binaries on IA64 HPUX for GCC 4.7.4 that match the 'make check' result that I've sent. Bootstrapped with host compiler set to aCC. textdata bss dec hex filename 21159330 382188 2066112 23607630168394e ./gcc/cc1 23554890 405856 2077840 2603858618d513a ./gcc/cc1plus 21159330 382188 2066112 23607630168394e ./prev-gcc/cc1 23554890 405856 2077840 2603858618d513a ./prev-gcc/cc1plus 34531022 159496 2067656 36758174230e29e ./stage1-gcc/cc1 37750763 163656 2079432 3999385126241fb ./stage1-gcc/cc1plus These are the sizes for 4.7.4 bootstrapped with host compiler set to GCC 4.7.4 built above on the same machine. I did not have to use -Os because maxtsiz was increased as per previous recommendation. textdata bss dec hex filename 21159506 382188 2066112 2360780616839fe ./gcc/cc1 23555066 405856 2077840 2603876218d51ea ./gcc/cc1plus 21159506 382188 2066112 2360780616839fe ./prev-gcc/cc1 23555066 405856 2077840 2603876218d51ea ./prev-gcc/cc1plus 208396488 1100422 2066048 211562958 c9c31ce ./stage1-gcc/cc1 229695199 1167498 2077792 232940489 de263c9 ./stage1-gcc/cc1plus As can be seen above, stage1 binaries are just under 9 times the size of final -O2 compiled binaries. I believe you have mentioned that this is due the use of -O0 for stage1 compilation. But is such increase as seen above expected? Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #124 from Peter Bisroev --- (In reply to dave.anglin from comment #122) > There is a script in contrib/test_summary. If you run it in the top of your > build directory and > direct output to a file, it will generate a script to upload the test > results to gcc. You may need > to edit the mail command. Then, it will be easy for all to see results. Hi Dave, I was able to run 'make check-c check-c++' and emailed the results to gcc-testresults mailing list. You can see that here: https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01318.html Please let me know what you would like me to try next. Thanks! --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #121 from Peter Bisroev --- > > I think it would be good to test 4.7.4 build with make check. > I will try to get that done. Unfortunately I remember trying to get guile > (required for "make check" based on the errors) to work on HPUX and not > getting anywhere. Will try getting it running over the weekend. Hi Dave, after a bit of trial and error, I was able to get Tcl, expect and DejaGnu to run from what I can tell. It also looks like that this is all that is needed to run "make check-c" and "make check-c++". Would these two checks be good enough to start? I am currently running them both for 4.7.4 bootstrapped by aCC. Thanks, --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #120 from Peter Bisroev --- (In reply to EML from comment #117) > I do appreciate someone else taking a look at this; I've had a lot of > changes at work, so this really took a back seat. And I don't have access to > the HP compiler to try things. I think this is an important step is in > comment 112: > > --- > Unfortunately, the above won't work directly because of the function name > encoding used on pa. Maybe you can look at aCC to see the assembly output > it generates to a call to a weak function. > --- > > > If we can figure out how aCC generates such weak and linkonce sections, we > should be able to make gcc do the same. > > As an aside, I have maxtsiz set to 1073741824 (per kctune) Thank you EML. Also increasing maxtsiz did help the self bootstrap of 4.7.4 with itself without needing to use "-Os" with STAGE1_CFLAGS. As far as compiling with aCC, is there anything specific that you would like to test out now? I can definitely compile that for you. Thanks, --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #119 from Peter Bisroev --- (In reply to dave.anglin from comment #116) > It's the stage1 compile flags, "-O0 -g", which generate the large binaries. > Later stages > are compiled with -O2. You could reduce the size of stage1 using "-Os" in > STAGE1_CFLAGS > and STAGE1_CXXFLAGS. Got it, that makes sense. However what I am still not sure about is why there is such as drastic difference between aCC being used as a host compiler to compiler 4.7.4 and using compiler 4.7.4 as a host compiler to bootstrap itself again. In the meantime, as per your suggestion, I have used the size tool to check the size of the text section, and it was much larger than maxtsiz. By making it larger, I was successfully able do a 3-stage self bootstrap of 4.7.4 with 4.7.4 that was initially compiled with aCC. I did not have to use "-Os" with STAGE1_CFLAGS. > I think it would be good to test 4.7.4 build with make check. I will try to get that done. Unfortunately I remember trying to get guile (required for "make check" based on the errors) to work on HPUX and not getting anywhere. Will try getting it running over the weekend. > Think your aCC build was probably fine apart from the maxtsiz issue. I > would focus on it > first. Got it, will stick to 4.7.4 bootstrapped with aCC as a host compiler. Thanks, --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #115 from Peter Bisroev --- Hi Dave, (In reply to dave.anglin from comment #114) > I would try to build 4.7.4 directly with aCC or gcc 3.3.6 (i.e., skip > intermediates). When I tried building 4.7.4 with aCC, 3-stage bootstrap completes successfully. It is only when I then use the newly built 4.7.4 to bootstrap itself again, that is when I run into trouble as cc1 blows up in size when compiled with 4.7.4. What I am not understanding though, is how come we can build everything properly, all the stages when bootstraping with aCC but not with 4.7.4 itself? I guess I can keep the binaries generated and see what is different. Will do that soon. I will also try using working 3.3.6 to try and build 4.7.4 as you have suggested. Will let you know how that goes as well. > Maybe just build C in your first attempt at 4.7.4. If I recall this thread > correctly, the issue > with C++ relates to linkonce and one-only support for C++. So far, whenever I have tried compiling just the C compiler with 4.7.4 I have used the --enable-languages='c' configure flag. However it always ends up building C++ as well. When I run "grep ^language= */config-lang.in" as mentioned here (https://gcc.gnu.org/install/configure.html), I just get 'c++' option and not 'c'. Maybe the ability to build C only has been deprecated? Or maybe I am doing something wrong? > There are patches in this thread that fix some problems but not all... Would you recommend I apply some of those patches or continue working on a clean source tree for now? > On my parisc build system, I have maxtsize set at 134217728. Maybe you > should double > your current value but that should be enough. This size command should show > the actually > text size of cc1 and cc1plus. A log of the size of cc1 is debug info. I will definitely try to use the "size" command in the future for that and adjust maxtsize accordingly. I have definitely seen the binaries three times your limit though. I will double check everything again though. Thanks for the pointer! > 4.1.2 is probably broken and has miscompiled 4.2.0. If you hit the same > issue building 4.7.4, > then it's worthwhile trying to debug the stack overflow. I have actually tried that as well. 4.1.2 cab build 4.7.4 perfectly fine, 3 stage bootstrap completes successfully. It is then that 4.7.4 fails to bootstrap itself due to maxtsize issue again. It is actually exactly the same behavior as with aCC above. I will actually repeat the test and see what are the sizes of the binaries in both cases and will let you know. By the way, unless I am mistaken, should the output of stage3 be in theory the same irrespective of whether host compiler to build stage1 was 3.3.6 or aCC? > Getting this going is not likely to be easy... Does not look like it but already, thank you for your help so far! Cheers, --peter
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Peter Bisroev changed: What|Removed |Added CC||peter.bisroev at groundlabs dot co ||m --- Comment #113 from Peter Bisroev --- Hi Dave, I know this thread has been dormant for a while, but I have access to HP-UX on IA64 architecture and might be able to assist with getting newer versions of GCC running on that platform. Unfortunately I cannot provide you with direct access to the machine, but can definitely be your eyes and ears on it :) I have read through this entire thread here and on related bugs such as 64919, and for the most part was able to reproduce everything that has been shown here already. However as you have mentioned in your last comment, we need to get a bootstrap compiler working first. So I have done some work to try and narrow down which GCC release introduced the regression (at least as far as I can see on the machine I have access to). On my machine, I have HP's C/aC++ Compiler version is B3910B A.06.29 [Oct 18 2016] and HP's linker version is 92453-07 B.12.65. I am also using GNU Make 3.82 as the newer versions seem to have process control issues but that is something separate. I just list that here so if anyone tries to reproduce my steps they have the base to go from. Here I will include brief errors as to limit the size of the message but I can of course provide more detailed errors once we know what should be looked at next. I guess, this is more of an introduction to what I have already done. Besides trying what is mentioned here in this thread already, I first tried to get a working GCC 4.7.4 using HP's C compiler as it is the last one that can be bootstrapped by a C compiler. In order to do this I've compiled 32 bit versions of the following using cc/aCC: - Binutils 2.32 without GMP, MPC, MPFR. Some minor changes needed to be done to not build info pages and to remove compilation flags not supported by aCC from WARN_WRITE_STRINGS, GCC_WARN_CFLAGS, GCC_WARN_CFLAGS_FOR_BUILD. - GMP 6.1.0 (Earlier versions fail to compile due to syntax errors.) - MPFR 3.1.4 (Earlier versions fail to compile due to syntax errors. I also had to use +O0 as otherwise some unit tests through 'make check' fail with the default optimization level of +02. This is not needed when compiling with a working GCC such as 4.1.2, please see below.) - MPC 1.0.3 Unfortunately I was not able to compile exact versions of GMP, MPFR and MPC as downloaded by contrib/download_prerequisites script due to compilation issues mentioned above. But in my testing on other platforms, using newer versions above (as used by GCC 8.3.0 and 9.2.0) did not cause any issues. So for this test I decided to stick with those. I then was able to get a clean compilation of GCC 4.7.4 using GNU assembler without any issues using the following configure and make commands: $SRCDIR/configure \ --prefix="$HOME/opt/aCC/32/$SRCBASENAME" \ --with-gmp="$HOME/opt/aCC/32" \ --with-mpfr="$HOME/opt/aCC/32" \ --with-mpc="$HOME/opt/aCC/32" \ --enable-languages='c,c++' \ --enable-version-specific-runtime-libs \ --disable-nls \ --with-gnu-as \ --with-as="$HOME/opt/aCC/32/bin/as" \ --without-gnu-ld \ --with-ld="/usr/bin/ld" \ AWK="/usr/local/bin/awk" \ M4="/usr/local/bin/m4" \ CC='cc +DD32' CXX='aCC +DD32' ~/opt/aCC/32/bin/make -j8 bootstrap ~/opt/aCC/32/bin/make -j8 install Unfortunately after that the compiler fails to bootstrap itself with the error shown below with build/stage_current set to "stage1": checking for ia64-hp-hpux11.31-gcc... /build/./gcc/xgcc -B/build/./gcc/ -B/opt/aCC/32/gcc-4.7.4-self-bootstrapped/ia64-hp-hpux11.31/bin/ -B/opt/aCC/32/gcc-4.7.4-self-bootstrapped/ia64-hp-hpux11.31/lib/ -isystem /opt/aCC/32/gcc-4.7.4-self-bootstrapped/ia64-hp-hpux11.31/include -isystem /opt/aCC/32/gcc-4.7.4-self-bootstrapped/ia64-hp-hpux11.31/sys-include exec(2): text exceeds limits checking for suffix of object files... exec(2): text exceeds limits configure: error: in `/build/ia64-hp-hpux11.31/libgcc': configure: error: cannot compute suffix of object files: cannot compile Looking through the ia64-hp-hpux11.31/libgcc/config.log I can see that the original error is: xgcc: error trying to exec '/build/./gcc/cc1': execv: Not enough space I then noticed that the size of that executable is 336194708 bytes, while the one that is used to bootstrap this compiler, /opt/aCC/32/gcc-4.7.4/libexec/gcc/ia64-hp-hpux11.31/4.7.4/cc1 is only 86758824 bytes. So that error message makes sense as new cc1 is too big to load as limited by maxtsiz kernel tunable parameter. On my machine maxtsiz is set to the default value of 100663296
