[Bug c++/111034] New: Precompiled headers still non-deterministic

2023-08-15 Thread skunk at iskunk dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111034

Bug ID: 111034
   Summary: Precompiled headers still non-deterministic
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---

This is a follow-on of bug #92717.

In that bug, it was noted that .gch files are basically GCC memory dumps, and
that because ASLR is typically enabled on modern Linux systems, this results in
non-deterministic output every time such a file is generated.

The solution given was to disable ASLR, e.g. by using "setarch -R". And I
confirmed that if I generate the same .gch file multiple times in a tight loop
with ASLR disabled, every file comes out identical.

That was only a test, however. My production fix was to disable ASLR for the
entire build process, with "setarch -R make bootstrap".

And that yielded much spottier results. After multiple attempts, maybe 10% of
the pairs of bootstraps that I ran came out with identical .gch files. And that
was running on the same container host---if I tried the build in the same
container architecture/environment but a different host, the files would end up
different as a matter of course.

I think, in the interests of reproducibility, the way .gch files are generated
needs to be reworked in a way that does not depend on the runtime environment.
The current approach may be fine for PCH purposes, but the security
implications of any opaque non-determinism will only get worse with time.

[Bug c++/111033] New: libcody build does not use AR_FLAGS

2023-08-15 Thread skunk at iskunk dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111033

Bug ID: 111033
   Summary: libcody build does not use AR_FLAGS
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---

I am working on getting a reproducible GCC build. This includes passing the "D"
option to ar(1) to avoid non-deterministic static library outputs.

In bootstrapping 13.2.0, I noticed that libcody.a was not being generated
consistently. The libcody makefile has the following:

AR := @AR@

...

$(AR) -cr $@ $^

For comparison, in the rest of the GCC tree, you typically see

AR = @AR@
AR_FLAGS = rc

...

$(AR) $(AR_FLAGS) libfoo.a ...

and AR_FLAGS is the natural place to add additional flags. An AR_FLAGS variable
should thus likewise be added to the libcody makefile.

(ARFLAGS is also used; I am not entirely sure which form is favored.)

Beyond addressing this small inconsistency, it would be good to see the GCC
build itself check whether ar(1) supports the "D" flag, and add it
automatically if so.

[Bug tree-optimization/106247] GCC12 warning in Eigen: array subscript is partly outside array bounds

2022-08-01 Thread skunk at iskunk dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247

Daniel Richard G.  changed:

   What|Removed |Added

 CC||skunk at iskunk dot org

--- Comment #4 from Daniel Richard G.  ---
I am seeing what may be the same issue in a different context.

This is occurring in a proprietary C source codebase newly being compiled with
12.1.0, and unfortunately the problem goes away if I attempt to cut it down to
a minimal test case. Nevertheless, the actual issue is quite simple, and IMO
clear-cut.

(some names edited to protect the guilty)

In file included from /usr/include/string.h:375,
 from foo.c:7:
In function 'function3',
inlined from 'function2' at foo.c:1206:5,
inlined from 'function1' at foo.c:2840:7:
foo.c:415:3: error: array subscript 'union [1]' is partly outside
array bounds of 'unsigned char[5]' [-Werror=array-bounds]
  415 |   memset(constraints,0,sizeof(char)*NB_CONSTRAINTS);
  |   ^~
foo.c: In function 'function1':
foo.c:380:17: note: at offset 4 into object 'constraints' of size 5
  380 |   unsigned char constraints[NB_CONSTRAINTS];
  | ^~~~
cc1: all warnings being treated as errors


Curiously enough, I only see this issue in an i686 build. I don't get it on
x86-64. (Dropping -march=i686 does not help.)

[Bug libstdc++/106501] New: libstdc++ is built without -fPIC despite --with-pic

2022-08-01 Thread skunk at iskunk dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106501

Bug ID: 106501
   Summary: libstdc++ is built without -fPIC despite --with-pic
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

I bootstrapped GCC 12.1.0 with the following options:

--disable-shared
--disable-nls
--enable-version-specific-runtime-libs
--with-pic
--disable-multilib
--with-arch=opteron
--disable-libsanitizer
--disable-libcc1
--enable-languages=c,c++,lto

Notable is the combination of "--disable-shared --with-pic", with the intention
of having all the GCC support libraries be statically linkable when building
executables, shared libraries, etc.

Once the bootstrap was complete, I used the new GCC to build a current version
of GDB. That build failed with

  CXXLD  libinproctrace.so
/usr/bin/ld:
/opt/sfw/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/libstdc++.a(class_type_info.o):
relocation R_X86_64_32S against `_ZTVN10__cxxabiv117__class_type_infoE' can not
be used when making a shared object; recompile with -fPIC
/opt/sfw/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/libstdc++.a: could not read
symbols: Bad value
collect2: error: ld returned 1 exit status
gmake[2]: *** [Makefile:383: libinproctrace.so] Error 1
gmake[2]: Leaving directory '/tmp/gdb-12.1-build/gdbserver'
gmake[1]: *** [Makefile:11743: all-gdbserver] Error 2
gmake[1]: Leaving directory '/tmp/gdb-12.1-build'
gmake: *** [Makefile:1001: all] Error 2


I checked the build log for GCC. None of the compile lines for
class_type_info.o include the -fPIC option (i.e. "fgrep class_type_info.o
gcc12-build-log.txt | grep -c PIC" yields 0).

The --with-pic option should cause all libraries to be built with -fPIC, even
when they are built as static archives. It is possible that libstdc++ is not
the only library that was built incorrectly; it is only the one I noticed.

Related: bug #66955, bug #67128

[Bug bootstrap/106482] [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors

2022-08-01 Thread skunk at iskunk dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482

--- Comment #2 from Daniel Richard G.  ---
It would be good to have a specific minimum version of GCC in the documented
prerequisites, as the current text ("an existing GCC binary (version 4.8 or
later)", albeit referring to non-bootstrap builds) misses edge cases like this.

[Bug bootstrap/106482] New: [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors

2022-07-30 Thread skunk at iskunk dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482

Bug ID: 106482
   Summary: [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails
with C++ errors
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

I attempted to bootstrap 12.1.0 using GCC 4.8.2. The documented prerequisites
include an "ISO C++11 compiler," so this appears to be a supported arrangement.

GCC 12 was configured with --disable-shared --disable-nls
--enable-version-specific-runtime-libs --with-pic --disable-multilib
--with-arch=opteron --disable-libcc1 --enable-languages=c,c++,lto

The bootstrap failed as shown below. I was able to bootstrap 10.2.0 using the
original compiler, and then bootstrapped 12.1.0 with that intermediary.


tg-g++ -std=c++11  -fno-PIE -c   -g -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/src/gcc-12.1.0/gcc
-I/home/src/gcc-12.1.0/gcc/. -I/home/src/gcc-12.1.0/gcc/../include
-I/home/src/gcc-12.1.0/gcc/../libcpp/include
-I/home/src/gcc-12.1.0/gcc/../libcody -I/home/sfw/arch/linux64/include
-I/home/sfw/arch/linux64/include -I/home/sfw/arch/linux64/include 
-I/home/src/gcc-12.1.0/gcc/../libdecnumber
-I/home/src/gcc-12.1.0/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/src/gcc-12.1.0/gcc/../libbacktrace   -o fwprop.o -MT fwprop.o -MMD -MP
-MF ./.deps/fwprop.TPo /home/src/gcc-12.1.0/gcc/fwprop.cc
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:24:1: error: prototype for
'typename base_splay_tree::node_type
base_splay_tree::get_child(typename Accessors::node_type, unsigned
int)' does not match any in class 'base_splay_tree'
 base_splay_tree::get_child (node_type node, unsigned int index)
 ^
In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:125:20: error: candidate is: static
typename Accessors::node_type base_splay_tree::get_child(typename
Accessors::node_type, unsigned int)
   static node_type get_child (node_type, unsigned int);
^
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:49:1: error: prototype for
'typename base_splay_tree::node_type
base_splay_tree::promote_child(typename Accessors::node_type,
unsigned int)' does not match any in class 'base_splay_tree'
 base_splay_tree::promote_child (node_type node, unsigned int index)
 ^
In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:128:15: error: candidates are:
static void base_splay_tree::promote_child(typename
Accessors::node_type, unsigned int, typename Accessors::node_type)
   static void promote_child (node_type, unsigned int, node_type);
   ^
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:127:20: error:
static typename Accessors::node_type
base_splay_tree::promote_child(typename Accessors::node_type,
unsigned int)
   static node_type promote_child (node_type, unsigned int);
^
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:187:1: error: prototype for
'typename base_splay_tree::node_type
base_splay_tree::splay_limit(typename Accessors::node_type)' does
not match any in class 'base_splay_tree'
 base_splay_tree::splay_limit (node_type start)
 ^
In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:131:20: error: candidate is:
template template static typename
Accessors::node_type base_splay_tree::splay_limit(typename
Accessors::node_type)
   static node_type splay_limit (node_type);
^
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 f

[Bug other/91139] Attempts, fails to rebuild doc/gcc.info in tarball release build

2020-03-06 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91139

--- Comment #4 from Daniel Richard G.  ---
(In reply to Martin Liška from comment #3)
> 
> So is the issue fixed or not?

Not fixed as of 9.2.0, I'm afraid:

[...]
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --split-size=500
--no-split -I . -I ../../gcc--9.2.0/gcc/doc \
-I ../../gcc--9.2.0/gcc/doc/include -o doc/cpp.info
../../gcc--9.2.0/gcc/doc/cpp.texi; \
fi
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --split-size=500
--no-split -I . -I ../../gcc--9.2.0/gcc/doc \
-I ../../gcc--9.2.0/gcc/doc/include -o doc/gcc.info
../../gcc--9.2.0/gcc/doc/gcc.texi; \
fi
../../gcc--9.2.0/gcc/doc//invoke.texi:1783: @include
`/users/cport/tmp/gcc-build/gcc/../../gcc-9.2.0/gcc/../libiberty/at-file.texi':
No such file or directory.
../../gcc--9.2.0/gcc/doc//extend.texi:7097: warning: `.' or `,' must follow
@xref, not `f'.
../../gcc--9.2.0/gcc/doc//extend.texi:8181: warning: `.' or `,' must follow
@xref, not `f'.
makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to
preserve.
Makefile:3228: recipe for target 'doc/gcc.info' failed
gmake[3]: *** [doc/gcc.info] Error 1
gmake[3]: Leaving directory '/home/skunk/tmp/gcc-build/gcc'
Makefile:4661: recipe for target 'all-stage1-gcc' failed
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory '/home/skunk/tmp/gcc-build'
Makefile:22313: recipe for target 'stage1-bubble' failed
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory '/home/skunk/tmp/gcc-build'
Makefile:22649: recipe for target 'bootstrap' failed
gmake: *** [bootstrap] Error 2


(Note the reference to "gcc-9.2.0" when the actual path is "gcc--9.2.0")

[Bug tree-optimization/91555] [9.2 regression] Optimizer bug

2019-08-26 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555

--- Comment #10 from Daniel Richard G.  ---
Okay. I'll accept that the code is dodgy. Thanks for looking into this.

I'll keep in mind -fsanitize=undefined as a way of tracking down these issues
in the future.

[Bug tree-optimization/91555] [9.2 regression] Optimizer bug

2019-08-26 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555

--- Comment #8 from Daniel Richard G.  ---
The most I could tell via strategic printf() calls is that everything appears
to run correctly up until the binary search. I don't think any (unchecked)
overflow is at issue, but it seems I don't have a way of instrumenting the
program to check for that...

[Bug tree-optimization/91555] [9.2 regression] Optimizer bug

2019-08-26 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555

--- Comment #6 from Daniel Richard G.  ---
Unfortunately, this GCC build does not have libsanitizer, as it is on an older
(Linux) system without the necessary system headers.

$ gcc -O2 -fsanitize=undefined gcc9-opt-bug.c -o bug
/usr/bin/ld: cannot find -lubsan
collect2: error: ld returned 1 exit status

(I get a similar error on the Solaris system.)

Are you able to reproduce the -O1/-O2 split in behavior?

[Bug tree-optimization/91555] [9.2 regression] Optimizer bug

2019-08-26 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555

--- Comment #4 from Daniel Richard G.  ---
Yes, that is the case:

$ gcc -O2 gcc9-opt-bug.c -o bug
$ ./bug
WRONG 13
result: t = 18446744073709551615 (wrong)

$ gcc -O2 -fwrapv gcc9-opt-bug.c -o bug
$ ./bug
result: t = 1009489458 (correct)

[Bug tree-optimization/91555] [9.2 regression] Optimizer bug

2019-08-26 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555

Daniel Richard G.  changed:

   What|Removed |Added

  Attachment #46761|0   |1
is obsolete||

--- Comment #2 from Daniel Richard G.  ---
Created attachment 46762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46762&action=edit
Revised version of test program

Hi Andrew,

I revised the test program with the current version of those two functions. The
erroneous behavior w.r.t. optimization is unchanged.

>From what poking around I could do, the problem appears to occur in the binary
search in time2sub(), which is why making the lo/hi variables volatile appears
to straighten things out.

[Bug tree-optimization/91555] New: [9.2 regression] Optimizer bug

2019-08-26 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555

Bug ID: 91555
   Summary: [9.2 regression] Optimizer bug
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---

Created attachment 46761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46761&action=edit
Quasi-minimal test program

I have encountered what appears to be a bug in the optimizer of GCC 9.2.0. (I
am unclear as to whether it is the tree optimizer or RTL optimizer that is at
issue; please recategorize as appropriate.)

The problem occurs inside some timezone-handling code that is part of a larger
project. I have extracted the code into a program that may not be a minimal
test case, but nevertheless exhibits the problem.

This incorrect optimization has been observed in x86-64 builds on both Linux
and Solaris.

Correct result:

$ gcc -O1 gcc9-opt-bug.c -o bug
$ ./bug
result: t = 1009489458 (correct)

Wrong result:

$ gcc -O2 gcc9-opt-bug.c -o bug
$ ./bug
WRONG 13
result: t = 18446744073709551615

Workaround using "volatile" keyword:

$ gcc -O2 -DUSE_VOLATILE gcc9-opt-bug.c -o bug
$ ./bug
result: t = 1009489458 (correct)

This code was correctly optimized by GCC 4.8.1, so this appears to be a
regression.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

2019-08-21 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725

Daniel Richard G.  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Daniel Richard G.  ---
I have attempted a bootstrap of 9.2.0 on this same system again, and am happy
to report that it now completes successfully, modulo bug #55930. Specifically,

* The libgcc-unwind.map error no longer occurs, despite my use of
--disable-shared;

* The object diffs no longer arise, even though I am continuing to use
/usr/ccs/bin/as and /usr/ccs/bin/ld .

These issues appear to have been fixed by-the-by since this bug was originally
filed, so I am closing accordingly.

[Bug other/91139] Attempts, fails to rebuild doc/gcc.info in tarball release build

2019-07-11 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91139

--- Comment #2 from Daniel Richard G.  ---
(In reply to Richard Biener from comment #1)
> Maybe your NFS servers time is different from the local build ones so make
> gets confused as to what is new?  That said, I've never seen Bug-1 but I also
> do not build with source on NFS.

For confirmation, I attempted a bootstrap with the source tree on local disk.
It appears that doc/gcc.info continues to be regenerated in the same manner.

(If NFS timestamp shenanigans were at issue, I'd have expected to see much more
widespread breakage)

[Bug other/91139] New: Attempts, fails to rebuild doc/gcc.info in tarball release build

2019-07-10 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91139

Bug ID: 91139
   Summary: Attempts, fails to rebuild doc/gcc.info in tarball
release build
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---

There may be one or two bugs in this report.

I am bootstrapping from a release tarball on a Solaris system. The system has
makeinfo 4.7 installed, which the GCC configure script finds.

At a certain point in the build, I get this error:

[...]
(echo "@set version-GCC 9.1.0"; \
 if [ "" = "experimental" ]; \
 then echo "@set DEVELOPMENT"; \
 else echo "@clear DEVELOPMENT"; \
 fi) > gcc-vers.texiT
echo @set srcdir /nfs/gnu/src/gcc/gcc--9.1.0/gcc >> gcc-vers.texiT
if [ -n "(GCC) " ]; then \
  echo "@set VERSION_PACKAGE (GCC) " >> gcc-vers.texiT; \
fi
echo "@set BUGURL @uref{https://gcc.gnu.org/bugs/}"; >> gcc-vers.texiT; \
mv -f gcc-vers.texiT gcc-vers.texi
if [ xinfo = xinfo ]; then \
/nfs/gnu/src/gcc/gcc--9.1.0/missing makeinfo --split-size=500
--split-size=500 --split-size=500 --no-split -I . -I
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc \
-I /nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/include -o doc/cpp.info
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/cpp.texi; \
fi
if [ xinfo = xinfo ]; then \
/nfs/gnu/src/gcc/gcc--9.1.0/missing makeinfo --split-size=500
--split-size=500 --split-size=500 --no-split -I . -I
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc \
-I /nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/include -o doc/gcc.info
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/gcc.texi; \
fi
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc//invoke.texi:1783: @include
`/nfs/gnu/src/gcc/gcc-9.1.0/gcc/../libiberty/at-file.texi': No such file or
directory.
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc//extend.texi:7097: warning: `.' or `,' must
follow @xref, not `f'.
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc//extend.texi:8181: warning: `.' or `,' must
follow @xref, not `f'.
makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to
preserve.
Makefile:3228: recipe for target 'doc/gcc.info' failed
gmake[3]: *** [doc/gcc.info] Error 1
gmake[3]: Leaving directory '/tmp/gcc--9.1.0.build/gcc'
Makefile:4661: recipe for target 'all-stage1-gcc' failed
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory '/tmp/gcc--9.1.0.build'
Makefile:22313: recipe for target 'stage1-bubble' failed
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory '/tmp/gcc--9.1.0.build'
Makefile:22660: recipe for target 'bootstrap-lean' failed
gmake: *** [bootstrap-lean] Error 2

Bug-1 is that the build is attempting to rebuild an info file, which should not
even be happening in the first place with an unmodified release tarball.

Bug-2 is the "No such file" error, which appears to be due to Texinfo syntax
processing erroneously being applied to the file path (note how "gcc--9.1.0"
becomes "gcc-9.1.0", despite only the former being valid for this build).

The second bug would be moot if not for the first.

[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified

2019-07-09 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638

--- Comment #12 from Daniel Richard G.  ---
This issue appears to persist in 9.1.0, where it prevents bootstrap from
completing:

[...]
libtool: link:  /tmp/gcc-9.1.0.build/./gcc/xg++ -B/tmp/gcc-9.1.0.build/./gcc/
-nostdinc++ -nostdinc++
-I/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/src/gcc/gcc-9.1.0/libstdc++-v3/libsupc++
-I/home/src/gcc/gcc-9.1.0/libstdc++-v3/include/backward
-I/home/src/gcc/gcc-9.1.0/libstdc++-v3/testsuite/util
-L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/opt/gnu/x86_64-pc-linux-gnu/bin/ -B/opt/gnu/x86_64-pc-linux-gnu/lib/
-isystem /opt/gnu/x86_64-pc-linux-gnu/include -isystem
/opt/gnu/x86_64-pc-linux-gnu/sys-include   -fchecking=1  -fPIC -DPIC -shared
-nostdlib /usr/lib/../lib64/crti.o /tmp/gcc-9.1.0.build/./gcc/crtbeginS.o 
.libs/findcomp.o .libs/libcc1.o .libs/libcp1.o .libs/names.o .libs/callbacks.o
.libs/connection.o .libs/marshall.o  
-L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-L/tmp/gcc-9.1.0.build/./gcc -L/lib/../lib64 -L/usr/lib/../lib64
/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a -lm
-lc -lgcc /tmp/gcc-9.1.0.build/./gcc/crtendS.o /usr/lib/../lib64/crtn.o 
-static-libstdc++ -static-libgcc ../libiberty/pic/libiberty.a   -Wl,-soname
-Wl,libcc1.so.0 -Wl,-retain-symbols-file
-Wl,/home/src/gcc/gcc-9.1.0/libcc1/libcc1.sym -o .libs/libcc1.so.0.0.0
/usr/bin/ld:
/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(class_type_info.o):
relocation R_X86_64_32S against `_ZTVN10__cxxabiv117__class_type_infoE' can not
be used when making a shared object; recompile with -fPIC
/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a:
could not read symbols: Bad value
collect2: error: ld returned 1 exit status
gmake[3]: *** [libcc1.la] Error 1
gmake[3]: Leaving directory `/tmp/gcc-9.1.0.build/libcc1'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/tmp/gcc-9.1.0.build/libcc1'
gmake[1]: *** [all-libcc1] Error 2
gmake[1]: Leaving directory `/tmp/gcc-9.1.0.build'
gmake: *** [bootstrap-lean] Error 2

(This tree was configured with --disable-shared
--enable-version-specific-runtime-libs --with-pic)

I have confirmed that Alec's workaround (in comment #11) still does the trick.

[Bug other/55930] [7/8/9/10 Regression] libatomic build failure if configured with --disable-dependency-tracking

2019-07-09 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930

Daniel Richard G.  changed:

   What|Removed |Added

 CC||skunk at iskunk dot org

--- Comment #10 from Daniel Richard G.  ---
Confirmed that this issue persists in 9.1.0:

libtool: compile:  /tmp/gcc-9.1.0.build/./gcc/xgcc
-B/tmp/gcc-9.1.0.build/./gcc/ -B/opt/gnu/x86_64-pc-linux-gnu/bin/
-B/opt/gnu/x86_64-pc-linux-gnu/lib/ -isystem
/opt/gnu/x86_64-pc-linux-gnu/include -isystem
/opt/gnu/x86_64-pc-linux-gnu/sys-include -fchecking=1 -DHAVE_CONFIG_H
-I/home/src/gcc/gcc-9.1.0/libatomic/config/x86
-I/home/src/gcc/gcc-9.1.0/libatomic/config/posix
-I/home/src/gcc/gcc-9.1.0/libatomic -I. -Wall -Werror -pthread -g -O2 -MT
load_1_.lo -MD -MP -MF .deps/load_1_.lo.Ppo -DN=1 -c
/home/src/gcc/gcc-9.1.0/libatomic/load_n.c  -fPIC -DPIC -o load_1_.o
/home/src/gcc/gcc-9.1.0/libatomic/load_n.c:115:1: fatal error: opening
dependency file .deps/load_1_.lo.Ppo: No such file or directory
  115 | EXPORT_ALIAS (SIZE(load));
  | ^~~~
compilation terminated.
gmake[4]: *** [load_1_.lo] Error 1
gmake[4]: Leaving directory
`/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libatomic'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libatomic'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libatomic'
gmake[1]: *** [all-target-libatomic] Error 2
gmake[1]: Leaving directory `/tmp/gcc-9.1.0.build'
gmake: *** [bootstrap-lean] Error 2

I'd like to echo Mr. Purdie's "We pass this option in globally to anything
using automake" as the approach my site uses as well.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

2018-12-12 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725

--- Comment #10 from Daniel Richard G.  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> 
> it would be helpful to know a bit more about that system: Solaris 10
> update release (e.g. from /etc/release), versions of as (as -V) and ld
> (ld -V), bootstrap compiler used, version of cmp (and do_compare setting
> in the toplevel Makefile).

Gladly:

$ cat /etc/release 
Oracle Solaris 10 8/11 s10x_u10wos_17b X86
  Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.
Assembled 23 August 2011

$ as -V
as: SunOS 5.10 119961-13 Patch 08/06/2014
[...]

$ ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1505

I am bootstrapping with an earlier build of GCC 7.3.0 (itself compiled via a
non-bootstrapped build, due to this issue).

cmp(1) has no version option; it is simply /usr/bin/cmp:

$ cmp
usage: cmp [-l] [-s] file1 file2 [skip1] [skip2]

$ grep 'do-compare.*=' Makefile
do-compare = cmp $$f1 $$f2 16 16
do-compare3 = $(do-compare)

> To investigate comparison failures, it's usually necessary to have both
> a few of the object pairs failing the comparison and the corresponding
> .s files from -save-temps.  You've to be very careful to rerun the exact
> compiler invocations from exactly the same directories which can be
> tricky due to all the shuffling around due to the different stages.

Is it feasible to re-run the bootstrap with something like
CFLAGS(_FOR_(BUILD|TARGET)) = "-save-temps" ? Recreating the compiler
invocations manually will be quite tricky.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

2018-12-11 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725

--- Comment #8 from Daniel Richard G.  ---
Hello Rainer,

(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> That bootstrap (amd64-pc-solaris2.10 with as/ld, --disable-shared
> --with-pic) has now completed as well: in addition to libcc1 (PR
> other/66955) and ada (cf. PR ada/88429), I also had to disable go
> because it uses sendfile without explicitly linking with -lsendfile (in
> the shared case, this works because libgo is linked with libsendfile).
> 
> Anyway, the bootstrap has now finished successfully and make check is
> running: no comparison failures at all.  So unless there's additional
> information how to reproduce this, I'll close the PR as WORKSFORME.

I tested this again with GCC 8.2.0 on the same system, using as/ld, and am
still seeing the object diffs. Would it help if I provided a copy of the
objects at issue?

[Bug bootstrap/66955] New: Bootstrap error: libcc1 compiled as shared library despite --disable-shared

2015-07-20 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66955

Bug ID: 66955
   Summary: Bootstrap error: libcc1 compiled as shared library
despite --disable-shared
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

Bootstrapping 5.2.0 with

--disable-shared
--enable-languages=c,c++
--disable-multilib

results in

[...]
libtool: compile:  /tmp/gcc-build/./gcc/xg++ -B/tmp/gcc-build/./gcc/
-nostdinc++ -nostdinc++
-I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/src/gcc-5.2.0/libstdc++-v3/libsupc++
-I/home/src/gcc-5.2.0/libstdc++-v3/include/backward
-I/home/src/gcc-5.2.0/libstdc++-v3/testsuite/util
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I/home/src/gcc-5.2.0/libcc1 -I /home/src/gcc-5.2.0/libcc1/../include -I
/home/src/gcc-5.2.0/libcc1/../libgcc -I ../gcc
-I/home/src/gcc-5.2.0/libcc1/../gcc -I /home/src/gcc-5.2.0/libcc1/../gcc/c -I
/home/src/gcc-5.2.0/libcc1/../gcc/c-family -I
/home/src/gcc-5.2.0/libcc1/../libcpp/include -I/usr/local/include
-I/usr/local/include -I/usr/local/include -W -Wall -fvisibility=hidden -g -O2
-D_GNU_SOURCE -MT marshall.lo -MD -MP -MF .deps/marshall.Tpo -c
/home/src/gcc-5.2.0/libcc1/marshall.cc  -fPIC -DPIC -o .libs/marshall.o
mv -f .deps/marshall.Tpo .deps/marshall.Plo
/bin/sh ./libtool --tag=CXX   --mode=link /tmp/gcc-build/./gcc/xg++
-B/tmp/gcc-build/./gcc/ -nostdinc++ `if test -f
/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags;
then /bin/sh
/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags
--build-includes; else echo -funconfigured-libstdc++-v3 ; fi`
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-W -Wall 
-fvisibility=hidden -g -O2 -D_GNU_SOURCE -module -export-symbols
/home/src/gcc-5.2.0/libcc1/libcc1.sym  -Xcompiler '-static-libstdc++'
-Xcompiler '-static-libgcc' -o libcc1.la -rpath /usr/local/lib/../lib64
findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo marshall.lo 
-Wc,../libiberty/pic/libiberty.a 
libtool: link:  /tmp/gcc-build/./gcc/xg++ -B/tmp/gcc-build/./gcc/ -nostdinc++
-nostdinc++
-I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/src/gcc-5.2.0/libstdc++-v3/libsupc++
-I/home/src/gcc-5.2.0/libstdc++-v3/include/backward
-I/home/src/gcc-5.2.0/libstdc++-v3/testsuite/util
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -fPIC -DPIC -shared
-nostdlib /usr/lib/../lib64/crti.o /tmp/gcc-build/./gcc/crtbeginS.o 
.libs/findcomp.o .libs/libcc1.o .libs/names.o .libs/callbacks.o
.libs/connection.o .libs/marshall.o  
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-L/tmp/gcc-build/./gcc -L/lib/../lib64 -L/usr/lib/../lib64
/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a -lm
-lc -lgcc /tmp/gcc-build/./gcc/crtendS.o /usr/lib/../lib64/crtn.o 
-static-libstdc++ -static-lib

[Bug bootstrap/66947] New: Bootstrap error: Extraneous text after `else' directive

2015-07-20 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66947

Bug ID: 66947
   Summary: Bootstrap error: Extraneous text after `else'
directive
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

Bootstrapping 5.2.0 on a 64-bit Linux system:

[...]
config.status: linking /home/src/gcc-5.2.0/libgcc/config/i386/sfp-machine.h to
sfp-machine.h
config.status: linking /home/src/gcc-5.2.0/libgcc/gthr-posix.h to
gthr-default.h
config.status: executing default commands
gmake[3]: Entering directory `/tmp/gcc-build/x86_64-unknown-linux-gnu/libgcc'
/home/src/gcc-5.2.0/libgcc/config/t-softfp:106: Extraneous text after `else'
directive
/home/src/gcc-5.2.0/libgcc/config/t-softfp:113: *** only one `else' per
conditional.  Stop.
gmake[3]: Leaving directory `/tmp/gcc-build/x86_64-unknown-linux-gnu/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


$ gmake --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.


I think the "else ifneq ..." construct in the t-softfp file requires a newer
version of GNU Make. (The GCC "Prerequisites" page indicates that version 3.80
is sufficient.)


[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression

2015-04-07 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644

--- Comment #9 from Daniel Richard G.  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> 
> Looking closer, you are *not* using the Solaris assembler (/usr/ccs/bin/as):

Good call, Rainer. GCC is in fact using /usr/sfw/bin/gas, which identifies as

$ /usr/sfw/bin/gas --version
GNU assembler 2.15
Copyright 2002 Free Software Foundation, Inc.

I am bootstrapping again with explicit use of the Solaris assembler to confirm
that everything works that way, but am running into stage2 != stage3 errors and
am currently sorting those out.


[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression

2015-04-06 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644

Daniel Richard G.  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #7 from Daniel Richard G.  ---
Reopening due to lack of resolution.

If system patches should resolve the issue, then I am open to trying any that
are appropriate; if they work, then they can be noted in the documentation. But
it is also possible that this is a limitation of this particular version of
Solaris that cannot be patched, and thus will need a workaround in GCC.


[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression

2015-04-02 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644

--- Comment #6 from Daniel Richard G.  ---
My admin installed 119961-13, which is the current version of 119961-11:

$ /usr/ccs/bin/as -V
as: SunOS 5.10 119961-13 Patch 08/06/2014
 Usage: as [-a32] [-m] [-m32] [-m64] [-n]
[...]

I'm still getting the same assembler error.


[Bug target/65644] New: Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression

2015-03-31 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644

Bug ID: 65644
   Summary: Assembler errors on Solaris 10 x86-64: `(%eXX)' is not
a valid 64 bit base/index expression
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Host: x86_64-pc-solaris2.10
Target: x86_64-pc-solaris2.10
 Build: x86_64-pc-solaris2.10

Created attachment 35197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35197&action=edit
test case

I built GCC 4.9.2 on a Solaris 10 system on x86-64, and then compiled a C
codebase that does some 64-bit-unsafe things (notably, assuming that pointers
are 32 bits, by casting unsigned ints to pointers). This resulted in "cast to
pointer from integer of different size" warnings as well as errors of the form

{standard input}: Assembler messages:
{standard input}:233: Error: `(%esi)' is not a valid 64 bit base/index
expression
{standard input}:250: Error: `(%edx)' is not a valid 64 bit base/index
expression
{standard input}:1150: Error: `(%edx)' is not a valid 64 bit base/index
expression

I have prepared a small test case that exhibits this same failure mode:

$ gcc -m64 -O -c gcc-asm-bug.c
gcc-asm-bug.c: In function 'foo1':
gcc-asm-bug.c:14:4: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
   ((struct foo_struct *)xptr)->one = val;
^
gcc-asm-bug.c: In function 'foo2':
gcc-asm-bug.c:19:4: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
   ((struct foo_struct *)xptr)->two = val;
^
/var/tmp//ccI3ovqk.s: Assembler messages:
/var/tmp//ccI3ovqk.s:6: Error: `(%edi)' is not a valid 64 bit base/index
expression

No such error occurs when I compile this source on a Linux system, so this may
have to do with the Solaris assembler.


[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

2015-02-17 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

--- Comment #14 from Daniel Richard G.  ---
(In reply to David Edelsohn from comment #13)
> The GCC build process has requirements, including SVR4/POSIX awk.  GCC works
> on a wide variety of systems, but needs to have a base set of requirements
> and limit accommodation to prevent things from getting out of control. 

I understand that; my point is, escaping a couple of characters falls under the
rubric of "limited accommodation." It would be a different story if I wanted
GCC to build with an awk that, say, doesn't support variables.

> Building and installing Gawk or Nawk or another implementation is not an
> unreasonable burden.

It's less reasonable than a two-line patch.

(Any info on building a dist tarball? I don't have enough space on my AIX 4.3
system to take the entire SVN tree)


[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

2015-02-16 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

--- Comment #12 from Daniel Richard G.  ---
(In reply to David Edelsohn from comment #8)
> Patches are reviewed on gcc-patches mailinglist, not in Bugzilla

Sorry, I'm not properly set up for mailing lists at the moment...

> > * Escape "{" characters to not annoy older awk programs
> 
> Prerequisites for GCC explicitly states that POSIX or SVR4 awk is required,
> so I don't think that this work-around would be accepted.  For example, you
> can install GNU Awk.

POSIX/SVR4 is significant if the system awk is missing major features that
would make the script awkward/impossible to maintain. But a small syntax tweak
like this, so long as it doesn't hurt other awk implementations, is no big
deal. Especially for a script that is run by users who are only compiling the
code, as opposed to developers.

> This already has been changed.
> 
[...]
> 
> The fixincludes changes are the most plausible ones.

As an aside, is there documentation somewhere on how to generate a GCC dist
tarball from SVN? "make dist" doesn't do it, Web searches turn up nothing, and
I'd rather not have to wait a few days for the next snapshot...


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2015-02-06 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #22 from Daniel Richard G.  ---
Still using AIX 4.3 here. The std::ctype error has been particularly
nettlesome, as it's beyond my ken and I can't work around it.


[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

2015-02-06 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009

--- Comment #11 from Daniel Richard G.  ---
Yep, that system's still running. I'll be happy to test any fixes for this
issue.


[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

2014-10-21 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

--- Comment #27 from Daniel Richard G.  ---
Likewise confirmed on the same Woody system from comment #5: 4.9.1 bootstraps
fine, 4.8.3 still has the bug.

(Oddly enough, the first configure run in the 4.9.1 bootstrap has the message
"checking for libsanitizer support... yes")

Given the target milestone, I presume there's going to be a 4.8.4?


[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified

2014-05-22 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638

--- Comment #8 from Daniel Richard G.  ---
(In reply to Jonathan Wakely from comment #7)
> Seems unlikely, but if -static-libgcc -static-libstdc++ gives you a runtime
> dependency on GCC then that should be reported as a bug.

I tried a 4.9.0 build without --disable-shared to jog my memory. The problem
was twofold:

First, GCC can't find its own runtime library when linking programs:

/usr/bin/ld: cannot find -lgcc_s

I can specify -L$(PREFIX)/lib/gcc/x86_64-unknown-linux-gnu/lib64 manually, and
that allows things to link. But then, unless I futz with
ld.so.conf/LD_LIBRARY_PATH, the resulting executable uses the wrong instance of
libgcc/libstdc++:

$ ldd swig 
linux-vdso.so.1 =>  (0x7fff76839000)
libdl.so.2 => /lib64/libdl.so.2 (0x00302ee0)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003039a0)
libm.so.6 => /lib64/libm.so.6 (0x00302e60)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003035a0)
libc.so.6 => /lib64/libc.so.6 (0x00302ea0)
/lib64/ld-linux-x86-64.so.2 (0x00302e20)

(Note: It's probably relevant that I also build GCC with
--enable-version-specific-runtime-libs, to avoid a different way that the
runtimes can get mixed up.)

Not having to specify -static-libblah is a bonus, but these were the real
reasons that I was using --disable-shared. Should I file a new bug for this?


[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified

2014-05-21 Thread skunk at iskunk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638

--- Comment #6 from Daniel Richard G.  ---
(In reply to Jonathan Wakely from comment #4)
> 
> Instead of building GCC with --disable-shared, why not just use
> -static-libstdc++ when linking?

It was a long time ago that I last tried that, so I can't say for sure, but it
was probably that executables were being produced that still had some-or-other
GCC shared-runtime dependency.

(This GCC instance is being used for production builds, so it's
release-engineering considerations uber alles)


[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

2013-10-30 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

--- Comment #10 from Daniel Richard G.  ---
(In reply to Richard Biener from comment #9)
> What's the status of this bug?

Same as I reported in comment #5---I just confirmed with a build of 4.8.2.


[Bug bootstrap/58720] New: FreeBSD 4.8 bootstrap fails due to missing stdint.h

2013-10-13 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58720

Bug ID: 58720
   Summary: FreeBSD 4.8 bootstrap fails due to missing stdint.h
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Host: i686-unknown-freebsd4.8
Target: i686-unknown-freebsd4.8
 Build: i686-unknown-freebsd4.8

After addressing bugs #58274 and #58719, a bootstrap of GCC 4.8.1 on FreeBSD
4.8 fails with

[...]
gmake[5]: Entering directory
`/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include'
mkdir -p ./i686-unknown-freebsd4.8/bits/stdc++.h.gch
/tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++
-L/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/src
-L/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/src/.libs
-B/usr/local/i686-unknown-freebsd4.8/bin/
-B/usr/local/i686-unknown-freebsd4.8/lib/ -isystem
/usr/local/i686-unknown-freebsd4.8/include -isystem
/usr/local/i686-unknown-freebsd4.8/sys-include-x c++-header -nostdinc++ -g
-O2
-I/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include/i686-unknown-freebsd4.8
-I/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include
-I/tmp/gcc-4.8.1/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/tmp/gcc-4.8.1/libstdc++-v3/include/precompiled/stdc++.h \
-o i686-unknown-freebsd4.8/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include/bits/atomic_base.h:37:0,
 from
/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include/atomic:41,
 from
/tmp/gcc-4.8.1/libstdc++-v3/include/precompiled/stdc++.h:99:
/tmp/gcc-build/./gcc/include/stdint.h:9:26: fatal error: stdint.h: No such file
or directory
 # include_next 
  ^
compilation terminated.
gmake[5]: *** [i686-unknown-freebsd4.8/bits/stdc++.h.gch/O2ggnu++0x.gch] Error
1
gmake[5]: Leaving directory
`/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
`/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3'
gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap] Error 2


This system has no /usr/include/stdint.h, so GCC should probably not be looking
for one.


[Bug bootstrap/58719] New: libgcc/enable-execute-stack-mprotect.c: bootstrap failure due to missing #include

2013-10-13 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58719

Bug ID: 58719
   Summary: libgcc/enable-execute-stack-mprotect.c: bootstrap
failure due to missing #include 
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Host: i686-unknown-freebsd4.8
Target: i686-unknown-freebsd4.8
 Build: i686-unknown-freebsd4.8

After patching bug #58274, a bootstrap of GCC 4.8.1 on FreeBSD 4.8 stops with

/tmp/gcc-build/./gcc/xgcc -B/tmp/gcc-build/./gcc/
-B/usr/local/i686-unknown-freebsd4.8/bin/
-B/usr/local/i686-unknown-freebsd4.8/lib/ -isystem
/usr/local/i686-unknown-freebsd4.8/include -isystem
/usr/local/i686-unknown-freebsd4.8/sys-include-g -O2 -O2  -g -O2 -DIN_GCC  
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -fpic -pthread -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -fpic -pthread -I. -I. -I../.././gcc
-I../../../gcc-4.8.1/libgcc -I../../../gcc-4.8.1/libgcc/.
-I../../../gcc-4.8.1/libgcc/../gcc -I../../../gcc-4.8.1/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o enable-execute-stack.o -MT enable-execute-stack.o
-MD -MP -MF enable-execute-stack.dep  -c enable-execute-stack.c
-fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/include/sys/mman.h:135:0,
 from enable-execute-stack.c:25:
/usr/include/sys/mman.h:141:14: error: unknown type name 'mode_t'
 int shm_open __P((const char *, int, mode_t));
  ^
/usr/include/sys/mman.h:144:11: error: unknown type name 'size_t'
 int mlock __P((const void *, size_t));
   ^
/usr/include/sys/mman.h:147:13: error: unknown type name 'size_t'
 void * mmap __P((void *, size_t, int, int, int, off_t));
 ^
/usr/include/sys/mman.h:147:13: error: unknown type name 'off_t'
 void * mmap __P((void *, size_t, int, int, int, off_t));
 ^
/usr/include/sys/mman.h:149:14: error: unknown type name 'size_t'
 int mprotect __P((const void *, size_t, int));
  ^
/usr/include/sys/mman.h:150:11: error: unknown type name 'size_t'
 int msync __P((void *, size_t, int));
   ^
/usr/include/sys/mman.h:151:13: error: unknown type name 'size_t'
 int munlock __P((const void *, size_t));
 ^
/usr/include/sys/mman.h:152:12: error: unknown type name 'size_t'
 int munmap __P((void *, size_t));
^
/usr/include/sys/mman.h:154:13: error: unknown type name 'size_t'
 int madvise __P((void *, size_t, int));
 ^
/usr/include/sys/mman.h:155:13: error: unknown type name 'size_t'
 int mincore __P((const void *, size_t, char *));
 ^
/usr/include/sys/mman.h:156:14: error: unknown type name 'size_t'
 int minherit __P((void *, size_t, int));
  ^
enable-execute-stack.c: In function '__enable_execute_stack':
enable-execute-stack.c:86:7: warning: implicit declaration of function
'mprotect' [-Wimplicit-function-declaration]
   if (mprotect (page, end - page, STACK_PROT_RWX) < 0)
   ^
gmake[3]: *** [enable-execute-stack.o] Error 1
gmake[3]: Leaving directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap] Error 2

$ ls -l /tmp/gcc-build/i686-unknown-freebsd4.8/libgcc/enable-execute-stack.c
lrwxr-xr-x 1 cport r&d 57 Oct 14 02:31
/tmp/gcc-build/i686-unknown-freebsd4.8/libgcc/enable-execute-stack.c ->
../../../gcc-4.8.1/libgcc/enable-execute-stack-mprotect.c


Adding an '#include ' to libgcc/enable-execute-stack-mprotect.c,
right before the sys/mman.h #include, is enough to get the bootstrap going
again.


[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified

2013-10-06 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638

--- Comment #1 from Daniel Richard G.  ---
A workaround for this issue is to build with CFLAGS="-fPIC" CXXFLAGS="-fPIC"
(presuming that one is building with GCC), in addition to --with-pic. This
results in a compiler build that does not fail as reported above.


[Bug libstdc++/58638] New: libstdc++ builds as non-PIC when --with-pic is specified

2013-10-05 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638

Bug ID: 58638
   Summary: libstdc++ builds as non-PIC when --with-pic is
specified
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

I built GCC 4.8.1 with "--disable-shared --with-pic" so that I can statically
link libgcc/libstdc++ into executables, including shared-library builds.
However, when I attempted to build a C++ shared object on Linux/amd64 using the
new compiler, I got this:

libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/../lib64/crti.o
/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbeginS.o
 .libs/Dqa_wrap.o .libs/dqa_func.o [...]
-L/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../..
/opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a -lm -lc -lgcc
/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtendS.o
/usr/lib/../lib64/crtn.o -march=opteron -mno-3dnow -O0   -pthread -Wl,-soname
-Wl,libdqa_swig_interface.so -o .libs/libdqa_swig_interface.so
/usr/bin/ld:
/opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a(eh_throw.o):
relocation R_X86_64_32S against `a local symbol' can not be used when making a
shared object; recompile with -fPIC
/opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a: could not read
symbols: Bad value
collect2: error: ld returned 1 exit status
make[6]: *** [libdqa_swig_interface.la] Error 1


This is a regression from 4.7.x, when --with-pic correctly caused all (static)
runtime libraries to be built with PIC code.


[Bug bootstrap/58274] New: libiberty/stack-limit.c: bootstrap failure due to missing FreeBSD header

2013-08-29 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58274

Bug ID: 58274
   Summary: libiberty/stack-limit.c: bootstrap failure due to
missing FreeBSD header
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Host: i386-unknown-freebsd4.8
Target: i386-unknown-freebsd4.8
 Build: i386-unknown-freebsd4.8

Created attachment 30724
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30724&action=edit
Patch against 4.8.1/SVN

This is basically the same as bug 49817, only this occurs on FreeBSD 4.8, which
doesn't have . (This is clearly a bug in the FreeBSD headers, but
this version of the OS won't be seeing a fix.)

[...]
if [ x"-fpic" != x ]; then \
  tg-gcc -c -DHAVE_CONFIG_H -g  -I. -I/home/src/gcc-4.8.1/libiberty/../include 
-W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic
/home/src/gcc-4.8.1/libiberty/stack-limit.c -o pic/stack-limit.o; \
else true; fi
In file included from /home/src/gcc-4.8.1/libiberty/stack-limit.c:43:
/usr/include/sys/resource.h:58: error: field 'ru_utime' has incomplete type
/usr/include/sys/resource.h:59: error: field 'ru_stime' has incomplete type
/usr/include/sys/resource.h:119: error: expected specifier-qualifier-list
before 'int32_t'
/usr/include/sys/resource.h:124: error: expected specifier-qualifier-list
before 'rlim_t'
/usr/include/sys/resource.h:130: error: expected specifier-qualifier-list
before 'fixpt_t'
/home/src/gcc-4.8.1/libiberty/stack-limit.c: In function
'stack_limit_increase':
/home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: 'struct rlimit' has no
member named 'rlim_cur'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: 'rlim_t' undeclared
(first use in this function)
/home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: (Each undeclared
identifier is reported only once
/home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: for each function it
appears in.)
/home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: 'u_quad_t' undeclared
(first use in this function)
/home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: expected ')' before
numeric constant
/home/src/gcc-4.8.1/libiberty/stack-limit.c:54: error: 'struct rlimit' has no
member named 'rlim_cur'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:55: error: 'struct rlimit' has no
member named 'rlim_max'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:55: error: expected ')' before
numeric constant
/home/src/gcc-4.8.1/libiberty/stack-limit.c:55: error: 'struct rlimit' has no
member named 'rlim_cur'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:55: error: 'struct rlimit' has no
member named 'rlim_max'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:57: error: 'struct rlimit' has no
member named 'rlim_cur'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:58: error: 'struct rlimit' has no
member named 'rlim_max'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:58: error: expected ')' before
numeric constant
/home/src/gcc-4.8.1/libiberty/stack-limit.c:58: error: 'struct rlimit' has no
member named 'rlim_cur'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:58: error: 'struct rlimit' has no
member named 'rlim_max'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:59: error: 'struct rlimit' has no
member named 'rlim_cur'
/home/src/gcc-4.8.1/libiberty/stack-limit.c:59: error: 'struct rlimit' has no
member named 'rlim_max'
gmake[3]: *** [stack-limit.o] Error 1


#Including  fixes the issue. See attached patch.


[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

2013-08-29 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

--- Comment #7 from Daniel Richard G.  ---
Created attachment 30723
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30723&action=edit
Trivial configure-time check

(In reply to Kostya Serebryany from comment #6)
> 
> That would be non-trivial. We intercept the pthread_ functions so we can't 
> call them directly. We'll at least need to bypass our own interceptors. 
> And as I mentioned before, older kernels will likely not work anyway for 
> a few other reasons.

Okay, so I guess there's no alternative but to disable libsanitizer for these
systems.

I see that libsanitizer support is inferred automatically by the
libsanitizer/configure.tgt script, which is sourced from the top-level
configure script. This script is not processed by Autoconf, so doing a
test-compile in there would be somewhat awkward. However, on this old Debian
system, the linux/futex.h header doesn't exist at all, so picking up on that
would be enough for me.

See attached patch for a first-draft proposal. (There probably needs to be some
build/host/target-sysroot awareness of where to look for the header; I'm not
familiar enough with building cross-compilers.)


[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

2013-08-28 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

Daniel Richard G.  changed:

   What|Removed |Added

 CC||skunk at iskunk dot org

--- Comment #5 from Daniel Richard G.  ---
I get this same error building on an old Debian woody system:

/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
function 'void __sanitizer::internal__exit(int)':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:142:11:
error: '__NR_exit_group' was not declared in this scope
   syscall(__NR_exit_group, exitcode);
   ^
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In member
function 'void __sanitizer::BlockingMutex::Lock()':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:529:13:
error: '__NR_futex' was not declared in this scope
 syscall(__NR_futex, m, FUTEX_WAIT, MtxSleeping, 0, 0, 0);
 ^
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In member
function 'void __sanitizer::BlockingMutex::Unlock()':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:537:13:
error: '__NR_futex' was not declared in this scope
 syscall(__NR_futex, m, FUTEX_WAKE, 1, 0, 0, 0);
 ^
gmake[4]: *** [sanitizer_linux.lo] Error 1


Would a fallback implementation of BlockingMutex::{Lock,Unlock}() that uses
pthread_mutex_*() be sensible here?


[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'

2012-09-27 Thread skunk at iskunk dot org


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



--- Comment #10 from Daniel Richard G.  2012-09-27 
14:02:03 UTC ---

Okay, I grabbed a copy of gcc-4.8-20120923, and started bootstrapping using an

older 4.5.2 (since the 4.7.0 C++ compiler isn't working correctly; am I correct

in observing that GCC can no longer be bootstrapped using just a C compiler?).



Things went well up until this point:



tg-g++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings

-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I.

-I. -I/home/src/gcc-4.8-20120923/gcc -I/home/src/gcc-4.8-20120923/gcc/.

-I/home/src/gcc-4.8-20120923/gcc/../include

-I/home/src/gcc-4.8-20120923/gcc/../libcpp/include

-I/tg/freeport/arch/aix32/include -I/tg/freeport/arch/aix32/include

-I/tg/freeport/arch/aix32/include 

-I/home/src/gcc-4.8-20120923/gcc/../libdecnumber

-I/home/src/gcc-4.8-20120923/gcc/../libdecnumber/dpd -I../libdecnumber\

/home/src/gcc-4.8-20120923/gcc/config/rs6000/rs6000.c -o rs6000.o

/home/src/gcc-4.8-20120923/gcc/config/rs6000/rs6000.c: In function 'void

rs6000_code_end()':

/home/src/gcc-4.8-20120923/gcc/config/rs6000/rs6000.c:28292:51: error:

'ASM_WEAKEN_DECL' was not declared in this scope

gmake[3]: *** [rs6000.o] Error 1

gmake[3]: Leaving directory `/tmp/gcc-4.8-test/gcc'

gmake[2]: *** [all-stage1-gcc] Error 2

gmake[2]: Leaving directory `/tmp/gcc-4.8-test'

gmake[1]: *** [stage1-bubble] Error 2

gmake[1]: Leaving directory `/tmp/gcc-4.8-test'

gmake: *** [bootstrap-lean] Error 2





This is one of the issues addressed by my aforementioned patch.


[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'

2012-09-25 Thread skunk at iskunk dot org


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



--- Comment #8 from Daniel Richard G.  2012-09-26 
06:06:11 UTC ---

Sure, can do. Is mainline a synonym for SVN trunk? Is there somewhere I can

download a ready-made tarball, just to make sure everything is autogen'ed

correctly?


[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'

2012-09-25 Thread skunk at iskunk dot org


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



--- Comment #6 from Daniel Richard G.  2012-09-25 
21:38:32 UTC ---

Okay, I'm bootstrapping an unmodified 4.7.2, using a previously-built 4.7.0 as

CC and the following configuration options:



--prefix=/opt/tg

--disable-dependency-tracking

--disable-maintainer-mode

--program-prefix=tg-

--disable-shared

--disable-nls

--enable-languages=c,c++

--enable-version-specific-runtime-libs

--with-pic

--with-mpc=/tg/freeport/arch/aix32

--with-mpfr=/tg/freeport/arch/aix32

--with-gmp=/tg/freeport/arch/aix32

--disable-powercpu



Last time I tried this with 4.7.0/4.7.1, there were numerous problems (none

having to do with bad PPC instructions, since I just used --with-cpu= et al. to

work around that). I actually have patches for most of the issues, and have

previously posted them at



http://gcc.gnu.org/PR53348#c7



but David Edelsohn took no notice of them. If you're interested, I'll be happy

to update the patch for current SVN.



At any rate, I'll let you know how the build goes. This machine isn't exactly a

speed demon, so give it a day or three


[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'

2012-09-25 Thread skunk at iskunk dot org


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



--- Comment #4 from Daniel Richard G.  2012-09-25 
10:56:41 UTC ---

(In reply to comment #3)

> Does this still fail?



I haven't built GCC on the AIX 4.3 (PowerPC 604) system lately, but my scripts

are set up to do so using



--with-cpu=powerpc --disable-aix64 --disable-powercpu



in order to avoid this issue. Should I be able to drop any of these, at this

point?


[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

2012-07-24 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887

--- Comment #21 from Daniel Richard G.  2012-07-25 
03:18:32 UTC ---
(In reply to comment #18)
> Maybe the  code is non-functional, but *something* is referencing the
> symbol under certain circumstances.

I figure this is a question worth answering. Repeating the failed link with
-Wl,-bnoquiet gives some helpful information:

ld: 0711-318 ERROR: Undefined symbols were found.
The following symbols are in error:
 SymbolInpndx  TY CL Source-File(Object-File) OR
Import-File{Shared-object}
  RLD: Address  Section  Rld-type Referencing
Symbol

--
 .std::function::function(std::function const&) [146]  
ER PR
/home/src/gcc-4.7.1/libstdc++-v3/src/c++11/regex.cc(/tmp/gcc-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a[regex.o])
   2918 .textR_RBR[3582] 
.std::__regex::_State::_State(std::__regex::_State const&)
 .std::function::function(std::function const&) [276]  
ER PR
/home/src/gcc-4.7.1/libstdc++-v3/src/c++11/functexcept.cc(/tmp/gcc-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a[functexcept.o])
   3e18 .textR_RBR[4312] 
.std::__regex::_State::_State(std::__regex::_State const&)
 .std::function::function(std::function
const&) [148]   ER PR
/home/src/gcc-4.7.1/libstdc++-v3/src/c++11/regex.cc(/tmp/gcc-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a[regex.o])
   2938 .textR_RBR[3582] 
.std::__regex::_State::_State(std::__regex::_State const&)
 .std::function::function(std::function
const&) [278]   ER PR
/home/src/gcc-4.7.1/libstdc++-v3/src/c++11/functexcept.cc(/tmp/gcc-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a[functexcept.o])
   3e38 .textR_RBR[4312] 
.std::__regex::_State::_State(std::__regex::_State const&)
ER: The return code is 8.
ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&)
ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&)
collect2: error: ld returned 8 exit status


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-07-23 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #21 from Daniel Richard G.  2012-07-23 
18:52:06 UTC ---
(In reply to comment #20)
> You could try adding this to ctype.cc around line 54

--- libstdc++-v3/src/c++98/ctype.cc.orig2012-01-23 18:12:01.2 -0500
+++ libstdc++-v3/src/c++98/ctype.cc2012-07-23 13:31:55.2 -0400
@@ -52,6 +52,8 @@

   const size_t ctype::table_size;

+  inline template class ctype;// added by skunk
+
   ctype::~ctype()
   { 
 _S_destroy_c_locale(_M_c_locale_ctype);


I rebuilt ctype.o and the libraries it goes into. Unfortunately, I still get
the link error. If I compare the output of "nm -A" on the old and new ctype.o
objects, I don't see a difference in the defined symbols.

The mangled form of "vtable for std::ctype" is "_ZTVSt5ctypeIcE". If I
grep for that in "nm -A ctype.o", I see

ctype.o:17c0 d _ZTVSt5ctypeIcE.P8

but no instances without the ".P8" suffix. Looking through all the objects of
libstdc++, grep only turns up these:

ctype_configure_char.o: U _ZTVSt5ctypeIcE
ctype_configure_char.o:08a4 d _ZTVSt5ctypeIcE.P8

For comparison, I grepped for "_ZTVNSt6locale5facetE", the mangled form of
"vtable for std::locale::facet", and got the below:

time_members.o: U _ZTVNSt6locale5facetE
time_members.o:1778 d _ZTVNSt6locale5facetE.P8
codecvt.o: U _ZTVNSt6locale5facetE
codecvt.o:15d0 d _ZTVNSt6locale5facetE.P8
locale-inst.o: U _ZTVNSt6locale5facetE
locale-inst.o:00023974 d _ZTVNSt6locale5facetE.P8
wlocale-inst.o: U _ZTVNSt6locale5facetE
wlocale-inst.o:00023c2c d _ZTVNSt6locale5facetE.P8
numeric_members.o: U _ZTVNSt6locale5facetE
numeric_members.o:0e64 d _ZTVNSt6locale5facetE.P8
ctype.o: U _ZTVNSt6locale5facetE
ctype.o:17bc d _ZTVNSt6locale5facetE.P8
monetary_members.o: U _ZTVNSt6locale5facetE
monetary_members.o:1b80 d _ZTVNSt6locale5facetE.P8
locale_init.o: U _ZTVNSt6locale5facetE
locale_init.o:4a50 d _ZTVNSt6locale5facetE.P8
ctype_configure_char.o: U _ZTVNSt6locale5facetE
ctype_configure_char.o:08a0 d _ZTVNSt6locale5facetE.P8
locale.o:2b08 d _ZTVNSt6locale5facetE
locale.o:2b08 D _ZTVNSt6locale5facetE
locale.o:2b3c d _ZTVNSt6locale5facetE.P8


The fact of the symbol being a vtable for a template class appears to be
relevant. Maybe a different kind of explicit instantiation is needed?


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-07-22 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #19 from Daniel Richard G.  2012-07-23 
04:20:33 UTC ---
The good news: The build gets past all of the pthreads-related errors described
here, so I think those two changes may be a workable solution.

The bad news: I'll still running up against this error:

/tmp/gcc-build/./prev-gcc/g++ -B/tmp/gcc-build/./prev-gcc/
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -nostdinc++
-B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs
-I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/tg/freeport/src/gcc/gcc--4.7.1-tera/libstdc++-v3/libsupc++
-L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs   -g
-O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1
c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
default-c.o rs6000-c.o \
  cc1-checksum.o main.o  libbackend.a libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   
-L/tg/freeport/arch/aix32/lib -L/tg/freeport/arch/aix32/lib
-L/tg/freeport/arch/aix32/lib -lmpc -lmpfr -lgmp   -L../zlib -lz
ld: 0711-317 ERROR: Undefined symbol: vtable for std::ctype
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
gmake[3]: *** [cc1] Error 1
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


I really need help with this error---this seems to be along the lines of the
PatternCursor issue we saw the other day, only this one is more confusing. What
do you think is going on here?

(FWIW, the objects that want the missing symbol are the various instances of
ctype_configure_char.o, which appears to be built from
libstdc++-v3/config/os/aix/ctype_configure_char.cc. I *think* the std::ctype
template/class is defined in libstdc++-v3/include/bits/locale_facets.h.)


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-07-20 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #18 from Daniel Richard G.  2012-07-20 
17:44:12 UTC ---
(In reply to comment #17)
> Between comment 5 (with missing ;;) and comment 14 it should work, I think.

Okay, I'm re-starting the build with those two changes (plus my omnibus patch)
applied to 4.7.1. Let's see where that goes over the weekend...


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-07-19 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #16 from Daniel Richard G.  2012-07-19 
21:10:28 UTC ---
Okay, spoke too soon; I encountered the same error later in the game, when
building the "pthread" variant of libstdc++-v3.

I'm going to try the build with a new patch, revisiting the code snippet in
comment #2:

--- libstdc++-v3/acinclude.m4(revision 189681)
+++ libstdc++-v3/acinclude.m4(working copy)
@@ -3282,13 +3282,18 @@

   AC_MSG_CHECKING([whether it can be safely assumed that mutex_timedlock is
available])

-  AC_TRY_COMPILE([#include ],
+  AC_TRY_COMPILE(
+[
+  #include 
+  #include 
+],
 [
   // In case of POSIX threads check _POSIX_TIMEOUTS.
   #if (defined(_PTHREADS) \
   && (!defined(_POSIX_TIMEOUTS) || _POSIX_TIMEOUTS <= 0))
   #error
   #endif
+  return pthread_mutex_timedlock(NULL, NULL)
 ], [ac_gthread_use_mutex_timedlock=1], [ac_gthread_use_mutex_timedlock=0])

   AC_DEFINE_UNQUOTED(_GTHREAD_USE_MUTEX_TIMEDLOCK,
$ac_gthread_use_mutex_timedlock,


Since the code is being compiled as C++, linking is not necessary to get an
error in case the function is missing. Will this work any better as a solution
than my suggestion in comment #4? (Might an "#ifndef WIN32" in there be
helpful?)


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-07-19 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #15 from Daniel Richard G.  2012-07-19 
19:24:37 UTC ---
(In reply to comment #14)
> I still don't think it's the right thing to do, but does this help?

I'm trying this now, in conjunction with the patch posted at

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348#c7

So far, your change seems to address the O2ggnu++0x.gch error in the original
report above, as I encountered that before actually making the change.

(Bootstrap time on this system is measured in days, and I'll probably need to
do a second go-around, so let me get back to you...)


[Bug spam/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

2012-07-17 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009

Daniel Richard G.  changed:

   What|Removed |Added

  Component|target  |spam

--- Comment #9 from Daniel Richard G.  2012-07-17 
23:32:04 UTC ---
I've posted a more elaborated patch for this (and other AIX 4.3 issues) to bug
#53348.


[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

2012-07-17 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

--- Comment #7 from Daniel Richard G.  2012-07-17 
23:24:13 UTC ---
Created attachment 27821
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27821
Patch against GCC SVN trunk

Hi David,

The attached patch is everything I've got so far to address issues in building
GCC on AIX 4.3. This covers issues beyond this bug report, but I figured you'd
rather take care of everything in one go. A walk-through of the changes:

++ gcc/opt-functions.awk

* Escape "{" characters to not annoy older awk programs

++ gcc/config/rs6000/rs6000.c

* legitimate_indirect_address_p() was coming up as undefined when declared with
the "inline" keyword

* ASM_WEAKEN_DECL() was coming up undefined, too, even though the call is in a
section of code not actually used on this platform

++ fixincludes/tests/base/*.h

* Updates to the test suite

++ fixincludes/inclhack.def

* Fixinclude for the oddly-sized fast-integer types

* Fixinclude for the broken PRIxNN macros in inttypes.h

* Fixinclude for an incomplete PTHREAD_ONCE_INIT (breaks -Werror builds)

* Tweaked the aix_pthread hack, as pthread.h has a tab character immediately
after the "#define" on my system

* Fixinclude for an strtof() declaration lacking a const keyword (bug #48009)


Please let me know what you think.


[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

2012-06-19 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887

--- Comment #15 from Daniel Richard G.  2012-06-20 
04:10:28 UTC ---
David, thank you for commenting; I have a better appreciation now of how AIX is
a different animal from most, and indeed may be doing things more correctly
than other systems on this one point.

I'd also like to bring attention to a seemingly similar issue I've encountered
when bootstrapping on AIX 4.3:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238#c11

That one is less straightforward, however, because (as reported a couple
comments further down) it only occurs when bootstrapping. If I build GCC with a
C-only GCC of the same version and --disable-bootstrap, there's no error.


[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

2012-06-18 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887

--- Comment #12 from Daniel Richard G.  2012-06-18 
16:56:42 UTC ---
(In reply to comment #11)
> We know the instantiations that are needed, but I don't want to define them 
> for
> all platforms if they're not needed elsewhere. I also have no way of testing 
> on
> AIX, so someone needs to run the teststuite with the changes.

I can do the testing, but is this really the solution? Why would AIX (and not
even all versions of AIX) need these instantiations, how is it doing things
differently from other systems?

This is fine as a workaround, but I'm presuming the real fix is to get GCC on
AIX working again the same way as it does elsewhere.


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-06-10 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #13 from Daniel Richard G.  2012-06-10 
22:39:36 UTC ---
Hi Jonathan,

I've checked and double-checked this, and was hoping you could offer some
insight:

I get the "Undefined symbol: vtable for std::ctype" error only when
bootstrapping. If I build 4.7.0 with a previously-built C-only 4.7.0 +
--disable-bootstrap, everything else the same, the build completes
successfully.

Can you make anything of that?


[Bug bootstrap/53607] New: opt-functions.awk --> "awk: There is a regular expression error."

2012-06-07 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53607

 Bug #: 53607
   Summary: opt-functions.awk --> "awk: There is a regular
expression error."
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: hppa2.0w-hp-hpux11.00
Target: hppa2.0w-hp-hpux11.00
 Build: hppa2.0w-hp-hpux11.00


Created attachment 27583
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27583
Proposed fix

Bootstrapping 4.7.0 on an HP-UX 11.00 system fails with

[...]
echo timestamp > s-options
awk -f /home/src/gcc-4.7.0/gcc/opt-functions.awk -f /tg/freepor
t/src/gcc/gcc--4.7.0-tera/gcc/opt-read.awk \
   -f /home/src/gcc-4.7.0/gcc/opth-gen.awk \
   < optionlist > tmp-options.h
awk: There is a regular expression error.
?, *, or + not preceded by valid regular expression
 The source line number is 90.
 The error context is
if (flags ~ >>>  "^{") <<< 
gmake[3]: *** [s-options-h] Error 2
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


The fix for this is fairly trivial; patch against SVN is attached.


[Bug bootstrap/52850] Linker path ends up using wrong zlib

2012-06-07 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52850

--- Comment #3 from Daniel Richard G.  2012-06-07 
21:59:39 UTC ---
Created attachment 27582
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27582
Proposed fix

Since the in-tree zlib is always built as a static archive, we can link it in
with an explicit path rather than -lz (and still use the latter when using the
system zlib). How does this look?


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-05-15 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #11 from Daniel Richard G.  2012-05-16 
02:51:24 UTC ---
Okay, the bootstrap gets further this time. A couple of unrelated issues came
up which I was able to work around, but then I encountered this:

[...]
/tmp/gcc-build/./prev-gcc/g++ -B/tmp/gcc-build/./prev-gcc/
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -nostdinc++
-B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs
-I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++
-L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs   -g
-O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1
c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
default-c.o rs6000-c.o \
  cc1-checksum.o main.o  libbackend.a libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   
-L/tg/freeport/arch/aix32/lib -L/tg/freeport/arch/aix32/lib
-L/tg/freeport/arch/aix32/lib -lmpc -lmpfr -lgmp   -L../zlib -lz
ld: 0711-317 ERROR: Undefined symbol: vtable for std::ctype
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
gmake[3]: *** [cc1] Error 1
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


If I add -Wl,-bnoquiet to that, I get

[...]
ld: 0711-318 ERROR: Undefined symbols were found.
The following symbols are in error:
 SymbolInpndx  TY CL Source-File(Object-File) OR
Import-File{Shared-object}
  RLD: Address  Section  Rld-type Referencing
Symbol

--
 vtable for std::ctype [16]ER PR
ctype_configure_char.cc(/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs/libstdc++.a[ctype_configure_char.o])
   08a4 .dataR_POS[775]  
<_ZTVSt5ctypeIcE.P8>
ER: The return code is 8.
ld: 0711-317 ERROR: Undefined symbol: vtable for std::ctype
collect2: error: ld returned 8 exit status


Seems like another issue in the vein of bug 52887. I can't make heads or tails
of C++ at this level; would another instantiation do the trick here?


[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

2012-05-15 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

--- Comment #6 from Daniel Richard G.  2012-05-15 
19:01:45 UTC ---
My first thought had been to put in AIX-version-dependent cpp conditionals in
aix-stdint.h, but admittedly, that would have been an ugly way to go.

I have an AIX 5.3 system here as well. There is no sys/inttypes.h, but
[u]int_fastNN_t is defined in sys/stdint.h, and all the types are the same size
as [u]intNN_t. This is presumably the case for newer AIXes as well.

Fixincluding sys/inttypes.h should be safe IMO, and any bad fallout from that
should be limited to AIX releases that still have this header, and use the
unequal-sized-types, and somehow depend on those types. I'll double-check that
this isn't the case for 4.3.


[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

2012-05-15 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

--- Comment #4 from Daniel Richard G.  2012-05-15 
17:35:20 UTC ---
(In reply to comment #3)
> AIX 4.3.2 was announced in 1998 and end of service in 2003. The AIX header is
> wrong and was fixed in later versions. You have a work-around. I am not aware
> of anyone else trying to use recent versions of GCC on ancient versions of 
> AIX.
> Customers who continue to use an old version generally freeze all software on
> the system. Patches are welcome.

So if I understand correctly: GCC may still nominally support AIX 4.3, but no
one here really wants to spend time dealing with it.

If that's the case, could you set these PRs to WAITING/IN_PROGRESS, and assign
them to me? I'll gladly try my hand at some patches, as long as someone here is
willing to review them and get them in if they're good.

I was under the impression that fast-integer types could be N bits or more in
size, so e.g. "typedef int32_t int_fast16_t" would be valid (and may make sense
for the architecture). So you're saying that's not it, and sys/inttypes.h needs
fixincluding?


[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

2012-05-14 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

--- Comment #2 from Daniel Richard G.  2012-05-14 
22:54:02 UTC ---
*** Bug 47902 has been marked as a duplicate of this bug. ***


[Bug bootstrap/47902] Bootstrap failure: libiberty/regex.c: error: two or more data types in declaration specifiers

2012-05-14 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47902

Daniel Richard G.  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from Daniel Richard G.  2012-05-14 
22:54:02 UTC ---
This bug appears to be a duplicate of bug 53348.

(The linked bug report is newer, but represents a clearer diagnosis of the
problem, and is filed against version 4.7.0.)

*** This bug has been marked as a duplicate of bug 53348 ***


[Bug bootstrap/47907] Bootstrap failure: libiberty/hashtab.c: error: conflicting types for 'int_fast16_t'

2012-05-14 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47907

Daniel Richard G.  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Daniel Richard G.  2012-05-14 
22:51:36 UTC ---
This bug is a duplicate of bug 53348. The failure mode in comment 1 is a
duplicate of bug 53351.

(The linked bug reports are newer, but represent a clearer diagnosis of the
problem, and are filed against version 4.7.0.)

*** This bug has been marked as a duplicate of bug 53348 ***


[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

2012-05-14 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

--- Comment #1 from Daniel Richard G.  2012-05-14 
22:51:36 UTC ---
*** Bug 47907 has been marked as a duplicate of this bug. ***


[Bug bootstrap/53351] New: Missing integer types when bootstrapping on AIX 4.3

2012-05-14 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53351

 Bug #: 53351
   Summary: Missing integer types when bootstrapping on AIX 4.3
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: powerpc-ibm-aix4.3.2.0
Target: powerpc-ibm-aix4.3.2.0
 Build: powerpc-ibm-aix4.3.2.0


Bootstrapping 4.7.0 on AIX 4.3 fails with

[...]
Making all in c++11
gmake[6]: Entering directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/c++11'
/opt/freeware/bin/bash ../../libtool --tag CXX --tag disable-shared 
--mode=compile /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc
-nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include   
-I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++   -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=chrono.lo -std=gnu++11 -g 
-c -o chrono.lo /home/src/gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc
libtool: compile:  /tmp/gcc-build/./gcc/xgcc -shared-libgcc
-B/tmp/gcc-build/./gcc -nostdinc++
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include
-I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=chrono.lo -std=gnu++11 -g -c
/home/src/gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc  -DPIC -o chrono.o
In file included from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/ratio:39:0,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/chrono:38,
 from /home/src/gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc:25:
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:65:11:
error: '::int8_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:66:11:
error: '::int16_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:67:11:
error: '::int32_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:68:11:
error: '::int64_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:70:11:
error: '::int_fast8_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:71:11:
error: '::int_fast16_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:72:11:
error: '::int_fast32_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:73:11:
error: '::int_fast64_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:75:11:
error: '::int_least8_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:76:11:
error: '::int_least16_t' has not been declared
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:77:11:
error: '::int_least32_t' has not been declared
[numerous cascaded errors elided]
gmake[6]: *** [chrono.lo] Error 1
gmake[6]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/c++11'
gmake[6]: Entering directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src'
gmake[6]: *** No rule to make target `../src/c++98/libc++98convenience.la',
needed by `libstdc++.la'.  Stop.
gmake[6]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src'
gmake[5]: *** [all-recursive] Error 1
gmake[5]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2
gmake[2]: Leaving directory `/tmp/gcc-bui

[Bug bootstrap/53348] New: Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

2012-05-14 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

 Bug #: 53348
   Summary: Conflicting fast-integer types on AIX:
 vs. gcc/config/rs6000/aix-stdint.h
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: powerpc-ibm-aix4.3.2.0
Target: powerpc-ibm-aix4.3.2.0
 Build: powerpc-ibm-aix4.3.2.0


Bootstrapping 4.7.0 on AIX 4.3 fails with

[...]
Making all in include
gmake[5]: Entering directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include'
mkdir -p ./powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch
/tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-x c++-header -nostdinc++ -g 
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h \
-o powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/bits/atomic_base.h:37:0,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/atomic:41,
 from
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:100:
/tmp/gcc-build/./gcc/include/stdint.h:72:29: error: conflicting declaration
'typedef short int int_fast16_t'
In file included from /tmp/gcc-build/./gcc/include-fixed/sys/types.h:64:0,
 from /usr/include/sys/lc_core.h:36,
 from /usr/include/sys/localedef.h:43,
 from /tmp/gcc-build/./gcc/include-fixed/ctype.h:131,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cctype:44,
 from
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:36:
/usr/include/sys/inttypes.h:143:18: error: 'int_fast16_t' has a previous
declaration as 'typedef int32_t int_fast16_t'
In file included from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/bits/atomic_base.h:37:0,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/atomic:41,
 from
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:100:
/tmp/gcc-build/./gcc/include/stdint.h:75:29: error: conflicting declaration
'typedef unsigned char uint_fast8_t'
In file included from /tmp/gcc-build/./gcc/include-fixed/sys/types.h:64:0,
 from /usr/include/sys/lc_core.h:36,
 from /usr/include/sys/localedef.h:43,
 from /tmp/gcc-build/./gcc/include-fixed/ctype.h:131,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cctype:44,
 from
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:36:
/usr/include/sys/inttypes.h:145:18: error: 'uint_fast8_t' has a previous
declaration as 'typedef uint32_t uint_fast8_t'
In file included from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/bits/atomic_base.h:37:0,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/atomic:41,
 from
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:100:
/tmp/gcc-build/./gcc/include/stdint.h:76:30: error: conflicting declaration
'typedef short unsigned int uint_fast16_t'
In file included from /tmp/gcc-build/./gcc/include-fixed/sys/types.h:64:0,
 from /usr/include/sys/lc_core.h:36,
 from /usr/include/sys/localedef.h:43,
 from /tmp/gcc-build/./gcc/include-fixed/ctype.h:131,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cctype:44,
 from
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:36:
/usr/include/sys/inttypes.h:146:18: error: 'uint_fast16_t' has a previous
declaration as 'typedef uint32_t uint_fast16_t'
gmake[5]: *** [powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
gmake[5]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *

[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

2012-05-13 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009

--- Comment #8 from Daniel Richard G.  2012-05-14 
03:19:36 UTC ---
Marc, thank you for the pointer. The single-line-edit case, at least, seems
straightforward enough.

Here's my stab at it:

/*
 * stdlib.h on AIX 4.3 declares strtof() with a non-const first argument.
 */
fix = {
hackname  = aix_strtof_const;
files = stdlib.h;
select= "(extern float +strtof)\(char \*, char \*\*\)";
c_fix = format;
c_fix_arg = "%1(const char *, char **)";
test_text = "strtof(char *, char **);";
};


[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

2012-05-12 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009

--- Comment #6 from Daniel Richard G.  2012-05-13 
05:11:32 UTC ---
(In reply to comment #5)
> AIX 4.3 is extremely old and support was withdrawn a while ago. I am surprised
> that anyone is trying to build recent versions of GCC for it. If someone wants
> to develop a fixincludes patch, I can review it. The problem undoubtedly
> exists, but can be worked around manually.

My employer favors the use of older systems for software builds, as Unix is
generally solid on forward compatibility and this prevents awkward scenarios
where a customer is running an older OS than we are.

Continuing GCC support is one of the downsides of this approach, of course. I
wouldn't be surprised if support for AIX 4.3 is obsoleted soon, but I'd like to
ensure that everything is working before that point. (I didn't follow up
Solaris 8 as aggressively, and now I'm trying to get some fixes in even as the
support is being ripped out of 4.8.)

I can provide a unified-diff patch for the header in question; I don't know how
to hack fixincludes. (If anyone can point me to a fixinclude that does the same
kind of one-line change elsewhere, I could work with that...)


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-05-11 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #10 from Daniel Richard G.  2012-05-12 
05:36:16 UTC ---
(In reply to comment #9)
> I won't be able to work on that until I'm back from holiday in two weeks, in
> the meanwhile --disable-libstdcxx-threads should allow you to bootstrap, or
> maybe just --disable-libstdcxx-pch

--disable-libstdcxx-pch isn't enough, alas:

[...]
libtool: compile:  /tmp/gcc-build/./gcc/xgcc -shared-libgcc
-B/tmp/gcc-build/./gcc -nostdinc++
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -pthread
-I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=eh_alloc.lo -g -pthread -c
/home/src/gcc-4.7.0/libstdc++-v3/libsupc++/eh_alloc.cc  -DPIC -o eh_alloc.o
In file included from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-default.h:30:0,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr.h:150,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/ext/concurrence.h:36,
 from
/home/src/gcc-4.7.0/libstdc++-v3/libsupc++/eh_alloc.cc:37:
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-posix.h:
In function 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const
__gthread_time_t*)':
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-posix.h:789:69:
error: 'pthread_mutex_timedlock' was not declared in this scope
gmake[9]: *** [eh_alloc.lo] Error 1
gmake[9]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/libsupc++'
gmake[8]: *** [all-recursive] Error 1
gmake[8]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3'
gmake[7]: *** [all] Error 2
gmake[7]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3'
gmake[6]: *** [multi-do] Error 1
gmake[6]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[5]: *** [all-multi] Error 2
gmake[5]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


Will try with --disable-libstdcxx-threads ...


[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

2012-05-11 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887

--- Comment #8 from Daniel Richard G.  2012-05-12 
05:09:15 UTC ---
(In reply to comment #7)
> Looks as though it also needs
> template class function;

I added that, and with the two instantiations, bootstrap completes
successfully.

(I don't suppose that's the fix, however, given that other systems don't need
this...)


[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

2012-05-11 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009

--- Comment #3 from Daniel Richard G.  2012-05-12 
04:33:41 UTC ---
Created attachment 27384
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27384
/usr/include/stdlib.h from AIX 4.3

Attaching the relevant header file, to aid in development of a fixinclude rule.


[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

2012-05-11 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009

Daniel Richard G.  changed:

   What|Removed |Added

Version|4.5.2   |4.7.0

--- Comment #2 from Daniel Richard G.  2012-05-12 
04:30:17 UTC ---
Still an issue in 4.7.0.

user@host:/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/c++98> gmake
libc++98convenience.la
/opt/freeware/bin/bash ../../libtool --tag CXX --tag disable-shared 
--mode=compile /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc
-nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include   
-I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++   -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=c++locale.lo -g  -c -o
c++locale.lo c++locale.cc
libtool: compile:  /tmp/gcc-build/./gcc/xgcc -shared-libgcc
-B/tmp/gcc-build/./gcc -nostdinc++
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include
-I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=c++locale.lo -g -c
c++locale.cc  -DPIC -o c++locale.o
c++locale.cc: In function 'void std::__convert_to_v(const char*, _Tp&,
std::ios_base::iostate&, int* const&) [with _Tp = float; std::ios_base::iostate
= std::_Ios_Iostate; std::__c_locale = int*]':
c++locale.cc:67:34: error: invalid conversion from 'const char*' to 'char*'
[-fpermissive]
In file included from /tmp/gcc-build/./gcc/include-fixed/math.h:388:0,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cmath:46,
 from c++locale.cc:33:
/tmp/gcc-build/./gcc/include-fixed/stdlib.h:479:18: error:   initializing
argument 1 of 'float strtof(char*, char**)' [-fpermissive]
gmake: *** [c++locale.lo] Error 1


[Bug bootstrap/37122] fixed-value.c and tree-ssa-loop-ivopts.c won't compile with Sun Studio 11 on Solaris 9 due to incompatible operand types

2012-05-11 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37122

--- Comment #6 from Daniel Richard G.  2012-05-11 
19:16:50 UTC ---
Created attachment 27383
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27383
updated patch for 4.7.0

I got bitten by this recently. Bootstrapping GCC 4.7.0 on Solaris 8:

[...]
cc -xarch=v9 -xildoff -c   -g -DIN_GCC-DHAVE_CONFIG_H -I. -I.
-I/home/src/gcc-4.7.0/gcc -I/home/src/gcc-4.7.0/gcc/.
-I/home/src/gcc-4.7.0/gcc/../include
-I/home/src/gcc-4.7.0/gcc/../libcpp/include -I/tg/freeport/arch/sunos64/include
-I/tg/freeport/arch/sunos64/include -I/tg/freeport/arch/sunos64/include 
-I/home/src/gcc-4.7.0/gcc/../libdecnumber
-I/home/src/gcc-4.7.0/gcc/../libdecnumber/dpd -I../libdecnumber   
/home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c -o tree-ssa-loop-ivopts.o
"/home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c", line 6047: operands have
incompatible types:
 struct  {int cost, unsigned int complexity} ":" const struct  {int cost,
unsigned int complexity}
"/home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c", line 6048: operands have
incompatible types:
 struct  {int cost, unsigned int complexity} ":" const struct  {int cost,
unsigned int complexity}
cc: acomp failed for /home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c
gmake[3]: *** [tree-ssa-loop-ivopts.o] Error 2
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


I'd love to patch the compiler, but Oracle won't let me do that unless I give
them a fat wad of money. David's patch to the source is no longer applicable to
4.7.0, so I'm attaching an update.


[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

2012-05-11 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887

--- Comment #6 from Daniel Richard G.  2012-05-11 
17:05:57 UTC ---
With the new build, I now see one missing symbol instead of two. (Not sure why
the earlier hacked build went through):

gmake[3]: Entering directory `/tmp/gcc-4.7.0/_build/gcc'
/tmp/gcc-4.7.0/_build/./prev-gcc/g++ -B/tmp/gcc-4.7.0/_build/./prev-gcc/
-B/opt/tg/powerpc-ibm-aix5.3.0.0/bin/ -nostdinc++
-B/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs
-B/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs
-I/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/powerpc-ibm-aix5.3.0.0
-I/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include
-I/tmp/gcc-4.7.0/libstdc++-v3/libsupc++
-L/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs
-L/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs
  -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1
c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
default-c.o rs6000-c.o \
  cc1-checksum.o main.o  libbackend.a libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   
-L/tg/freeport/arch/aix64/lib -L/tg/freeport/arch/aix64/lib
-L/tg/freeport/arch/aix64/lib -lmpc -lmpfr -lgmp   -L../zlib -lz
ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&)
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
gmake[3]: *** [cc1] Error 1
gmake[3]: Leaving directory `/tmp/gcc-4.7.0/_build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-4.7.0/_build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-4.7.0/_build'
gmake: *** [bootstrap] Error 2


Perhaps one more instantiation is needed?


[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

2012-05-10 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887

--- Comment #5 from Daniel Richard G.  2012-05-10 
22:04:26 UTC ---
(In reply to comment #3)
> does adding this instantiation to libstdc++-v3/src/c++11/regex.cc help?

Apologies Jonathan, I didn't see your comment before submitting my attachment.

Preliminary results are that the instantiation allows the link to proceed. This
was in a tree where the error had already occurred, however, so not the best
test. I've started a new build, with the change in from the beginning, that
should hopefully answer the question definitively by tomorrow.


[Bug other/53299] libiberty usage of GCC_PICFLAG causes -fPIC to be passed to non-GNU compiler

2012-05-10 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53299

--- Comment #3 from Daniel Richard G.  2012-05-10 
20:11:15 UTC ---
(In reply to comment #2)
> What is the correct option to pass to the vendor compiler in order to get code
> suitable for inclusion in a shared library?

In this case, it's -KPIC.

I don't see that this macro should be necessary, however, given that Libtool
already knows the magic PIC incantation for many systems. Another excerpt from
the bootstrap log (this one with --disable-lto and no -errwarn):

[...]
Configuring stage 1 in ./gcc
configure: creating cache ./config.cache
checking build system type... sparc64-sun-solaris2.8
checking host system type... sparc64-sun-solaris2.8
[...]
checking for objdir... .libs
checking for cc -xarch=v9 -xildoff option to produce PIC... -KPIC -DPIC
checking if cc -xarch=v9 -xildoff PIC flag -KPIC -DPIC works... yes
checking if cc -xarch=v9 -xildoff static flag -Bstatic works... no
checking if cc -xarch=v9 -xildoff supports -c -o file.o... yes
checking if cc -xarch=v9 -xildoff supports -c -o file.o... (cached) yes
checking whether the cc -xarch=v9 -xildoff linker (ld -64) supports shared
libraries... yes
checking dynamic linker characteristics... solaris2.8 ld.so
[...]


[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

2012-05-10 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887

--- Comment #4 from Daniel Richard G.  2012-05-10 
15:04:22 UTC ---
Created attachment 27364
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27364
Workaround to provide the two missing symbols

I needed a working 4.7.0, and don't use the STL, so I put together a small
workaround for this bug. Compile this source file, and add the object to the
appropriate libstdc++.a library. More details in the file.

(Note that I build GCC with --disable-shared; "fixing" a shared libstdc++ would
be a bit more involved)


[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

2012-05-10 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887

--- Comment #2 from Daniel Richard G.  2012-05-10 
13:54:12 UTC ---
I can avoid this error during bootstrap by configuring with
--disable-build-poststage1-with-cxx, but then I get the same link error when
building regular C++ programs with the newly-built compiler.


[Bug other/53299] New: libiberty usage of GCC_PICFLAG causes -fPIC to be passed to non-GNU compiler

2012-05-09 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53299

 Bug #: 53299
   Summary: libiberty usage of GCC_PICFLAG causes -fPIC to be
passed to non-GNU compiler
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: sparc64-sun-solaris2.8
Target: sparc64-sun-solaris2.8
 Build: sparc64-sun-solaris2.8


In the course of bootstrapping 4.7.0 on Solaris using the vendor compiler, I
saw this:

[...]
config.status: creating testsuite/Makefile
config.status: creating config.h
config.status: executing default commands
gmake[3]: Entering directory `/tmp/gcc-build/libiberty'
if [ x"-fPIC" != x ] && [ ! -d pic ]; then \
  mkdir pic; \
else true; fi
touch stamp-picdir
if [ x"-fPIC" != x ]; then \
  cc -xarch=v9 -xildoff -errwarn=%all -c -DHAVE_CONFIG_H -g  -I.
-I/home/src/gcc-4.7.0/libiberty/../include   -fPIC
/home/src/gcc-4.7.0/libiberty/regex.c -o pic/regex.o; \
else true; fi
cc: Warning: illegal option -fPIC
cc -xarch=v9 -xildoff -errwarn=%all -c -DHAVE_CONFIG_H -g  -I.
-I/home/src/gcc-4.7.0/libiberty/../include  
/home/src/gcc-4.7.0/libiberty/regex.c -o regex.o
if [ x"-fPIC" != x ]; then \
  cc -xarch=v9 -xildoff -errwarn=%all -c -DHAVE_CONFIG_H -g  -I.
-I/home/src/gcc-4.7.0/libiberty/../include   -fPIC
/home/src/gcc-4.7.0/libiberty/cplus-dem.c -o pic/cplus-dem.o; \
else true; fi
cc: Warning: illegal option -fPIC
[...]


I traced the -fPIC flag to the GCC_PICFLAG macro in the libiberty configure
script. There needs to be a check for whether $CC is GNU or not, because
passing in a bogus flag won't necessarily raise an error (even with -errwarn).


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-05-08 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #8 from Daniel Richard G.  2012-05-08 
18:18:04 UTC ---
I did a non-bootstrap build to speed things up a bit. (The system already has
GCC 4.5.2.)

First: Your patch needs a couple of ";;" sprinkled in there :-)

Second: With the patch, after working around some unrelated integer-type
issues, I get the following error:

[...]
Making all in include
gmake[4]: Entering directory
`/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include'
mkdir -p ./powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch
/tmp/gcc-4.7.0/_build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-4.7.0/_build/./gcc
-nostdinc++ -L/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src
-L/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-x c++-header -nostdinc++ -g -O2
-I/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/tmp/gcc-4.7.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/tmp/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h \
-o powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/tmp/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:102:0:
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:62:13:
error: '__gthread_cond_t' does not name a type
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:67:5:
error: '__native_type' does not name a type
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:71:13:
error: '__native_type' does not name a type
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:141:5:
error: 'native_handle_type' does not name a type
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:
In member function 'std::cv_status
std::condition_variable::__wait_until_impl(std::unique_lock&, const
std::chrono::time_point<_Clock, _Duration>&)':
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:157:2:
error: '__gthread_time_t' was not declared in this scope
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:157:19:
error: expected ';' before '__ts'
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:163:28:
error: '_M_cond' was not declared in this scope
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:164:7:
error: '__ts' was not declared in this scope
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:164:11:
error: there are no arguments to '__gthread_cond_timedwait' that depend on a
template parameter, so a declaration of '__gthread_cond_timedwait' must be
available [-fpermissive]
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:164:11:
note: (if you use '-fpermissive', G++ will accept your code, but allowing the
use of an undeclared name is deprecated)
In file included from
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/future:41:0,
 from
/tmp/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:104:
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: At
global scope:
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:63:13:
error: '__gthread_t' does not name a type
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:70:7:
error: 'native_handle_type' does not name a type
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:76:29:
error: expected ')' before '__id'
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:174:5:
error: 'native_handle_type' does not name a type
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: In
constructor 'std::thread::id::id()':
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:73:23:
error: class 'std::thread::id' does not have any field named '_M_thread'
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: In
function 'bool std::operator==(std::thread::id, std::thread::id)':
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:84:36:
error: 'class std::thread::id' has no member named '_M_thread'
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:84:51:
error: 'class std::thread::id' has no member named '_M_thread'
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:84:60:
error: '__gthread_equal' was not declared in this scope
/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: In
function 'bool std::operator<(std::thread::id, std::thread::id)':
/tmp/gcc-4.

[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-05-07 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #7 from Daniel Richard G.  2012-05-07 
21:09:43 UTC ---
(In reply to comment #6)
> Created attachment 27320 [details]
> diff of regenerated configure

Jonathan, thank you for the patch, and the regen.

I'm starting a new build to test the patch. This AIX machine runs rather slow,
so I'll need a few days to get back to you; please hold tight!


[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'

2012-05-07 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53266

--- Comment #2 from Daniel Richard G.  2012-05-07 
17:42:43 UTC ---
(In reply to comment #1)
> mulhwu is a powerpc but not rs6000 instruction.

When a file failed to compile, I noticed that specifying -mcpu=powerpc got
things going again. I'm not clear on how GCC distinguishes powerpc versus
rs6000, but as far as -mcpu is concerned, the former value seems to exclude
mulhwu.


[Bug bootstrap/53266] New: Error: Unrecognized opcode: `mulhwu'

2012-05-07 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53266

 Bug #: 53266
   Summary: Error: Unrecognized opcode: `mulhwu'
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: powerpc-ibm-aix4.3.2.0
Target: powerpc-ibm-aix4.3.2.0
 Build: powerpc-ibm-aix4.3.2.0


Bootstrapping GCC 4.7.0 on AIX 4.3 fails with

[...]
gmake[3]: Entering directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
DEFINES='' HEADERS='' \
/home/src/gcc-4.7.0/libgcc/mkheader.sh > tmp-libgcc_tm.h
/opt/freeware/bin/bash /home/src/gcc-4.7.0/libgcc/../move-if-change
tmp-libgcc_tm.h libgcc_tm.h
echo timestamp > libgcc_tm.stamp
/tmp/gcc-build/./gcc/xgcc -B/tmp/gcc-build/./gcc/
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-g -O2 -O2  -g -O2 -DIN_GCC   -W
-Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -mlong-double-128 -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -mlong-double-128 -I. -I.
-I../.././gcc -I/home/src/gcc-4.7.0/libgcc -I/home/src/gcc-4.7.0/libgcc/.
-I/home/src/gcc-4.7.0/libgcc/../gcc -I/home/src/gcc-4.7.0/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep
-DL_muldi3 -c /home/src/gcc-4.7.0/libgcc/libgcc2.c 
/tmp//cczJLmgC.s: Assembler messages:
/tmp//cczJLmgC.s:379: Error: Unrecognized opcode: `mulhwu'
gmake[3]: *** [_muldi3.o] Error 1
gmake[3]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


It appears to be the same issue as reported in a comment long ago:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12691#c2

My error was obtained using --with-gnu-as and --disable-multilib.

After some experimentation, I got rid of --disable-multilib, and configured the
tree with --with-cpu=powerpc --disable-aix64 --disable-powercpu, which allowed
the bootstrap to proceed without the above error. However, given that
build=host=target, and that the system triplet explicitly denotes a 32-bit
PowerPC processor, the configuration phase should have detected the need to
avoid unsupported instructions on its own.


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-05-05 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #4 from Daniel Richard G.  2012-05-05 
16:05:30 UTC ---
(In reply to comment #3)
> If you're using --enable-thread=posix then it should be defined.

I haven't used --enable-thread=posix, and if I invoke ".../xgcc -v", I see
"Thread model: aix". So it seems the test passes because _PTHREADS is not
defined.

Shouldn't the cpp conditional in the test be written as

#if !defined(_PTHREADS) || !defined(_POSIX_TIMEOUTS) || _POSIX_TIMEOUTS <=
0

?


[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-05-04 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

--- Comment #2 from Daniel Richard G.  2012-05-04 
20:33:46 UTC ---
(In reply to comment #1)
> You'll need to figure out why the configure test passes, most of us who work 
> on
> that bit of code don't have access to AIX

Below is the relevant excerpt from gcc-4.7.0/libstdc++-v3/acinclude.m4:

8<
  AC_MSG_CHECKING([whether it can be safely assumed that mutex_timedlock is
available])

  AC_TRY_COMPILE([#include ],
[
  // In case of POSIX threads check _POSIX_TIMEOUTS.
  #if (defined(_PTHREADS) \
  && (!defined(_POSIX_TIMEOUTS) || _POSIX_TIMEOUTS <= 0))
  #error
  #endif
], [ac_gthread_use_mutex_timedlock=1], [ac_gthread_use_mutex_timedlock=0])

  AC_DEFINE_UNQUOTED(_GTHREAD_USE_MUTEX_TIMEDLOCK,
$ac_gthread_use_mutex_timedlock,
 [Define to 1 if mutex_timedlock is available.])

  if test $ac_gthread_use_mutex_timedlock = 1 ; then res_mutex_timedlock=yes ;
  else res_mutex_timedlock=no ; fi
  AC_MSG_RESULT([$res_mutex_timedlock])
>8

Neither _PTHREADS nor _POSIX_TIMEOUTS appear anywhere in /usr/include/.

I'm a little mystified as to why this test is relying entirely on feature test
macros, instead of checking for the existence of pthread_mutex_timedlock
directly...


[Bug bootstrap/53238] New: Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

2012-05-04 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238

 Bug #: 53238
   Summary: Bootstrap failure: error: 'pthread_mutex_timedlock'
was not declared in this scope
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: powerpc-ibm-aix4.3.2.0
Target: powerpc-ibm-aix4.3.2.0
 Build: powerpc-ibm-aix4.3.2.0


Bootstrapping 4.7.0 on AIX 4.3...

[...]
gmake[9]: Entering directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include'
mkdir -p ./powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch
/tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include  -pthread -x c++-header -nostdinc++
-g   -pthread
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h \
-o powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-default.h:30:0,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr.h:150,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/ext/atomicity.h:34,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/bits/ios_base.h:41,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/ios:43,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/istream:40,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/sstream:39,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/complex:47,
 from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/ccomplex:42,
 from
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:53:
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-posix.h:
In function 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const
__gthread_time_t*)':
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-posix.h:789:69:
error: 'pthread_mutex_timedlock' was not declared in this scope
gmake[9]: *** [powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
gmake[9]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include'
gmake[8]: *** [all-recursive] Error 1
gmake[8]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3'
gmake[7]: *** [all] Error 2
gmake[7]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3'
gmake[6]: *** [multi-do] Error 1
gmake[6]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[5]: *** [all-multi] Error 2
gmake[5]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


This system does not know about pthread_mutex_timedlock:

$ find /usr/include -type f -exec grep -l pthread_mutex_timedlock {} \;
$

However, a configure check appears to have determined otherwise. In

/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/config.log

, I see the following:


configure:65564: checking whether it can be safely assumed that mutex_timedlock
is available
configure:65583:  /tmp/gcc-build/./gcc/xgcc -shared-libgcc
-B/tmp/gcc-build/./gcc -nostdinc++
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-c -g  -fno-exceptions
-I/home/src/gcc-4.7.0/libstdc++-v3/../l

[Bug bootstrap/53237] New: Bootstrap fails due to mixed declarations and code (c-lex.c)

2012-05-04 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53237

 Bug #: 53237
   Summary: Bootstrap fails due to mixed declarations and code
(c-lex.c)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org


Building 4.7.0 on Solaris using the Sun compiler...

[...]
cc -xarch=v9 -xildoff -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC   
-DHAVE_CONFIG_H -I. -Ic-family -I/home/src/gcc-4.7.0/gcc
-I/home/src/gcc-4.7.0/gcc/c-family -I/home/src/gcc-4.7.0/gcc/../include
-I/home/src/gcc-4.7.0/gcc/../libcpp/include -I/tg/freeport/arch/sunos64/include
-I/tg/freeport/arch/sunos64/include -I/tg/freeport/arch/sunos64/include 
-I/home/src/gcc-4.7.0/gcc/../libdecnumber
-I/home/src/gcc-4.7.0/gcc/../libdecnumber/dpd -I../libdecnumber   
/home/src/gcc-4.7.0/gcc/c-family/c-lex.c -o c-family/c-lex.o
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 353: syntax error before or
at: char
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 354: undefined symbol: str
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 354: cannot dereference
non-pointer type
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 355: syntax error before or
at: literal
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 357: undefined symbol: literal
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 357: warning: improper
pointer/integer combination: op "="
cc: acomp failed for /home/src/gcc-4.7.0/gcc/c-family/c-lex.c
gmake[3]: *** [c-family/c-lex.o] Error 2
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


The relevant portion of c-lex.c is declaring "char *str" in the middle of an
if{} block.


[Bug other/53178] fixinclude needed for iso/ctype_iso.h on Solaris 8

2012-05-02 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53178

--- Comment #2 from Daniel Richard G.  2012-05-02 
15:57:24 UTC ---
(In reply to comment #1)
> Is this problem also present in more recent Solaris releases?

It's gone as of Solaris 10 (the macros have the necessary casts), but I don't
have a 9 system to check.

Can a fixinclude go in, just so that 4.7 can have reasonably complete -Werror
support for Solaris 8? No previous version of GCC is going to have that.


[Bug bootstrap/52847] "case" shell quoting problem in top-level makefile

2012-05-01 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52847

--- Comment #3 from Daniel Richard G.  2012-05-01 
23:01:28 UTC ---
(In reply to comment #1)
> You should not need -mminimal-toc because of this toplevel makefile part.

Ah, good to know. If I don't set -mminimal-toc in CC, I see this when larger
executables are being linked...

ld: 0711-783 WARNING: TOC overflow. TOC size: 474420Maximum size: 65536
Extra instructions are being generated for each reference to a TOC
symbol if the symbol is in the TOC overflow area.

...but the warning is non-fatal, and bootstrapping is otherwise unaffected.


[Bug other/53179] fixinclude needed for pthread.h on AIX 5.3 (PTHREAD_ONCE_INIT)

2012-05-01 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53179

--- Comment #1 from Daniel Richard G.  2012-05-01 
20:17:24 UTC ---
Created attachment 27275
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27275
Fixed version of pthread.h


[Bug other/53179] New: fixinclude needed for pthread.h on AIX 5.3 (PTHREAD_ONCE_INIT)

2012-05-01 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53179

 Bug #: 53179
   Summary: fixinclude needed for pthread.h on AIX 5.3
(PTHREAD_ONCE_INIT)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: powerpc-ibm-aix5.3.0.0
Target: powerpc-ibm-aix5.3.0.0
 Build: powerpc-ibm-aix5.3.0.0


Created attachment 27274
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27274
/usr/include/pthread.h from AIX 5.3

$ cat pth.c
#include 

pthread_once_t once = PTHREAD_ONCE_INIT;

int main(void) { return 0; }

$ OBJECT_MODE=32 gcc -W -Wall -c pth.c
pth.c:3:1: warning: missing braces around initializer
pth.c:3:1: warning: (near initialization for 'once.__on_word')

$ gcc -maix64 -W -Wall -c pth.c
pth.c:3:1: warning: missing braces around initializer
pth.c:3:1: warning: (near initialization for 'once.__on_word')

This is bad if you're building with -Werror.

Inexplicably, both the 32- and 64-bit forms of the PTHREAD_ONCE_INIT
initializer lack a pair of curly-braces. This despite other initializers in the
same file having the same form, and the correct double-brace syntax.

I am attaching a copy of both the original, unmodified pthread.h header, and my
manually-fixed version.


[Bug other/53178] New: fixinclude needed for iso/ctype_iso.h on Solaris 8

2012-05-01 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53178

 Bug #: 53178
   Summary: fixinclude needed for iso/ctype_iso.h on Solaris 8
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: i386-pc-solaris2.8
Target: i386-pc-solaris2.8
 Build: i386-pc-solaris2.8


Created attachment 27273
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27273
/usr/include/iso/ctype_iso.h from Solaris 8

$ cat ctype.c
#include 

int main(void)
{
char c = 'A';

return isgraph(c);
}

$ gcc -W -Wall -c ctype.c
ctype.c: In function 'main':
ctype.c:7:2: warning: array subscript has type 'char' [-Wchar-subscripts]

This is bad if you're building with -Werror.

The problem:

$ grep isgraph /usr/include/iso/ctype_iso.h
extern int isgraph(int);
inline int isgraph(int c) { return (__ctype_mask[c] & _ISGRAPH); }
inline int isgraph(int c) { return ((__ctype + 1)[c] & (_P | _U | _L | _N)); }
#defineisgraph(c)(__ctype_mask[c] & _ISGRAPH)
#defineisgraph(c)((__ctype + 1)[c] & (_P | _U | _L | _N))
#defineisgraph(c)((_ctype + 1)[c] & (_P | _U | _L | _N))

The solution:

$ grep isgraph
/opt/gcc/lib/gcc/i386-pc-solaris2.8/4.7.0/include-fixed/iso/ctype_iso.h
extern int isgraph(int);
inline int isgraph(int c) { return (__ctype_mask[c] & _ISGRAPH); }
inline int isgraph(int c) { return ((__ctype + 1)[c] & (_P | _U | _L | _N)); }
#defineisgraph(c)(__ctype_mask[(int)(c)] & _ISGRAPH)
#defineisgraph(c)((__ctype + 1)[(int)(c)] & (_P | _U | _L | _N))
#defineisgraph(c)((_ctype + 1)[(int)(c)] & (_P | _U | _L | _N))

Same deal with the other isx() routines. I'm attaching the unmodified
system header file for reference.


[Bug bootstrap/52850] Linker path ends up using wrong zlib

2012-04-24 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52850

--- Comment #2 from Daniel Richard G.  2012-04-24 
15:18:33 UTC ---
(In reply to comment #1)
> That sounds like an user problem rather than a GCC issue.

>From the "Installing GCC: Configuration" doc:

--with-system-zlib
Use installed `zlib' rather than that included with GCC. 

If this option was not given (and it wasn't), then GCC should be using its own
zlib, regardless of the presence of other instances of zlib outside of the
build tree.


[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

2012-04-12 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072

Daniel Richard G.  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #36 from Daniel Richard G.  2012-04-12 
16:28:36 UTC ---
My sysadmin recently upgraded the troublesome AIX 5.3 machine in question, and
this has made the linker issues go away. The minimal test case now passes, and
I can compile and link programs again without any workarounds. This is true
both for GCC 4.5.1 (same build as in the original report), and the older GCC
2.9 bundled with the system.

I'll provide the same patch-level information as Paul Pryor did earlier:

$ oslevel -s
5300-12-05-1140

$ ls -l /usr/bin/ld
lrwxrwxrwx1 bin  bin  15 Dec 02 2004  /usr/bin/ld ->
/usr/ccs/bin/ld
$ ls -l /usr/ccs/bin/ld
-r-xr-xr-x1 bin  bin   38942 Aug 09 2011  /usr/ccs/bin/ld

$ lslpp -h bos.rte.bind_cmds
  Fileset Level Action   Status   Date Time
  
Path: /usr/lib/objrepos
  bos.rte.bind_cmds
  5.3.0.0   COMMIT   COMPLETE 12/02/04 17:04:24
  5.3.0.1   COMMIT   COMPLETE 12/06/04 11:52:51
 5.3.0.30   COMMIT   COMPLETE 09/30/10 10:04:35
 5.3.0.40   COMMIT   COMPLETE 10/01/10 11:02:18
 5.3.0.53   COMMIT   COMPLETE 10/01/10 14:15:17
 5.3.0.65   COMMIT   COMPLETE 10/05/10 09:48:48
  5.3.7.5   COMMIT   COMPLETE 10/06/10 10:04:03
  5.3.8.6   COMMIT   COMPLETE 10/07/10 08:13:13
  5.3.9.7   COMMIT   COMPLETE 10/08/10 08:33:35
 5.3.10.4   COMMIT   COMPLETE 10/14/10 10:35:13
 5.3.11.4   COMMIT   COMPLETE 10/15/10 23:31:34
 5.3.12.1   COMMIT   COMPLETE 10/16/10 00:05:56
 5.3.12.4   COMMIT   COMPLETE 04/03/12 12:34:21

$ lslpp -i bos.rte.bind_cmds
Vendor
  Fileset   CodeProduct Id  Feature Id  Package Name
  
Path: /usr/lib/objrepos
  bos.rte.bind_cmds 5.3.0.0
5765-E6200  bos


I will be happy to provide additional details about the configuration of this
system if anyone needs it.

There does not appear to be anything left to do here as far as GCC is
concerned, so I'm marking this bug as invalid. If anyone feels differently,
feel free to change it back.


[Bug bootstrap/52887] New: Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

2012-04-06 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887

 Bug #: 52887
   Summary: Bootstrap on AIX failure: Undefined symbol:
.std::function::function(std::function const&)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: powerpc-ibm-aix5.3.0.0
Target: powerpc-ibm-aix5.3.0.0
 Build: powerpc-ibm-aix5.3.0.0


Bootstrapping GCC 4.7.0 on an AIX 5.3 system fails with

/tmp/gcc-4.7.0-build/./prev-gcc/g++ -B/tmp/gcc-4.7.0-build/./prev-gcc/
-B/opt/tg/powerpc-ibm-aix5.3.0.0/bin/ -nostdinc++
-B/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs
-B/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs
-I/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/powerpc-ibm-aix5.3.0.0
-I/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++
-L/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs
-L/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs
  -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1
c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
default-c.o rs6000-c.o \
  cc1-checksum.o main.o  libbackend.a libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   
-L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -lmpc -lmpfr -lgmp  
-L../zlib -lz
ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&)
ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&)
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
gmake[3]: *** [cc1] Error 1
gmake[3]: Leaving directory `/tmp/gcc-4.7.0-build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-4.7.0-build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-4.7.0-build'
gmake: *** [bootstrap-lean] Error 2


The build tree was configured with

'--prefix=/opt/tg' '--disable-dependency-tracking' '--disable-maintainer-mode'
'--program-prefix=tg-' '--disable-shared' '--disable-nls'
'--enable-version-specific-runtime-libs' '--with-pic' '--with-mpc=/usr/local'
'--with-mpfr=/usr/local' '--with-gmp=/usr/local' 'CC=tg-gcc -mminimal-toc'
'CXX=false' '--enable-languages=c,c++'


[Bug bootstrap/52850] New: Linker path ends up using wrong zlib

2012-04-03 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52850

 Bug #: 52850
   Summary: Linker path ends up using wrong zlib
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org


Bootstrapping GCC on AIX fails with

tg-gcc -mminimal-toc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common 
-DHAVE_CONFIG_H -Wl,-bmaxdata:0x4000 -o cc1 c-lang.o c-family/stub-objc.o
attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o
c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
default-c.o rs6000-c.o \
  cc1-checksum.o main.o tree-browser.o libbackend.a libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a  -liconv ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a-L/tg/freeport/arch/aix64/lib
-L/tg/freeport/arch/aix64/lib -L/tg/freeport/arch/aix64/lib -lmpc -lmpfr -lgmp 
 -L../zlib -lz
ld: 0711-317 ERROR: Undefined symbol: .deflateInit_
ld: 0711-317 ERROR: Undefined symbol: .zError
ld: 0711-317 ERROR: Undefined symbol: .deflate
ld: 0711-317 ERROR: Undefined symbol: .deflateEnd
ld: 0711-317 ERROR: Undefined symbol: .inflateInit_
ld: 0711-317 ERROR: Undefined symbol: .inflate
ld: 0711-317 ERROR: Undefined symbol: .inflateEnd
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
gmake[3]: *** [cc1] Error 1
gmake[3]: Leaving directory `/tmp/gcc-4.7.0-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-4.7.0-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-4.7.0-build'
gmake: *** [bootstrap-lean] Error 2


The problem is that there is an unsuitable copy of libz installed under
/tg/freeport/arch/aix64/lib (where suitable copies of gmp/mpfr/mpc are
located), but since "-L../zlib -lz" is specified after
"-L/tg/freeport/arch/aix64/lib", zlib is obtain from the latter location.

Either "-L../zlib" should be specified prior to any user-supplied library
paths, or the link invocation should specify the libz library file explicitly
rather than use "-lz".


[Bug other/52847] New: "case" shell quoting problem in top-level makefile

2012-04-03 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52847

 Bug #: 52847
   Summary: "case" shell quoting problem in top-level makefile
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org


[Configured on AIX with CC="gcc -mminimal-toc"]

$ gmake bootstrap-lean
echo stage3 > stage_final
/opt/freeware/bin/bash: command substitution: line 1: syntax error near
unexpected token `-mminimal-toc'
/opt/freeware/bin/bash: command substitution: line 1: `case gcc -mminimal-toc
in *gcc*) echo -Wl,-bbigtoc ;; esac;'
gmake[1]: Entering directory `/tmp/gcc-4.7.0-build'
gmake[2]: Entering directory `/tmp/gcc-4.7.0-build'
gmake[2]: Leaving directory `/tmp/gcc-4.7.0-build'
gmake[2]: Entering directory `/tmp/gcc-4.7.0-build'
Configuring stage 1 in ./intl
configure: creating cache ./config.cache
checking whether gmake sets $(MAKE)... yes
[...]

The above warning comes from the below line in the top-level makefile, under
the "host and target specific makefile fragments come in here" header:

LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;`

I believe this needs to be written as

LDFLAGS = `case "$(CC)" in *gcc*) echo -Wl,-bbigtoc ;; esac;`

in order to accommodate values of $(CC) which contain spaces.


[Bug c/37187] please provide a way to treat -pedantic as warning when using -Werror

2011-11-18 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37187

Daniel Richard G.  changed:

   What|Removed |Added

 CC||skunk at iskunk dot org

--- Comment #5 from Daniel Richard G.  2011-11-18 
20:06:13 UTC ---
There is still no way to defang -pedantic warnings with -Werror as of GCC
4.6.1.


[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

2011-09-15 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072

--- Comment #34 from Daniel Richard G.  2011-09-15 
14:01:36 UTC ---
(In reply to comment #33)

Vladimir, this [GCC] bug report has nothing to do with the assembler
segfaulting. The problem is that the linker can't link what the assembler is
producing ("ld: 0711-593 SEVERE ERROR").


  1   2   >