[Bug c++/32364] Error from simple typedef/void combination
--- Comment #2 from craig dot powers at gmail dot com 2007-08-15 19:08
---
(In reply to comment #0)
> Came across this head-scratcher in building Qt with GCC 4.2.0. Heavily
> simplified version:
>
> foo.cxx:
> typedef void (*funcptr)(void);
>
> typedef void GLvoid;
> typedef GLvoid (*_GLUfuncptr)(GLvoid);
>
> int foo(void) { return 1; }
>
> $ g++ -c foo.cxx
> foo.cxx:4: error: '' has incomplete type
> foo.cxx:4: error: invalid use of 'GLvoid'
>
> Compiles fine with 4.1.2 and 2.95.4.
>
You can patch GL/glu.h as e.g.
#ifdef __cplusplus
typedef void (*_GLUfuncptr)(void);
#else
typedef GLvoid (*_GLUfuncptr)(GLvoid);
#endif
I'm assuming that the line that now fails to compile in C++ is still valid C.
I'll admit, I don't really see the point to using a typedef for void.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32364
[Bug c++/32364] Error from simple typedef/void combination
--- Comment #3 from craig dot powers at gmail dot com 2007-08-15 19:13 --- Looking at CVS for glu.h, the official patch is: #ifdef __cplusplus typedef GLvoid (*_GLUfuncptr)(); #else ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32364
[Bug libfortran/20068] New: Backspace problems
For an input file containing: INITIAL_CONFIG 300 The following code will fail with a runtime error if the write statement is commented out: PROGRAM Test IMPLICIT NONE INTEGER, PARAMETER :: DP = SELECTED_REAL_KIND(15,300) REAL(DP) :: init_vel CHARACTER(40) :: Fstart OPEN(UNIT=20,FILE='test.inp',POSITION='REWIND') READ(20,*) Fstart ! WRITE(*,*) 'Reading in key value "',Fstart,'"' BACKSPACE(20) READ(20,*) Fstart, init_vel WRITE(*,*) 'Read was successful: ',Fstart,' = ',init_vel END PROGRAM Test -- Summary: Backspace problems Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: craig dot powers at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20068
[Bug bootstrap/37888] New: make install fails attempting to build gcc/intl.c
Source directory is $HOME/gcc-build/gcc-4.4.-20081017
Object directory is $HOME/gcc-build/gcc-4.4-obj
Configured from the object directory as ../gcc-4.4-20081017/configure
--prefix=$HOME/gcc-trunk --enable-languages=c,c++,fortran
--with-mpfr=$HOME/gcc-build/gcc-4.4-20081017/mpfr
Make was run from the object directory with no errors.
Attempting make install results in:
gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.4-20081017/gcc -I../../gcc-4.4-20081017/gcc/.
-I../../gcc-4.4-20081017/gcc/../include
-I../../gcc-4.4-20081017/gcc/../libcpp/include
-I$HOME/gcc-build/gcc-4.4-20081017/mpfr/include
-I../../gcc-4.4-20081017/gcc/../libdecnumber
-I../../gcc-4.4-20081017/gcc/../libdecnumber/bid -I../libdecnumber\
-DLOCALEDIR=\"$HOME/gcc-trunk/share/locale\" \
-c ../../gcc-4.4-20081017/gcc/intl.c -o intl.o
cc1: error: unrecognized command line option "-Wc++-compat"
cc1: error: unrecognized command line option "-Wno-variadic-macros"
cc1: error: unrecognized command line option "-Wno-overlength-strings"
make[2]: *** [intl.o] Error 1
make[2]: Leaving directory `$HOME/gcc-build/gcc-4.4-obj/gcc'
make[1]: *** [install-gcc] Error 2
make[1]: Leaving directory `$HOME/gcc-build/gcc-4.4-obj'
make: *** [install] Error 2
(I have substituted $HOME for the actual expansion of my home directory. The
home directory is an AFS network shared space.)
Executing the same command line manually (with include directories suitably
modified) produces the same error.
The system gcc is:
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)
--
Summary: make install fails attempting to build gcc/intl.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig dot powers at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888
[Bug fortran/39890] New: Link of a large application fails with spurious multiple symbol definition
I attempted to build my research group's molecular simulation code. Compiling appears to proceed normally, but linking fails with a string of spurious multiple definition errors, e.g. nucleation.o(.bss+0x0): multiple definition of `__nucleation_MOD_atomicpress' nucleation.o(.bss+0x0): first defined here However, running nm on nucleation.o shows only one line for the referenced symbol: B __nucleation_MOD_atomicpress And a grep of the program source shows that atomicpress is only declared in module nucleation, so there is no apparent source for the complaints. This code has been compiled and linked successfully with ifort 11 and a version of pathf95 (either 2.5 or 3.0). -- Summary: Link of a large application fails with spurious multiple symbol definition Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: craig dot powers at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39890
[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition
--- Comment #1 from craig dot powers at gmail dot com 2009-04-25 05:23 --- (In reply to comment #0) I neglected to give my compiler info... /usr/gcc44/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.4.0/configure --prefix=/usr/gcc44 --enable-languages=all Thread model: posix gcc version 4.4.0 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39890
[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition
--- Comment #2 from craig dot powers at gmail dot com 2009-04-25 05:25 --- (In reply to comment #0) Also, I omitted the link invocation: gfortran -O3 -o (exe_name) (big honkin' list of object files) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39890
[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition
--- Comment #3 from craig dot powers at gmail dot com 2009-04-25 05:29 --- (In reply to comment #0) Compiler invocation for each source file: /usr/gcc44/bin/gfortran -c -fbacktrace -x f95-cpp-input -DF2003 -DF2003_NO_ASSOCIATE (source file) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39890
[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition
--- Comment #5 from craig dot powers at gmail dot com 2009-04-25 17:23 --- (In reply to comment #4) > > Also, I omitted the link invocation: > > gfortran -O3 -o (exe_name) (big honkin' list of object files) > > Can you double check that in the "big honkin' list of object files" the file > "nucleation.o" is listed only once? > Oops, that was it. The object file was twice in the list. I should have checked that. -- craig dot powers at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39890
[Bug other/39933] New: make clean fails in libgcc
I was trying to use make clean to clean up after a successful bootstrap and
install.
The error message (and nearby messages) are as follows:
make[1]: Entering directory
`/home/cpowers/src/gcc-4.4.0-obj/x86_64-unknown-linux-gnu/libgcc'
make[1]: -print-multi-directory: Command not found
make[1]: -print-multi-os-directory: Command not found
/bin/sh: line 0: test: !=: unary operator expected
rm -f config.h stamp-h stmp-ldirs libgcc.map
make[1]: *** Recursive variable `AR_FOR_TARGET' references itself (eventually).
Stop.
make[1]: Leaving directory
`/home/cpowers/src/gcc-4.4.0-obj/x86_64-unknown-linux-gnu/libgcc'
make: *** [clean-stage3-target-libgcc] Error 2
--
Summary: make clean fails in libgcc
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig dot powers at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933
[Bug fortran/19479] UBOUND causes ICE
--- Additional Comments From craig dot powers at gmail dot com 2005-02-07 20:48 --- The specific problem statement appears to be line 1799/1801 in gfc_simplify_bound: return gfc_copy_expr (as->upper[i-1]); or return gfc_copy_expr (as->lower[i-1]); The problematic execution sequence is (apologies for any errors due to only fragmentary understanding of the data structures involved): * as is initially set to array->as, where array is the expression sent to gfc_simplify_bound; the symbol from array->symtree->n.sym is named as the derived variable e.g. "tab" in the example. This array spec is null (I presume it's not the right place to get it). * Because there are component references, the following loop walks them. * The first reference is the COMPONENT reference (the name associated with array->symtree->n.sym at this point is the derived type itself e.g. "fft_tab_type" in the example code); it then attempts to take the array spec from there. Unfortunately, this spec is ALSO null. * The second reference is the ARRAY reference; at this point it kicks out of the walk loop because there's nothing following. * The ref variable now points to a gfc_array_ref, and this is actually checked by the code -- if ref->type is not REF_ARRAY or if ref->u.ar.type is not AR_FULL, it kicks out of the routine with a NULL return value. * At this point, as is still null; I presume that with the appropriate logic, it could be taken from ref->u.ar, a simplistic fix like the following: if (! as) as = ref->u.ar.as; seems to fix the problem, with implications down the line unknown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19479
[Bug fortran/19479] UBOUND causes ICE
--- Additional Comments From craig dot powers at gmail dot com 2005-02-08 21:53 --- Further testing indicates that the bug is caused by an array in a derived type -- the pointer is not necessary. program test implicit none type test_type integer, dimension(5) :: a end type test_type type (test_type) :: tt integer i i = ubound(tt%a) end program test In this case, as originally takes on a non-null value (I presume because the type member is now an array rather than a pointer), but in the component walk, it is set to NULL via ref->u.c.sym->as. I think this may be instructive about the precise nature of the bug as originally reported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19479
