https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Peter Bisroev changed:
What|Removed |Added
CC||peter.bisroev at groundlabs
dot co
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Peter Bisroev changed:
What|Removed |Added
CC||peter.bisroev at groundlabs
dot co
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 comple
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
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 t
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 HPU
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 uplo
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 d
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
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
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
> >
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 l
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
> > F
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: fil
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
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 ke
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 se
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
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
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 ICE
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
&
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
&g
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 wit
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&action=edit
.o, .s and RTL dumps
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
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&action=edit
GCC 4.9.4 gimple-expr.c dump (gcc)
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&action=edit
GCC 4.9.4 gimple-expr.c dump (aCC)
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 we
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Peter Bisroev changed:
What|Removed |Added
Attachment #47829|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Peter Bisroev changed:
What|Removed |Added
Attachment #47839|0 |1
is obsolete|
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
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?
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
&g
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. Probabl
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
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
&g
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,
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
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&action=edit
Basic compiler tests v00
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
> >
> > --- Co
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 ha
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
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
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&rep=rep1&type=pdf).
I know it is no
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. I
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,
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 f
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
>
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 t
51 matches
Mail list logo
