[Bug c/25338] New: make: 1254-002 Cannot find a rule to create target, Opencobol on AIX53
Quando executo "configure":
OpenCOBOL Configuration:
COB_CC gcc
CFLAGS -g -O2
COB_CFLAGS -I${prefix}/include
COB_LIBS -L${exec_prefix}/lib -lcob -lm -lgmp -lltdl -lintl
-lncurses
COB_CONFIG_DIR ${prefix}/share/open-cobol/config
COB_LIBRARY_PATH .:${exec_prefix}/lib/open-cobol
COB_MODULE_EXT so
COB_SHARED_OPT -shared
COB_PIC_FLAGS -DPIC
COB_EXPORT_DYN
Use gettext for international messages: yes
Use Berkeley DB for file I/O:no
Use fcntl for file locking: yes
Use ncurses for screen I/O: yes
Quando executo o "make":
gcc -fsigned-char -Wall -Wwrite-strings -Wmissing-prototypes -Wno-format-y2k
-g -O2 -o cobc cobc-cobc.o cobc-config.o cobc-tree.o cobc-reserved.o
cobc-error.o cobc-parser.o cobc-scanner.o cobc-field.o cobc-typeck.o
cobc-codegen.o cobc-ppparse.o cobc-pplex.o -L/opt/freeware/lib -lintl
-liconv ../lib/libsupport.a
-Wl,-blibpath:/opt/freeware/lib:/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.2:/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.2/../../..:/usr/lib:/lib
Target "all-am" is up to date.
Making all in bin
if gcc -DHAVE_CONFIG_H -I. -I. -I..-fsigned-char -Wall
-Wwrite-strings
-Wmissing-prototypes -Wno-format-y2k -I.. -g -O2 -MT cobcrun-cobcrun.o -MD
-MP -MF ".deps/cobcrun-cobcrun.Tpo" -c -o cobcrun-cobcrun.o `test -f
'cobcrun.c' || echo './'`cobcrun.c; then mv -f ".deps/cobcrun-cobcrun.Tpo"
".deps/cobcrun-cobcrun.Po"; else rm -f ".deps/cobcrun-cobcrun.Tpo"; exit 1;
fi
make: 1254-002 Cannot find a rule to create target
../libcob/.libs/libcob_la-call.o from dependencies.
Stop.
--
Summary: make: 1254-002 Cannot find a rule to create target,
Opencobol on AIX53
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jorgefortal at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25338
[Bug other/25200] ICE compiling GNU tar
--- Comment #9 from andreas at florath dot net 2005-12-10 12:09 --- --- gcc-4.2-20051203 --- No differences - same results as for the 4.1 version. --- nameing --- >>The configure line doesn't match the title of the report: the compiler has >>been >>configured as a native 64-bit compiler. The first one I mispelled (it should be sparcv9-sun-solaris2.8 instead of sparc64-sun-solaris2.8) - sorry! --- aim --- My aim: build up a GNU binutils and gcc pair, running on SPARC 64 bit and creating (by default, i. e. without specifying any compiler swicth) SPARC 64 binaries. Also the compiler compiling binutils and boostrapping the compiler should be gcc. >> How did you compile it? Steps (in more detail) (Version of gcc here is 4.2-20051203): (1) gcc [32 -> 32] using Solaris cc and Solaris ld, as, ar, ... Configured compiler with: /appl/tmo/be8/tmp/gcc-4.2-20051203/configure --prefix=/appl/tmo/be8/pkg/pre1 --enable-shared --enable-threads --enable-languages=c --disable-libgcj --enable-multilib sparc-sun-solaris2.8 (2) GNU binutils [32 -> 64] compiled with (1) Configured with: /appl/tmo/be8/tmp/binutils-051130/configure --enable-64-bit-bfd --prefix=/appl/tmo/be8/pkg/pre2 --enable-bfd-assembler --host=sparc-sun-solaris2.8 --target=sparcv9-sun-solaris2.8 (3) gcc [32 -> 64] compiled with (1) and using (2) Configured with: /appl/tmo/be8/tmp/gcc-4.2-20051203/configure --prefix=/appl/tmo/be8/pkg/pre2 --enable-shared --enable-threads --enable-languages=c,c++ --disable-libgcj --with-gnu-as --with-as=/appl/tmo/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-as --with-gnu-ld --with-ld=/appl/tmo/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-ld --disable-multilib sparcv9-sun-solaris2.8 (4) GNU binutils [64 -> 64] compiled with (3) Configured with: /appl/tmo/be8/tmp/binutils-051130/configure --enable-64-bit-bfd --prefix=/appl/tmo/be8/pkg/pre3 --enable-bfd-assembler --host=sparcv9-sun-solaris2.8 --target=sparcv9-sun-solaris2.8 (5) gcc [64 -> 64] compiled with (3) and using (4) Configured with: /appl/tmo/be8/tmp/gcc-4.2-20051203/configure --prefix=/appl/tmo/be8/pkg/pre3 --enable-shared --enable-threads --enable-languages=c,c++ --disable-libgcj --with-gnu-as --with-as=/appl/tmo/be8/pkg/pre3/bin/as --with-gnu-ld --with-ld=/appl/tmo/be8/pkg/pre3/bin/ld --disable-multilib sparcv9-sun-solaris2.8 This works quiet good. When I use gcc (5) now, I'll get 64 bit binaries - without the need to specify any compiler switch. >> That's pretty confusing. What are you trying to do? If you want to build a >> full 64-bit toochain, just build everything directly as 64-bit either with >> "cc >> -xarch=v9" or "gcc -m64" and don't enter the 32/64-bit mixing game. I think the steps I do is one way to get all the tools running and be sure that everything is created with GNU tools. @Eric Botcazou: When you run the testsuites for Solaris V9, are you using 32or 64 bit executables? Are you using Solaris ld, as, ar or the GNU binutils? (I'm asking this, because your results look much better than mine.) > >> >>SPARC V9 is pretty confusing, SPARC64 is a much better moniker. The >>sparc-sun-solaris2.* compiler is a multilib 32-bit compiler and must be >>compiled by a pre-existing 32-bit compiler (e.g. cc). The >>sparc64-sun-solaris2.* compiler a multilib 64-bit compiler and must be >>compiled >>by a pre-existing 64-bit compiler (e.g. cc -xarch=v9). So the test results (sparc64-*-*) are done with SOLARIS ld, as, ar, ..., running 64 bit and producing 32 bit executables using the 32 bit backend? There is no testsuite run for the 64 bit backend? I know that the SPARC compiler is a multilib compiler - but I explicitly disabled this: I really only need 64 bit executables. (I'm not a SPARC expert, I just read the installation instructions http://gcc.gnu.org/install/specific.html#sparcv9-x-solaris2 and thought that SPARC V9 and SPARC 64 are the same.) >> Using any other combination is asking for trouble. Is this, because nobody else had done this before? :-) In my opinion, my way to get a 64 bit-only compiler is leagal - maybe more complicated as just bootstrap with SUNs cc - but it should work. If it does not work, there is a bug somewhere in the chain. (Hope you agree with this?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200
[Bug c/25338] make: 1254-002 Cannot find a rule to create target, Opencobol on AIX53
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-10 12:50 --- And why do you think this is a GCC bug and not just an opencobol bug? There is not enough information here to reproduce this bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25338
[Bug c++/25337] [3.4/4.0/4.1/4.2 Regression]ICE with template processing
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-10 13:01 ---
Reduced testcase:
template T& MakeT();
template ().operator[](0))>
struct helper{};
template
static char is_here(helper*);
This never really worked as we would run into PR 10858 all the time but since
this was a sorry but now we get an ICE this is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||10858
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to work|3.3.6 |
Last reconfirmed|-00-00 00:00:00 |2005-12-10 13:01:57
date||
Summary|ICE with template processing|[3.4/4.0/4.1/4.2
||Regression]ICE with template
||processing
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25337
[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-09-30 05:35:40 |2005-12-10 13:06:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20772
[Bug fortran/23815] Add -byteswapio flag
--- Comment #23 from tkoenig at gcc dot gnu dot org 2005-12-10 13:09 --- Updated patch. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/fortra|http://gcc.gnu.org/ml/fortra |n/2005-12/msg00127.html |n/2005-12/msg00146.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug c++/13590] [DR39] Non-existing ambiguity when inhering through virtuals two identical using declarations.
--- Comment #19 from gcc-bugzilla at kayari dot org 2005-12-10 13:17 --- would the summary be clarified by changing "Non-existing ambiguity when inhering through virtuals two identical using declarations" to "Ambiguity due to two using declarations for same member of virtual base" ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13590
[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64
--- Comment #15 from ghazi at gcc dot gnu dot org 2005-12-10 13:23 --- Subject: Bug 20772 Author: ghazi Date: Sat Dec 10 13:23:19 2005 New Revision: 108348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108348 Log: PR testsuite/20772 * g++.dg/abi/mangle24.C, g++.dg/abi/mangle25.C, g++.dg/ext/vector2.C, g++.dg/opt/longbranch2.C, g++.dg/opt/mmx1.C, g++.dg/opt/reg-stack4.C, gcc.dg/20020108-1.c, gcc.dg/20020122-2.c, gcc.dg/20020122-3.c, gcc.dg/20020206-1.c, gcc.dg/20020310-1.c, gcc.dg/20020411-1.c, gcc.dg/20020418-2.c, gcc.dg/20020426-2.c, gcc.dg/20020517-1.c, gcc.dg/20030204-1.c, gcc.dg/20030826-2.c, gcc.dg/20031202-1.c, gcc.dg/format/unnamed-1.c, gcc.dg/setjmp-2.c, gcc.dg/short-compare-1.c, gcc.dg/short-compare-2.c, gcc.dg/tls/opt-1.c, gcc.dg/tls/opt-2.c, gcc.dg/torture/fp-int-convert-float128-timode.c, gcc.dg/torture/fp-int-convert-float128.c, gcc.dg/torture/fp-int-convert-float80-timode.c, gcc.dg/torture/fp-int-convert-float80.c, gcc.dg/unroll-1.c, gcc.target/i386/20030926-1.c: Merge i?86 and x86_64 cases. * gcc.dg/tls/opt-1.c: Require effective target fpic. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/mangle24.C trunk/gcc/testsuite/g++.dg/abi/mangle25.C trunk/gcc/testsuite/g++.dg/ext/vector2.C trunk/gcc/testsuite/g++.dg/opt/longbranch2.C trunk/gcc/testsuite/g++.dg/opt/mmx1.C trunk/gcc/testsuite/g++.dg/opt/reg-stack4.C trunk/gcc/testsuite/gcc.dg/20020108-1.c trunk/gcc/testsuite/gcc.dg/20020122-2.c trunk/gcc/testsuite/gcc.dg/20020122-3.c trunk/gcc/testsuite/gcc.dg/20020206-1.c trunk/gcc/testsuite/gcc.dg/20020310-1.c trunk/gcc/testsuite/gcc.dg/20020411-1.c trunk/gcc/testsuite/gcc.dg/20020418-2.c trunk/gcc/testsuite/gcc.dg/20020426-2.c trunk/gcc/testsuite/gcc.dg/20020517-1.c trunk/gcc/testsuite/gcc.dg/20030204-1.c trunk/gcc/testsuite/gcc.dg/20030826-2.c trunk/gcc/testsuite/gcc.dg/20031202-1.c trunk/gcc/testsuite/gcc.dg/format/unnamed-1.c trunk/gcc/testsuite/gcc.dg/setjmp-2.c trunk/gcc/testsuite/gcc.dg/short-compare-1.c trunk/gcc/testsuite/gcc.dg/short-compare-2.c trunk/gcc/testsuite/gcc.dg/tls/opt-1.c trunk/gcc/testsuite/gcc.dg/tls/opt-2.c trunk/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode.c trunk/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128.c trunk/gcc/testsuite/gcc.dg/torture/fp-int-convert-float80-timode.c trunk/gcc/testsuite/gcc.dg/torture/fp-int-convert-float80.c trunk/gcc/testsuite/gcc.dg/unroll-1.c trunk/gcc/testsuite/gcc.target/i386/20030926-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20772
[Bug ada/25245] Discriminant is left uninitialized.
--- Comment #8 from laurent at guerby dot net 2005-12-10 13:26 --- Ok I now agree on both counts :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25245
[Bug other/25200] ICE compiling GNU tar
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-12-10 13:42 --- > >>The configure line doesn't match the title of the report: the compiler has > >>been configured as a native 64-bit compiler. > > The first one I mispelled (it should be sparcv9-sun-solaris2.8 instead > of sparc64-sun-solaris2.8) - sorry! You missed the point. Look at the configure lines at the very bottom of the first report, they are not in keeping with the title. You configured your 3rd compiler as a native sparcv9-sun-solaris2.8 compiler, while it should have been configured as specified in the title. And since you built it with a 32-bit compiler, it cannot reasonably work. > My aim: build up a GNU binutils and gcc pair, running on SPARC 64 bit > and creating (by default, i. e. without specifying any compiler swicth) > SPARC 64 binaries. Also the compiler compiling binutils and > boostrapping the compiler should be gcc. The last point is irrelevant, as the very purpose of bootstrapping is precisely to let GCC compile itself. The compiler you start from doesn't matter. Simply take the followig steps: - build GNU Binutils as sparcv9-sun-solaris2.8 with "cc -xarch=v9" - bootstrap GCC as sparcv9-sun-solaris2.8 with "cc -xarch=v9" - rebuild GNU Binutils with GCC You are less likely to make mistakes because you don't fiddle with 32-bit stuff. > (3) gcc [32 -> 64] compiled with (1) and using (2) > Configured with: > /appl/tmo/be8/tmp/gcc-4.2-20051203/configure > --prefix=/appl/tmo/be8/pkg/pre2 --enable-shared --enable-threads > --enable-languages=c,c++ --disable-libgcj --with-gnu-as > --with-as=/appl/tmo/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-as --with-gnu-ld > --with-ld=/appl/tmo/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-ld > --disable-multilib sparcv9-sun-solaris2.8 That's wrong. It should be configured like the Binutils in step 2. > This works quiet good. You're lucky then. :-) Step 3 is definitely wrong. > So the test results (sparc64-*-*) are done with SOLARIS ld, as, ar, ..., > running 64 bit and producing 32 bit executables using the 32 bit backend? No, sparc64-*-* is a 64-bit compiler generating 64-bit binaries. It generates 32-bit binaries only when passed with -m32. > There is no testsuite run for the 64 bit backend? See above. > I know that the SPARC compiler is a multilib compiler - but I > explicitly disabled this: I really only need 64 bit executables. > (I'm not a SPARC expert, I just read the installation instructions > http://gcc.gnu.org/install/specific.html#sparcv9-x-solaris2 > and thought that SPARC V9 and SPARC 64 are the same.) Yes they are, but we prefer sparc64-*-* over sparcv9-*-* (and the option -mcpu=v9 doesn't cause 64-bit code to be generated). > Is this, because nobody else had done this before? :-) Yeah, not everyone is crazy enough to use 5 steps to get a 64-bit toolchain while 2 are sufficient. :-) > In my opinion, my way to get a 64 bit-only compiler is leagal - maybe > more complicated as just bootstrap with SUNs cc - but it should work. Except step 3. > If it does not work, there is a bug somewhere in the chain. (Hope > you agree with this?) Yes, I agree that, if you fix step 3, that should theoritically work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200
[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64
--- Comment #16 from ghazi at gcc dot gnu dot org 2005-12-10 13:47 --- Subject: Bug 20772 Author: ghazi Date: Sat Dec 10 13:47:29 2005 New Revision: 108349 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108349 Log: PR testsuite/20772 * g++.dg/abi/mangle24.C, g++.dg/abi/mangle25.C, g++.dg/ext/vector2.C, g++.dg/opt/longbranch2.C, g++.dg/opt/mmx1.C, g++.dg/opt/reg-stack4.C, gcc.dg/20020108-1.c, gcc.dg/20020122-2.c, gcc.dg/20020122-3.c, gcc.dg/20020206-1.c, gcc.dg/20020310-1.c, gcc.dg/20020411-1.c, gcc.dg/20020418-2.c, gcc.dg/20020426-2.c, gcc.dg/20020517-1.c, gcc.dg/20030204-1.c, gcc.dg/20030826-2.c, gcc.dg/20031202-1.c, gcc.dg/format/unnamed-1.c, gcc.dg/setjmp-2.c, gcc.dg/short-compare-1.c, gcc.dg/short-compare-2.c, gcc.dg/tls/opt-1.c, gcc.dg/tls/opt-2.c, gcc.dg/unroll-1.c, gcc.target/i386/20030926-1.c: Merge i?86 and x86_64 cases. * gcc.dg/tls/opt-1.c: Require effective target fpic. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/abi/mangle24.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/abi/mangle25.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/vector2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/longbranch2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/mmx1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/reg-stack4.C branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020108-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020122-2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020122-3.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020206-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020310-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020411-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020418-2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020426-2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020517-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20030204-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20030826-2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20031202-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/format/unnamed-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/setjmp-2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/short-compare-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/short-compare-2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tls/opt-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tls/opt-2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/unroll-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/20030926-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20772
[Bug target/25339] New: /usr/bin/ld: Procedure labels require the P' selector
/xxx/gnu/gcc-3.3/objdir/./gcc/xgcc -shared-libgcc -B/xxx/gnu/gcc-3.3/objdir/./g cc -nostdinc++ -L/xxx/gnu/gcc-3.3/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/src - L/xxx/gnu/gcc-3.3/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/src/.libs -B/opt/gnu/ gcc/gcc-4.1.0/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.1.0/hppa1.1-hp-hpux 10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.1.0/hppa1.1-hp-hpux10.20/include -isystem /opt/gnu/gcc/gcc-4.1.0/hppa1.1-hp-hpux10.20/sys-include -shared -nostdlib -fPIC -Wl,+h -Wl,libstdc++.sl.6 -Wl,+b -Wl,/opt/gnu/gcc/gcc-4.1.0/lib -o .libs/libstd c++.sl.6.7 .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator. o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/d ebug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_locale.o .libs/globa ls_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .lib s/limits.o .libs/list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/tree.o .libs/alloc ator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/io- inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/locale-mis c-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/strea mbuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wl ocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .lib s/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetar y_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .lib s/c++locale.o .libs/libstdc++.lax/libmath.a/stubs.o .libs/libstdc++.lax/libmath. a/signbit.o .libs/libstdc++.lax/libmath.a/signbitf.o .libs/libstdc++.lax/libsup c++convenience.a/del_op.o .libs/libstdc++.lax/libsupc++convenience.a/del_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/del_opv.o .libs/libstdc++.lax/libsupc ++convenience.a/del_opvnt.o .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc. o .libs/libstdc++.lax/libsupc++convenience.a/eh_arm.o .libs/libstdc++.lax/libsup c++convenience.a/eh_aux_runtime.o .libs/libstdc++.lax/libsupc++convenience.a/eh_ call.o .libs/libstdc++.lax/libsupc++convenience.a/eh_catch.o .libs/libstdc++.lax /libsupc++convenience.a/eh_exception.o .libs/libstdc++.lax/libsupc++convenience. a/eh_globals.o .libs/libstdc++.lax/libsupc++convenience.a/eh_personality.o .libs /libstdc++.lax/libsupc++convenience.a/eh_term_handler.o .libs/libstdc++.lax/libs upc++convenience.a/eh_terminate.o .libs/libstdc++.lax/libsupc++convenience.a/eh_ throw.o .libs/libstdc++.lax/libsupc++convenience.a/eh_type.o .libs/libstdc++.lax /libsupc++convenience.a/eh_unex_handler.o .libs/libstdc++.lax/libsupc++convenien ce.a/guard.o .libs/libstdc++.lax/libsupc++convenience.a/new_handler.o .libs/libs tdc++.lax/libsupc++convenience.a/new_op.o .libs/libstdc++.lax/libsupc++convenien ce.a/new_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/new_opv.o .libs/libst dc++.lax/libsupc++convenience.a/new_opvnt.o .libs/libstdc++.lax/libsupc++conveni ence.a/pure.o .libs/libstdc++.lax/libsupc++convenience.a/tinfo.o .libs/libstdc++ .lax/libsupc++convenience.a/tinfo2.o .libs/libstdc++.lax/libsupc++convenience.a/ vec.o .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o .libs/libstdc++.la x/libsupc++convenience.a/cp-demangle.o -L/xxx/gnu/gcc-3.3/objdir/hppa1.1-hp-hp ux10.20/libstdc++-v3/src -L/xxx/gnu/gcc-3.3/objdir/hppa1.1-hp-hpux10.20/libstdc+ +-v3/src/.libs -lm ../libmath/.libs/libmath.a -lm ../libsupc++/.libs/libsupc++co nvenience.a -lm -L/xxx/gnu/gcc-3.3/objdir/./gcc -L/usr/ccs/lib -L/opt/langtools/ lib -L/opt/gnu/gcc/gcc-4.1.0/lib -lgcc_s -lgcc_s -lm -lgcc_s -lgcc_s -lc /usr/bin/ld: Procedure labels require the P' selector - use the P' selector on c ode symbol "typeinfo for std::logic_error" in file .libs/functexcept.o collect2: ld returned 1 exit status make[5]: *** [libstdc++.la] Error 1 make[5]: Leaving directory `/xxx/gnu/gcc-3.3/objdir/hppa1.1-hp-hpux10.20/libstdc ++-v3/src' make[4]: *** [all-recursive] Error 1 I'm fairly certain Richard's large patch to revamp section handling broke the handling of one-only data on hpux 10 but I'm not sure if this is the cause of the above error. -- Summary: /usr/bin/ld: Procedure labels require the P' selector Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25339
[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64
--- Comment #17 from ghazi at gcc dot gnu dot org 2005-12-10 14:29 --- Subject: Bug 20772 Author: ghazi Date: Sat Dec 10 14:29:38 2005 New Revision: 108350 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108350 Log: PR testsuite/20772 * g++.dg/abi/bitfield3.C, g++.dg/abi/bitfield8.C, g++.dg/abi/bitfield9.C, g++.dg/abi/dtor1.C, g++.dg/abi/empty10.C, g++.dg/abi/empty7.C, g++.dg/abi/empty9.C, g++.dg/abi/layout3.C, g++.dg/abi/layout4.C, g++.dg/abi/thunk1.C, g++.dg/abi/thunk2.C, g++.dg/abi/vbase11.C, g++.dg/abi/vthunk2.C, g++.dg/abi/vthunk3.C, g++.dg/charset/asm2.c, g++.dg/eh/simd-1.C, g++.dg/eh/simd-2.C, g++.dg/ext/attrib8.C, g++.dg/ext/vector2.C, g++.dg/opt/cse2.C, g++.dg/opt/inline9.C, g++.dg/opt/life1.C, g++.dg/opt/longbranch2.C, g++.dg/opt/mmx1.C, g++.dg/opt/reg-stack4.C, g++.dg/other/big-struct.C, g++.dg/warn/register-var-1.C, g++.old-deja/g++.abi/aggregates.C, g++.old-deja/g++.abi/align.C, g++.old-deja/g++.abi/bitfields.C, g++.old-deja/g++.ext/asmspec1.C, g++.old-deja/g++.ext/attrib1.C, g++.old-deja/g++.ext/attrib2.C, g++.old-deja/g++.ext/attrib3.C, g++.old-deja/g++.law/weak.C, g++.old-deja/g++.other/regstack.C, g++.old-deja/g++.other/store-expr1.C, g++.old-deja/g++.other/store-expr2.C, g++.old-deja/g++.pt/asm1.C, g++.old-deja/g++.pt/asm2.C, gcc.c-torture/compile/2804-1.c, gcc.dg/2609-1.c, gcc.dg/2614-1.c, gcc.dg/2720-1.c, gcc.dg/2724-1.c, gcc.dg/2807-1.c, gcc.dg/2904-1.c, gcc.dg/20001127-1.c, gcc.dg/20010202-1.c, gcc.dg/20010520-1.c, gcc.dg/20011009-1.c, gcc.dg/20011029-2.c, gcc.dg/20011107-1.c, gcc.dg/2009-1.c, gcc.dg/20020108-1.c, gcc.dg/20020122-2.c, gcc.dg/20020122-3.c, gcc.dg/20020201-3.c, gcc.dg/20020206-1.c, gcc.dg/20020218-1.c, gcc.dg/20020224-1.c, gcc.dg/20020310-1.c, gcc.dg/20020411-1.c, gcc.dg/20020418-1.c, gcc.dg/20020418-2.c, gcc.dg/20020426-1.c, gcc.dg/20020426-2.c, gcc.dg/20020517-1.c, gcc.dg/20020523-2.c, gcc.dg/20020531-1.c, gcc.dg/20020616-1.c, gcc.dg/20020729-1.c, gcc.dg/20030204-1.c, gcc.dg/20030826-2.c, gcc.dg/20030926-1.c, gcc.dg/20031102-1.c, gcc.dg/20031202-1.c, gcc.dg/980226-1.c, gcc.dg/980312-1.c, gcc.dg/980313-1.c, gcc.dg/980414-1.c, gcc.dg/980520-1.c, gcc.dg/980709-1.c, gcc.dg/990117-1.c, gcc.dg/990130-1.c, gcc.dg/990213-2.c, gcc.dg/990214-1.c, gcc.dg/990424-1.c, gcc.dg/990524-1.c, gcc.dg/991129-1.c, gcc.dg/991209-1.c, gcc.dg/991214-1.c, gcc.dg/991230-1.c, gcc.dg/charset/asm3.c, gcc.dg/clobbers.c, gcc.dg/format/unnamed-1.c, gcc.dg/i386-387-1.c, gcc.dg/i386-387-2.c, gcc.dg/i386-387-3.c, gcc.dg/i386-387-4.c, gcc.dg/i386-387-5.c, gcc.dg/i386-387-6.c, gcc.dg/i386-387-7.c, gcc.dg/i386-387-8.c, gcc.dg/i386-3dnowA-1.c, gcc.dg/i386-3dnowA-2.c, gcc.dg/i386-asm-1.c, gcc.dg/i386-asm-2.c, gcc.dg/i386-asm-3.c, gcc.dg/i386-bitfield1.c, gcc.dg/i386-bitfield2.c, gcc.dg/i386-bitfield3.c, gcc.dg/i386-call-1.c, gcc.dg/i386-loop-1.c, gcc.dg/i386-loop-2.c, gcc.dg/i386-loop-3.c, gcc.dg/i386-memset-1.c, gcc.dg/i386-pentium4-not-mull.c, gcc.dg/i386-pic-1.c, gcc.dg/i386-regparm.c, gcc.dg/i386-signbit-1.c, gcc.dg/i386-signbit-2.c, gcc.dg/i386-signbit-3.c, gcc.dg/i386-sse-5.c, gcc.dg/i386-sse-8.c, gcc.dg/i386-unroll-1.c, gcc.dg/i386-volatile-1.c, gcc.dg/loop-3.c, gcc.dg/pr12092-1.c, gcc.dg/pr14289-1.c, gcc.dg/pr19236-1.c, gcc.dg/pr20017.c, gcc.dg/pr20204.c, gcc.dg/pr9771-1.c, gcc.dg/pragma-align.c, gcc.dg/register-var-1.c, gcc.dg/setjmp-2.c, gcc.dg/short-compare-1.c, gcc.dg/short-compare-2.c, gcc.dg/sibcall-5.c, gcc.dg/smod-1.c, gcc.dg/tls/opt-1.c, gcc.dg/tls/opt-2.c, gcc.dg/tls/opt-3.c, gcc.dg/torture/badshift.c, gcc.dg/unroll-1.c, gcc.misc-tests/i386-pf-3dnow-1.c, gcc.misc-tests/i386-pf-athlon-1.c, gcc.misc-tests/i386-pf-none-1.c, gcc.misc-tests/i386-pf-sse-1.c, gfortran.dg/promotion.f90: Backport from mainline. Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/bitfield3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/bitfield8.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/bitfield9.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/dtor1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/empty10.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/empty7.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/empty9.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/layout3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/layout4.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/thunk1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/abi/thunk2.C branches/gcc-
[Bug target/25339] [4.2 Regression] /usr/bin/ld: Procedure labels require the P' selector
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, link-failure Summary|/usr/bin/ld: Procedure |[4.2 Regression] |labels require the P' |/usr/bin/ld: Procedure |selector|labels require the P' ||selector Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25339
[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-12-10 15:39 --- There are two errors on this one. The first is not a regression (happens with 4.0.3): $ cat a.f90 integer :: i = 1 open(11,status="replace",form="unformatted") read(11,end=1008) i 1008 continue read(11,end=1011) i 1011 continue end $ gfortran a.f90 && ./a.out At line 5 of file a.f90 Fortran runtime error: Read past ENDFILE record The second one is a regression (doesn't happen with 4.0.3). $ cat a.f90 integer :: i = 1 open(11,status="replace",form="unformatted") write(11) dat read(11,end=1008) i 1008 continue backspace 11 backspace 11 backspace 11 end $ gfortran a.f90 && ./a.out At line 8 of file a.f90 Fortran runtime error: Invalid argument PS: sorry Janne for hinting that it might have been related to your patch. Reducing this has been a bit painful. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 4.2.0 Known to work||4.0.3 Last reconfirmed|2005-11-29 12:29:53 |2005-12-10 15:39:19 date|| Summary|"Invalid argument" error on |[4.1/4.2 regression] |I/O |"Invalid argument" error on ||I/O http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
[Bug target/25258] [4.0 regression/hpux] gcc generates incorrect stabs debug output
--- Comment #5 from danglin at gcc dot gnu dot org 2005-12-10 15:45 --- Subject: Bug 25258 Author: danglin Date: Sat Dec 10 15:45:43 2005 New Revision: 108351 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108351 Log: PR target/25258 * pa.c (som_text_section_asm_op): Use .NSUBSPA directive when changing to the text subspace to output debugging information. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25258
[Bug target/25258] [4.0 regression/hpux] gcc generates incorrect stabs debug output
--- Comment #6 from danglin at gcc dot gnu dot org 2005-12-10 16:02 --- Subject: Bug 25258 Author: danglin Date: Sat Dec 10 16:01:56 2005 New Revision: 108352 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108352 Log: PR target/25258 * pa.c (som_text_section_asm_op): Use .NSUBSPA directive when changing to the text subspace to output debugging information. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25258
[Bug target/25258] [4.0 regression/hpux] gcc generates incorrect stabs debug output
--- Comment #7 from danglin at gcc dot gnu dot org 2005-12-10 16:08 --- Subject: Bug 25258 Author: danglin Date: Sat Dec 10 16:08:24 2005 New Revision: 108353 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108353 Log: PR target/25258 * pa.c (som_text_section_asm_op): Use .NSUBSPA directive when changing to the text subspace to output debugging information. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25258
[Bug libfortran/25289] Cannot handle record numbers large than huge(0_4)
--- Comment #1 from jb at gcc dot gnu dot org 2005-12-10 16:17 --- Confirmed. I guess this is because rec=n is transferred to the library as a gfc_integer_4, but it should be gfc_offset. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-10 16:17:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25289
[Bug libfortran/25340] New: Runtime error: "Read past ENDFILE record"
PR 25139 is in fact two different bugs, so I open this PR to separate them. $ cat a.f90 integer :: i = 1 open(11,status="replace",form="unformatted") read(11,end=1008) i 1008 continue read(11,end=1011) i 1011 continue end $ gfortran a.f90 && ./a.out At line 5 of file a.f90 Fortran runtime error: Read past ENDFILE record -- Summary: Runtime error: "Read past ENDFILE record" Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25340
[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-12-10 16:39 --- I found the problem in the second one, which is fixed by the one-line patch: Index: io/file_pos.c === --- io/file_pos.c (revision 108353) +++ io/file_pos.c (working copy) @@ -109,13 +109,14 @@ length = sizeof (gfc_offset); - p = salloc_r_at (u->s, &length, - file_position (u->s) - length); + /* length is modified by this function call, and most probably + set to zero. */ + p = salloc_r_at (u->s, &length, file_position (u->s) - length); if (p == NULL) goto io_error; memcpy (&m, p, sizeof (gfc_offset)); - new = file_position (u->s) - m - 2*length; + new = file_position (u->s) - m - sizeof (gfc_offset) - length; if (sseek (u->s, new) == FAILURE) goto io_error; (well, more than one line since I added a comment so that we don't do this mistake again). Since this does not fixed the other problem, I filed it separately under PR 25340. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-12-10 15:39:19 |2005-12-10 16:39:26 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
[Bug libfortran/25340] Runtime error: "Read past ENDFILE record"
--- Comment #1 from kargl at gcc dot gnu dot org 2005-12-10 16:55 --- What is the bug? 9.4.1.6 End-of-file branch If an end-of-file condition (9.4.3) occurs and no error condition (9.4.3) occurs during execution of an input statement that contains an END= specifier (1) Execution of the input statement terminates, (2) If the file specified in the input statement is an external file, it is positioned after the endfile record. So, after the first read(11,end=1008), the file is positioned "after the endfile record." Your second read(11,end=1011) is reading past the ENDFILE record, which is what the runtime error says. Now, if your second read statement had been read(11,err=1011), then everything should work out. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25340
[Bug treelang/25341] New: tree_code_create_variable does not "handle" global variables properly
Although treelang does not support global variables, if support for them is
ever added, there might be a problem with tree_code_create_variable()
(treetree.c). Inside tree_code_create_variable() is the following switch:
switch (storage_class)
{
case STATIC_STORAGE:
TREE_STATIC (var_decl) = 1;
break;
case AUTOMATIC_STORAGE:
break;
case EXTERNAL_DEFINITION_STORAGE:
TREE_PUBLIC (var_decl) = 1;
break;
case EXTERNAL_REFERENCE_STORAGE:
DECL_EXTERNAL (var_decl) = 1;
break;
default:
gcc_unreachable ();
}
Calling tree_code_create_variable() with a storage class of
"EXTERNAL_DEFINITION_STORAGE" while in file scope does not create the global
variable properly. No allocation for the variable will be done, because the
TREE_STATIC property is set to 0, as if this were an "auto" variable.
Here is my diff for the fix, with an added check that there cannot be auto
global variables (applied to treetree.c of the GCC 4.0.2):
548a549,553
> if (current_function_decl == NULL_TREE)
> {
> error ("file-scope variable with automatic storage class");
> return error_mark_node;
> }
551a557,561
> if (current_function_decl == NULL_TREE)
> {
> /* Global extern variables cannot also be auto. */
> TREE_STATIC (var_decl) = 1;
> }
--
Summary: tree_code_create_variable does not "handle" global
variables properly
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: treelang
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: someone42 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25341
[Bug libfortran/25289] Cannot handle record numbers large than huge(0_4)
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-12-10 17:52 --- (In reply to comment #1) > Confirmed. I guess this is because rec=n is transferred to the library as a > gfc_integer_4, but it should be gfc_offset. Yes, I was beginning to think about that, but it has strongly implications on the general front-end/library configury, I guess. See my last mails in ml thread "Generalizing the library to arbitrary floating point modes" (the topic deviated!). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25289
[Bug libfortran/25307] internal read with end=label aborts
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-12-10 19:06 --- Confirmed. It's a library-side issue. I think I have a fix for it, currently under testing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-10 19:06:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25307
[Bug libfortran/25307] internal read with end=label aborts
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-12-10 19:31 --- (In reply to comment #1) > I think I have a fix for it, currently under testing. Forget that part. This bug is more serious than I thought. The code in next_char() might need some important changes... I'm currently stuck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25307
[Bug fortran/25068] IOSTAT should be default integer when -std=f95
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-10 19:42 --- (In reply to comment #2) >> I think we have the right to >> accept non-default IOSTAT variable if we do it correctly ;) > > not with -std=f95 This time, I read both the F95 and F2003 standard, and this is indeed a F95 constraint that disapeared in F2003. How cool! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-10 19:42:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25068
[Bug fortran/23815] Add -byteswapio flag
--- Comment #24 from tkoenig at gcc dot gnu dot org 2005-12-10 20:02 --- Subject: Bug 23815 Author: tkoenig Date: Sat Dec 10 20:01:56 2005 New Revision: 108358 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108358 Log: 2005-12-10 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/23815 * io.c (top level): Add convert to io_tag. (resolve_tag): convert is GFC_STD_GNU. (match_open_element): Add convert. (gfc_free_open): Likewise. (gfc_resolve_open): Likewise. (gfc_free_inquire): Likewise. (match_inquire_element): Likewise. * dump-parse-tree.c (gfc_show_code_node): Add convet for open and inquire. gfortran.h: Add convert to gfc_open and gfc_inquire. * trans-io.c (gfc_trans_open): Add convert. (gfc_trans_inquire): Likewise. * ioparm.def: Add convert to open and inquire. * gfortran.texi: Document CONVERT. 2005-12-10 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/23815 * io/file_pos.c (unformatted_backspace): If flags.convert does not equal CONVERT_NATIVE, reverse the record marker. * io/open.c: Add convert_opt[]. (st_open): If no convert option is given, set CONVERT_NATIVE. If CONVERT_BIG or CONVERT_LITTLE are given, set flags.convert to CONVERT_NATIVE or CONVERT_SWAP (depending on wether we have a big- or little-endian system). * io/transfer.c (unformatted_read): Remove unused attribute from arguments. If we need to reverse bytes, break up large transfers into a loop. Split complex numbers into its two parts. (unformatted_write): Likewise. (us_read): If flags.convert does not equal CONVERT_NATIVE, reverse the record marker. (next_record_w): Likewise. (reverse_memcpy): New function. * io/inquire.c (inquire_via_unit): Implement convert. * io/io.h (top level): Add enum unit_convert. Add convert to st_parameter_open and st_parameter_inquire. Define IOPARM_OPEN_HAS_CONVERT and IOPARM_INQUIRE_HAS_CONVERT. Increase padding for st_parameter_dt. Declare reverse_memcpy(). 2005-12-10 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/23815 * gfortran.dg/unf_io_convert_1.f90: New test. * gfortran.dg/unf_io_convert_2.f90: New test. * gfortran.dg/unf_io_convert_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/unf_io_convert_1.f90 trunk/gcc/testsuite/gfortran.dg/unf_io_convert_2.f90 trunk/gcc/testsuite/gfortran.dg/unf_io_convert_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/io.c trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/inquire.c trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug fortran/23815] Add -byteswapio flag
--- Comment #25 from tkoenig at gcc dot gnu dot org 2005-12-10 20:12 --- The committed patch implements the basic functionality, via the CONVERT keyword for open. We still need different options to select this (via compile-time flags and environment variables), so I'm leaving this bug open. Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/fortra| |n/2005-12/msg00146.html | Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug libfortran/25307] internal read with end=label aborts
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-12-10 20:21 --- Where and how end of record or end of file is detected is very sensitive in this code for internal IO. I am currently dredging on 25264 which also has sensitivities. When you work at this long enough you realize that you have at least three different code paths intermixed in transfer. Files, scaler character strings, and character arrays. If you think you know whats up here, give me some feedback so we don't clobber each other. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25307
[Bug libfortran/25307] internal read with end=label aborts
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-10 20:29 --- (In reply to comment #3) > If you think you know whats up here, give me some feedback so we don't clobber > each other. :) I'll let this one to you, I really can't figure it out (it's making my head spin). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25307
[Bug fortran/25252] ICE on invalid code
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-12-10 20:30 --- Confirmed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2005-12-10 20:30:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug fortran/25068] IOSTAT should be default integer when -std=f95
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-12-10 21:44 --- Subject: Bug 25068 Author: fxcoudert Date: Sat Dec 10 21:44:43 2005 New Revision: 108360 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108360 Log: PR fortran/25068 * io.c (resolve_tag): Add correct diagnostic for F2003 feature. * gfortran.dg/iostat_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/iostat_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25068
[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c
--- Comment #8 from danglin at gcc dot gnu dot org 2005-12-10 21:48 --- Created an attachment (id=10447) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10447&action=view) .s output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c
--- Comment #9 from danglin at gcc dot gnu dot org 2005-12-10 21:48 --- Created an attachment (id=10448) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10448&action=view) .s file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug fortran/25068] [4.0/4.1] IOSTAT should be default integer when -std=f95
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-12-10 21:53 --- Fixed on mainline. Will backport the fix to 4.1 after a few days. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch Known to fail||4.1.0 4.0.3 Known to work||4.2.0 Last reconfirmed|2005-12-10 19:42:53 |2005-12-10 21:53:40 date|| Summary|IOSTAT should be default|[4.0/4.1] IOSTAT should be |integer when -std=f95 |default integer when - ||std=f95 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25068
[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c
--- Comment #10 from danglin at gcc dot gnu dot org 2005-12-10 22:22 --- GCC is generating incorrect assembler code for the target of weak references. For example, this is the declaration for "wf1": extern ftype wf1; I.e., it is declared as a function. However, there is no .IMPORT emitted for wf1, or its aliases Wf1a, Wf1b or Wf1c. As a result, the assembler has no way of knowing whether the symbol is code or data. So, it ends up as a data symbol. Data Unsat 0 ..S... 3 0 wf1 This would seem to indicate that ASM_OUTPUT_EXTERNAL wasn't used for wf1. Failure to type assembler symbols correctly can often cause HP ld to dump core. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #18 from danglin at gcc dot gnu dot org 2005-12-10 22:38 --- Created an attachment (id=10449) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10449&action=view) Patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #19 from danglin at gcc dot gnu dot org 2005-12-10 22:41 --- Andrew, I had your patch in my tree for some time and haven't seen any adverse effects. Would you like to submit or install it as obvious? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #20 from pinskia at gcc dot gnu dot org 2005-12-10 23:02 --- (In reply to comment #19) > Andrew, I had your patch in my tree for some time and haven't seen any > adverse effects. Would you like to submit or install it as obvious? I will deal with it soon as I download the SVN version of gcc on my laptop (which just started to work again). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug c++/25342] New: internal compiler error: in lookup_member, at cp/search.c:1209
g++ asked me to submit this report. It crashed on the following piece of code:
template < typename eval >
struct tpl_seq_search {
typedef typename eval::enum_type Enum;
template < Enum first, Enum last >
struct range {
static void find () {
range::find();
}
};// range
template < Enum val >
struct range {
static void find () {}
};// range
}; // tpl_bin_search
template < typename eval, typename eval::enum_type first, typename
eval::enum_type last >
void
tpl_seq_search_from_to () {
return( tpl_seq_search::template range::find() );
}
struct xxx {
typedef int enum_type;
static enum_type const first = 0;
static enum_type const last = 20;
};
int main ( void ) {
tpl_seq_search_from_to();
}
gcc> /added/pkg/gcc-4.0.2/usr/bin/g++ bug_20051208_01.cc
bug_20051208_01.cc: In function 'void tpl_seq_search_from_to() [with eval =
xxx, typename eval::enum_type first = 0, typename eval::enum_type last = 20]':
bug_20051208_01.cc:39: instantiated from here
bug_20051208_01.cc:27: internal compiler error: in lookup_member, at
cp/search.c:1209
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
The specs are:
gcc> /added/pkg/gcc-4.0.2/usr/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure --prefix=/added/pkg/gcc-4.0.2/usr
Thread model: posix
gcc version 4.0.2
Best
Kai-Uwe Bux
--
Summary: internal compiler error: in lookup_member, at
cp/search.c:1209
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkherciueh at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25342
[Bug c++/25342] [3.4/4.0/4.1/4.2 Regression] internal compiler error: in lookup_member, at cp/search.c:1209
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-11 00:31 ---
Confirmed reduced testcase:
template < typename eval >
struct tpl_seq_search {
typedef typename eval::enum_type Enum;
template < Enum first, Enum last >
struct range {
};
template < Enum val >
struct range {
};
};
struct xxx {
typedef int enum_type;
tpl_seq_search::range<0, 1> a;
};
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||3.4.0 4.0.0 4.1.0 4.2.0
Known to work||3.3.3
Last reconfirmed|-00-00 00:00:00 |2005-12-11 00:31:42
date||
Summary| internal compiler error: in|[3.4/4.0/4.1/4.2 Regression]
|lookup_member, at |internal compiler error: in
|cp/search.c:1209|lookup_member, at
||cp/search.c:1209
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25342
[Bug fortran/25264] write to internal unit from the string itself gives wrong result ?
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-12-11 00:32 --- I have this beastie beat. The fix of the initial problem caused no less than 10 regressions (I estimate) and so I had to unmangle that. Talk about head spinning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25264
[Bug target/25343] New: [4.0 4.1 regression] testsuite failures
on m68k-linux, the following test cases did fail until 4.0 20051001, did not fail with 20051023, 2005, and start to fail with 20051201 again. No test results exist, where these test cases succeed on the 4.1 branch. +FAIL: gcc.c-torture/execute/ashldi-1.c execution, -O0 +FAIL: gcc.c-torture/execute/ashrdi-1.c execution, -O0 +FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O0 +FAIL: largefile.c -O0 -g (test for excess errors) +FAIL: largefile.c -O0 (test for excess errors) +FAIL: largefile.c -O1 (test for excess errors) +FAIL: largefile.c -O2 (test for excess errors) +FAIL: largefile.c -O3 -fomit-frame-pointer (test for excess errors) +FAIL: largefile.c -O3 -g (test for excess errors) +FAIL: largefile.c -Os (test for excess errors) config.log: largefile.c:1: fatal error: had to relocate PCH compilation terminated. compiler exited with status 1 output is: largefile.c:1: fatal error: had to relocate PCH compilation terminated. -- Summary: [4.0 4.1 regression] testsuite failures Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC host triplet: m68k-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25343
[Bug fortran/25068] [4.0/4.1] IOSTAT should be default integer when -std=f95
--- Comment #7 from kargl at gcc dot gnu dot org 2005-12-11 00:39 --- Subject: Bug 25068 Author: kargl Date: Sun Dec 11 00:39:14 2005 New Revision: 108371 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108371 Log: Fix testsuite after this commit: 2005-12-10 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/25068 * gfortran.dg/iostat_3.f90: New test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/g77/19981216-0.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25068
[Bug other/25345] New: redundant opcodes before function call.
static void *a0ra, *a1ra;
void __attribute__((noinline)) a0() { a0ra = __builtin_return_address(0); }
void __attribute__((noinline)) a1() { a1ra = __builtin_return_address(0); }
int foo() { a0(); a1(); return a1ra - a0ra; }
int main()
{
printf("pd=%d\n", foo());
return 0;
}
$ gcc -O3 --save-temps call.c && ./a.out
in theroy this code should return on vary platforms
the sizeof(call/bl [mem] opcode).
it works fine ix86 (pd=5), ppc (pd=4) but doesn't work on amd64 (pd=7 !!!)
in the assemler dump i see redundant `xor eax,eax`.
a1: movq(%rsp), %rax
movq%rax, a1ra(%rip)
ret
a0: movq(%rsp), %rax
movq%rax, a0ra(%rip)
ret
foo:xorl%eax, %eax <== what for?
calla0
xorl%eax, %eax <== what for?
calla1
movqa1ra(%rip), %rax
subla0ra(%rip), %eax
ret
--
Summary: redundant opcodes before function call.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: x86-64
GCC host triplet: x86-64
GCC target triplet: x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25345
[Bug other/25345] redundant opcodes before function call.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-11 04:03 --- "void a0()" does not mean "void a0(void)" in C but like "void a0(...)". -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25345
[Bug other/25345] redundant opcodes before function call.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 04:05 ---
I should note that doing:
static void *a0ra, *a1ra;
void __attribute__((noinline)) a0(void) { a0ra = __builtin_return_address(0); }
void __attribute__((noinline)) a1(void) { a1ra = __builtin_return_address(0); }
int foo(void) { a0(); a1(); return a1ra - a0ra; }
int main()
{
printf("pd=%d\n", foo());
return 0;
}
You get the code which you want.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25345
[Bug c++/25010] [4.1/4.2 regression] Segmentation fault (infinite recursion in cgraph_clone_inlined_nodes)
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-11 04:16 --- Subject: Bug 25010 Author: mmitchel Date: Sun Dec 11 04:16:32 2005 New Revision: 108375 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108375 Log: PR c++/25010 * ipa-inline.c (cgraph_clone_inlined_nodes): Do not assume that DECL_EXTERNAL functions have no bodies. Tidy. PR c++/25010 * g++.dg/opt/inline10.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/inline10.C Modified: trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25010
[Bug c++/25010] [4.1/4.2 regression] Segmentation fault (infinite recursion in cgraph_clone_inlined_nodes)
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-12-11 04:24 --- Subject: Bug 25010 Author: mmitchel Date: Sun Dec 11 04:24:42 2005 New Revision: 108376 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108376 Log: PR c++/25010 * ipa-inline.c (cgraph_clone_inlined_nodes): Do not assume that DECL_EXTERNAL functions have no bodies. Tidy. PR c++/25010 * g++.dg/opt/inline10.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/inline10.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/ipa-inline.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25010
[Bug c++/25010] [4.1/4.2 regression] Segmentation fault (infinite recursion in cgraph_clone_inlined_nodes)
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-12-11 04:24 --- Subject: Bug 25010 Author: mmitchel Date: Sun Dec 11 04:24:50 2005 New Revision: 108377 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108377 Log: PR c++/25010 * ipa-inline.c (cgraph_clone_inlined_nodes): Do not assume that DECL_EXTERNAL functions have no bodies. Tidy. PR c++/25010 * g++.dg/opt/inline10.C: New test. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25010
[Bug c++/25010] [4.1/4.2 regression] Segmentation fault (infinite recursion in cgraph_clone_inlined_nodes)
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-12-11 04:25 --- Fixed in GCC 4.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25010
[Bug c++/25337] [3.4/4.0/4.1/4.2 Regression]ICE with template processing
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25337
[Bug libobjc/25346] New: objc_sizeof_type does not handle _Bool at all
the following program fails:
#include
#include
struct a
{
_Bool t;
};
int main(void)
{
if (objc_sizeof_type(@encode(struct a)) != sizeof(struct a))
abort ();
}
--
Summary: objc_sizeof_type does not handle _Bool at all
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25346
[Bug libobjc/25346] objc_sizeof_type does not handle _Bool at all
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-11 05:19 --- I have a fix which I am testing right now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-11 05:19:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25346
[Bug c++/25342] [3.4/4.0/4.1/4.2 Regression] internal compiler error: in lookup_member, at cp/search.c:1209
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-12-11 05:47 --- Looking at it. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25342
[Bug libobjc/25346] objc_sizeof_type does not handle _Bool at all
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 06:28 --- Subject: Bug 25346 Author: pinskia Date: Sun Dec 11 06:28:35 2005 New Revision: 108378 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108378 Log: 2005-12-11 Andrew Pinski <[EMAIL PROTECTED]> PR libobjc/25346 * objc/objc-api.h (_C_BOOL): New define. * encoding.c (objc_sizeof_type): Handle _C_BOOL. (objc_alignof_type): Likewise. (objc_skip_typespec): Likewise. 2005-12-11 Andrew Pinski <[EMAIL PROTECTED]> PR libobjc/25346 * objc.dg/encode-7.m: New test. Added: trunk/gcc/testsuite/objc.dg/encode-7.m Modified: trunk/gcc/testsuite/ChangeLog trunk/libobjc/ChangeLog trunk/libobjc/encoding.c trunk/libobjc/objc/objc-api.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25346
[Bug libobjc/25346] objc_sizeof_type does not handle _Bool at all
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-11 06:30 --- Fixed in 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25346
[Bug libobjc/25347] New: objc_alignof_type gets the wrong alignment for unions (objc_sizeof_type is wrong also too)
testcase:
/* { dg-options "-fgnu-runtime" } */
/* { dg-do run } */
#include
#include
union f
{
char i;
double f1;
short t;
};
int main(void)
{
if (objc_sizeof_type (@encode (union f)) != sizeof(union f))
abort ();
if (objc_alignof_type (@encode (union f)) != __alignof__(union f))
abort ();
return 0;
}
--
Summary: objc_alignof_type gets the wrong alignment for unions
(objc_sizeof_type is wrong also too)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-darwin, powerpc-aix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25347
[Bug libobjc/25347] objc_alignof_type gets the wrong alignment for unions (objc_sizeof_type is wrong also too)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-11 06:35 --- Mine, testing a fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-11 06:35:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25347
[Bug libobjc/25347] objc_alignof_type gets the wrong alignment for unions (objc_sizeof_type is wrong also too)
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 06:59 --- Subject: Bug 25347 Author: pinskia Date: Sun Dec 11 06:59:12 2005 New Revision: 108379 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108379 Log: 2005-12-11 Andrew Pinski <[EMAIL PROTECTED]> PR libobjc/25347 * encoding.c (objc_sizeof_type): Don't handle _C_UNION_B special but use the struct layout functions. (objc_alignof_type): Likewise. (objc_layout_structure): Handle _C_UNION_B also. (objc_layout_structure_next_member): Likewise. (objc_layout_finish_structure): Likewise. 2005-12-11 Andrew Pinski <[EMAIL PROTECTED]> PR libobjc/25347 * objc.dg/encode-8.m: New test. Added: trunk/gcc/testsuite/objc.dg/encode-8.m Modified: trunk/gcc/testsuite/ChangeLog trunk/libobjc/ChangeLog trunk/libobjc/encoding.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25347
[Bug libobjc/25347] objc_alignof_type gets the wrong alignment for unions (objc_sizeof_type is wrong also too)
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-11 06:59 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25347
[Bug objc/25348] New: ICE encoding zero sized struct array
Testcase:
struct f
{
int i;
struct{} g[4];
int tt;
};
char *e = @encode(struct f);
--
Summary: ICE encoding zero sized struct array
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: x86-64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25348
[Bug objc/25348] ICE encoding zero sized struct array
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-11 07:39 --- Mine testing a fix (I will file a corresponding libobjc bug for objc_sizeof_type in the morning). Not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||2.95.3 3.0.4 4.0.0 4.1.0 ||4.2.0 3.3.3 3.2.3 3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-12-11 07:39:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25348
