https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668
Dennis Clarke changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668
--- Comment #2 from Dennis Clarke ---
Oh darn. Is this documented anywhere in the build instructions?
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
CC: dkm at gcc dot gnu.org
Target Milestone: ---
Not sure where this arrived from however here are the particulars :
System is very off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472
Dennis Clarke changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472
--- Comment #5 from Dennis Clarke ---
(In reply to Andreas Schwab from comment #3)
> You are mixing two different ada compilers:
>
> /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I.
> -Iada/generated -Iada -I../../gcc-12.2.0/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472
--- Comment #4 from Dennis Clarke ---
(In reply to Andrew Pinski from comment #2)
> >warning: "s-stalib.adb" and "gnat1drv.adb" compiled with different GNAT
> >versions
>
> Is the first thing you should look into.
>
> Since you are setting th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472
--- Comment #1 from Dennis Clarke ---
Tried again with the system binutils and I see the same error :
/bin/ld: ada/b_gnat1.o: in function `adainit':
/opt/bw/build/gcc-12.2.0_linux_amd64.004/gcc/ada/b_gnat1.adb:363: undefined
reference to `sy
erity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
CC: dkm at gcc dot gnu.org
Target Milestone: ---
Not at all sure how to proceed here thus I will file this bug report
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88633
Dennis Clarke changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #5 from Dennis Clarke ---
Not sure how useful this is but all of the following toss the same ICE :
long f(long arg){return arg + 4096;}
long f(long arg){return arg - 4096;}
long f(long arg){return 4096 + arg;}
lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
Dennis Clarke changed:
What|Removed |Added
CC||dclarke at blastwave dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720
--- Comment #8 from Dennis Clarke ---
(In reply to jos...@codesourcery.com from comment #6)
.
.
.
> In turn, that section "Include Operation" has more details. It doesn't
> mention includes with an absolute path, but I think that's because the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720
--- Comment #7 from Dennis Clarke ---
Looking at the document n1256 "ISO/IEC 9899:TC3 WG14/N125" ye C99
specifications we see section 6.10.2 Source file inclusion subsection 1
which almost seems clear :
A #include directive shall identify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720
--- Comment #5 from Dennis Clarke ---
Glad someone looked at this. I was going to try again with LLVM/Clang
and then a few other places on a few other architectures. Why bother?
However if this is "implementation defined" then we should see a
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
Target Milestone: ---
Strangely I see recent cc1 accept this :
/* echo '"hell"' | cc -o tmp tmp.c && ./tmp */
#include
int main(void) {
printf("%s\n",
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
Target Milestone: ---
This has been repeatable and while configure and stage 1 seems fine the
process fails in stage 2 thus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15210
Dennis Clarke changed:
What|Removed |Added
CC||dclarke at blastwave dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037
Dennis Clarke changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #19 from Dennis Clarke ---
status : RESOLVED FIXED <-- seems to not apply.
For the sake of showing how there really is a problem here, we can
neatly compile some trivial code and get bizarre results simply
because the platform woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #18 from Dennis Clarke ---
We are saying the same thing here.
Those same emulation routines exist elsewhere and are called _Qp_div,
_Qp_mul and _Qp_add on Solaris SPARC systems whereas those are
implemented into other places with m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #16 from Dennis Clarke ---
Dear Jakub Jelinek :
Exactly.
Yes, I think the libmpfr/libgmp seem to work perfectly here but
the real issue is that the old 970 and pre Power ISA v.2.03 spec
type hardware is a historica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
Dennis Clarke changed:
What|Removed |Added
Known to work|8.0 |
--- Comment #14 from Dennis Clarke ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #10 from Dennis Clarke ---
Well, current gcc 8 snapshot doesn't work :
nix_$
nix_$ /usr/local/gcc8/bin/gcc --version
gcc (genunix Wed Apr 18 19:16:29 GMT 2018) 8.0.1 20180415 (experimental)
Copyright (C) 2018 Free Software Foundat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #9 from Dennis Clarke ---
Thank you Sir.
I think it best if I stay with the nightly/test tarball found
at https://gcc.gnu.org/pub/gcc/snapshots/LATEST-8/ and then
I won't have to fiddle with automake/reconf etc or be too
concerne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #7 from Dennis Clarke ---
found this : https://gcc.gnu.org/pub/gcc/snapshots/LATEST-8/
I will give that a try.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #6 from Dennis Clarke ---
Following the instructions at https://gcc.gnu.org/wiki/GitMirror there is
no branch anywhere that claims to be a version 8 type.
Where is this ver 8 code hidden away ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
Dennis Clarke changed:
What|Removed |Added
Known to work|8.0 |
--- Comment #4 from Dennis Clarke ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037
--- Comment #10 from Dennis Clarke ---
Can we close this as a non-issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #16 from Dennis Clarke ---
Can we close this as a non-issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #2 from Dennis Clarke ---
Thank you very much Sir!
So then .. where is this gcc 8 that you speak of ? Still just a
nightly test release or is there an actual tarball hidden away?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #15 from Dennis Clarke ---
The real issue here is libquadmath which seems to be based
on sources from Sun Microsystems software implementation of
the 128-bit floating point operations.
see 85440
: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
Target Milestone: ---
Seems fairly clear that while the info file does get installed
into share/info/libquadmath.info the actual lib and header do
not exist.
Could be bug 55821 here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #14 from Dennis Clarke ---
Since this bug was a "bootstrap" issue I think I should close it
as simply an issue related to the garbage collector libs needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #13 from Dennis Clarke ---
Finally managed to get a decent looking three stage bootstrap to complete
without bizarre errors. Thanks to Matthias Klose for the suggestion to
get away from that gc issue entirely.
Testsuite is running h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #12 from Dennis Clarke ---
Thanks .. I'll give that a try. The real objective here is to get a simple
native bootstrap going which includes libquadmath. My concern is that
there is no support for that unless the ppc64 system has the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #10 from Dennis Clarke ---
I had not yet tested a build of gcc previous to gcc 7.x regarding
this issue. Seemed counter intuitive to revert backwards but now
I have to agree that "something changed" again in the world of
doing a boot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81934
--- Comment #2 from Dennis Clarke ---
So then, this is a case of "wait and see" wherein any previous release of
the gcc tarballs will just continue to fail?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #8 from Dennis Clarke ---
That helps actually. However I am concerned that the folks from IBM are
entirely focused on a particular power architecture and old powerpc cpus
are not considered. Freescale implementations even less so. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #6 from Dennis Clarke ---
Actually first thing I did was remove a few options from configure stage
such that I could at least get past this small bump in the road :
--enable-multiarch and --enable-multilib removed.
Configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #4 from Dennis Clarke ---
So this is not at all clear about how to continue. I did install the
new requirement or at least the "undocumented" dependency from the
Debian pkg tree :
nix:~# apt-get install libgc-dev
Reading package lis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #2 from Dennis Clarke ---
There may be a hard requirement for the "Boehm-Demers-Weiser conservative
garbage collector" from here : http://www.hboehm.info/gc/
I will have resuls in about ten hours.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
Dennis Clarke changed:
What|Removed |Added
CC||dclarke at blastwave dot org
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
Target Milestone: ---
Late in stage 3 of a perfect looking bootstrap I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037
--- Comment #9 from Dennis Clarke ---
OKay, this is a surprise to me but I will take it as a given in the linux
world that a 32-bit linker binary is not able to perform linkage with
objects that are in a different ELF class. My experiences in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037
--- Comment #7 from Dennis Clarke ---
At this point I don't see what the real issue is here on powerpc64.
The configuration stage runs fine but everything fails in stage1
because the wrong ELF class is being used. Really the entire
compiler shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #30 from Dennis Clarke ---
If that is on gcc master I have to backport to 7.2.0 and then
give it a try.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #27 from Dennis Clarke ---
Okay .. thank you. So that should not be needed for a release version
bootstrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #25 from Dennis Clarke ---
So this seems to be related to some env var BUILD_CONFIG ?
Ehere is this "BUILD_CONFIG" documented?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037
--- Comment #6 from Dennis Clarke ---
Well that change fails in stage 1 :
/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/xgcc
-B/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/
-B/usr/local/gcc7/powerpc64-unknown-li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037
--- Comment #5 from Dennis Clarke ---
ppc64$ pwd
/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003
ppc64$ date
Fri Sep 1 03:01:16 GMT 2017
ppc64$ ../gcc-7.2.0/configure --build=powerpc64-unknown-linux-gnu \
> --target=powerpc64-unknown-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037
--- Comment #4 from Dennis Clarke ---
What if the objective was to have a final 64-bit gcc binary the same as
I have on sparc :
d # ls -lap /usr/local/gcc7/bin/gcc
-rwxr-xr-x 3 root root 6275104 Aug 30 18:40 /usr/local/gcc7/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037
--- Comment #2 from Dennis Clarke ---
Seems to be a 32-bit PowerPC ELF :
ppc64$ ls -lap /usr/bin/ld
lrwxrwxrwx 1 root root 6 Jan 12 2017 /usr/bin/ld -> ld.bfd
ppc64$ ls -lap /usr/bin/ld.bfd
-rwxr-xr-x 1 root root 700284 Jan 12 2017 /usr/bin/l
: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
Target Milestone: ---
Debian 8.8 on powerpc64-unknown-linux-gnu thus :
ppc64$ ../gcc-7.2.0/config.guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #22 from Dennis Clarke ---
I think Rainer's patch as well as the addition of the env vars that
point to "gobjcopy" and "gobjdump" have sorted this out. I get a
clean three stage bootstrap now on an sparc-sun-solaris2.10 arch
which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #21 from Dennis Clarke ---
update : after 11.7 hours the bootstrap completes with no errors.
running gmake -k check now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #20 from Dennis Clarke ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #17)
> > --- Comment #16 from Dennis Clarke ---
> > This is excellent follow up ...
> > Here is the diff on 7.2.0 gcc/config/sparc/sparc.c based on y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #19 from Dennis Clarke ---
Regarding "BUILD_CONFIG" I have about ten log files and they all say :
checking for default BUILD_CONFIG...
I have never set that var to anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #16 from Dennis Clarke ---
This is excellent follow up and it looks like GNU binutils must be around
somewhere on the system for "Go" to build. Also, I always run "gmake -k check"
for the testsuite and not sure why it would look othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #12 from Dennis Clarke ---
I don't mean to ask what may seem obvious but does it make sense to
add a not required "dummy .text" section? I mean to say, is there a
valid reason why gas would add in a blank ".text" where none is actual
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
Target Milestone: ---
After installation of gcc 7.2.0 there exists two libtool "dot-la" files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #9 from Dennis Clarke ---
If I remove the "go" language from the mix then I get reasonable results :
https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg02064.html
I will install that and then try again with the "all" languages sele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #8 from Dennis Clarke ---
(In reply to Eric Botcazou from comment #7)
> See PR bootstrap/77995 for a similar issue on x86-64/Solaris.
Looks like a distant relation at best. That seemed to have something
to do with complex types and b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #5 from Dennis Clarke ---
Minor note, the gcc 6.4.0 compiler I am using was not built with support for
"go". I rarely ever build "go" as I have never had a use for it however I
really should. It is possible some small bug has slipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #4 from Dennis Clarke ---
elfdump in Solaris says stage2 section ".debug_info" size is 0x1636a2:
Section Header[37]: sh_name: .debug_info
sh_addr: 0 sh_flags: 0
sh_size: 0x1636a2sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #2 from Dennis Clarke ---
the ELF section header table seems
to be in a slightly different place between the two files :
d$ elfdump -delv stage2-gcc/go/parse.o
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dclarke at blastwave dot org
CC: cmang at google dot com
Target Milestone: ---
configure ran thus :
$ ../gcc-7.2.0/configure --build=sparc64-sun-solaris2.10 \
--target=sparc64-sun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293
Dennis Clarke changed:
What|Removed |Added
Component|bootstrap |c
--- Comment #12 from Dennis C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293
Dennis Clarke changed:
What|Removed |Added
Component|bootstrap |c
--- Comment #10 from Dennis C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293
--- Comment #6 from Dennis Clarke 2012-11-12
23:06:56 UTC ---
the following fails also .. and it fails early :
$
$ CC='gcc -m64 -g -D_XOPEN_SOURCE=600' CXX='g++ -m64 -g -D_XOPEN_SOURCE=600' \
> ../gcc-4.7.2/configure --prefix=/usr/loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293
--- Comment #5 from Dennis Clarke 2012-11-12
22:44:19 UTC ---
okay, exact same failure happens with -D_POSIX_C_SOURCE=200112L by itself.
Am trying with _XOPEN_SOURCE=600 defined. Thus far ( well past 70 secs ) the
stage 1 phase seems to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293
--- Comment #4 from Dennis Clarke 2012-11-12
22:10:01 UTC ---
bootstrap fails in 71 seconds :
$ mkdir gcc-4.7.2_sparc64-sun-solaris2.10
$ cd gcc-4.7.2_sparc64-sun-solaris2.10
$ env | sort > ../gcc-4.7.2_sparc64-sun-solaris2.10.env
$ l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293
--- Comment #3 from Dennis Clarke 2012-11-12
22:07:29 UTC ---
OKay, I am extracting a fresh gcc 4.7.2 tarball and then running a new
bootstrap with the defines suggested. Results should appear in seven hours or
so, however I am hoping for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293
Bug #: 55293
Summary: Attempt to bootstrap 7.7.2 on Solaris 10 Sparc fails
with gcc/pretty-print.c:954:28: error: invalid
conversion from 'char**' to 'const char**'
73 matches
Mail list logo
