[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #9 from matz at gcc dot gnu dot org 2007-05-21 07:45 --- Richard, the problem isn't the compare or where to store the live values alen and blen (FYI, the store looks invalid, because reload will not immediately stop when it sees an invalid asm insn, but instead just patch it out, but it will leave the operands in a funny state, hence the compare insn looks incorrect). The problem is the asm instruction itself, and it's actually the exact same bug as pr21291 , which was worked around by the outof-ssa change to coalesce both operand, which doesn't work anymore due to the change in forwprop. This could have happened also by some other random transformation, so forwprop isn't at fault. To recap, the problem goes like this: You start with int inout, orig; orig = inout; asm (: +mr (inout)); use (orig); which is transformed very early to use explicit output and match operands (this in fact is the source of all evil, as far as reloads capabilities are concerned): asm (: =mr (inout) : 0 (inout)); Now SSA form properly assigns a new SSA name for the output operand in the asm to inout, and some other transformation can now make use of the original SSA name of inout (in this case it's forwprop), so we have: asm (: =mr (inout_2) : 0 (inout_1)); use (inout_1); Clearly inout_2 and inout_1 can't be coalesced easily anymore, as they represent two separate values, so they will get different pseudo registers during expansion. Pseudos are okay, as we indeed would accept registers at all in the constraint. But still from there everything goes downhill: Both operands need to match per the constraints, but use different pseudo registers, so they don't match. The only solution (for reload) is to register a reload for these operands. But reloads can only be satisfied by hardregs, not by memory, so we need a register for this reload, just because we are presented with non-matching operands. So, even though we allow memory for this operand, no memory can be used for it, because both operand parts don't match. That together with the other necessary registers will get us over the total limit of 6 available registers in the end. So it's a symptom of reload not being able to use memory for reloads (secondary reloads don't come into play here), a long standing problem. Alternatively it's also a symptom of both operands not coming into reload as matching (in which case the pseudo could go to memory just fine, as the alternative allows it, and no reload would be necessary). Extending reload to make use of memory for some reloads, where allowed, might be nice, but is unrealistic in its gory detail (even the secondary mem support doesn't really help here). So I think the only feasible fix or work-around is to present reload with matching operands, where required. Strictly it's required only if the alternative allows registers and memory and both operands are different pseudo regs, all other cases can be handled by reload equally well. That might still be done in tree form (what the old outof-ssa hack still tries but can't really work), or in RTL form shortly before reload. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #1 from bonzini at gnu dot org 2007-05-21 08:19 --- I know what's going on :-) -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-05-20 21:26:42 |2007-05-21 08:19:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #2 from bonzini at gnu dot org 2007-05-21 08:21 --- Created an attachment (id=13593) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13593action=view) tentative patch? Please test this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #97 from jv244 at cam dot ac dot uk 2007-05-21 08:30 --- This morning's mainline gives a new ICE on the CVS version of CP2K (the file in question is not in the tarbal of comment #0) gfortran -c -O3 -ftree-vectorize -ffast-math -march=native semi_empirical_int_ana.f90 /scratch/vondele/clean/cp2k/src/../src/semi_empirical_int_ana.F: In function dterep_ana: /scratch/vondele/clean/cp2k/src/../src/semi_empirical_int_ana.F:2319: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [semi_empirical_int_ana.o] Error 1 -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #10 from ubizjak at gmail dot com 2007-05-21 08:33 --- Extending reload to make use of memory for some reloads, where allowed, might be nice, but is unrealistic in its gory detail (even the secondary mem support doesn't really help here). Should we XFAIL this test? -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn||19398 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #11 from bonzini at gnu dot org 2007-05-21 08:48 --- Micha, do you mean transforming (while expanding to RTL) asm (: =mr (inout_2) : 0 (inout_1)); to inout_2 = inout_1; asm (: =mr (inout_2) : 0 (inout_2)); ? That shouldn't be too hard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #12 from matz at gcc dot gnu dot org 2007-05-21 09:03 --- Exactly. If during expansion or at some other time before reload, doesn't matter that much. Of course there's a remote possibility that some RTL passes between expand and reload would do the copy propagation to counter that transformation. As inout_2 would have two writes this would require some data flow analysis in the RTL phase to determine that this copy-prop is valid. There's hope that this isn't done, so that nobody would destroy that work-around again :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug libstdc++/32017] Exception-safety bug
--- Comment #1 from pcarlini at suse dot de 2007-05-21 09:22 --- Ok, thanks, but this bug is already fixed. *** This bug has been marked as a duplicate of 25288 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug libstdc++/25288] std::list insert members should have no effects if an exception is thrown
--- Comment #6 from pcarlini at suse dot de 2007-05-21 09:22 --- *** Bug 32017 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||dave at boost-consulting dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25288
[Bug libstdc++/21772] exception safety testing allocator
--- Comment #3 from pcarlini at suse dot de 2007-05-21 09:26 --- Also see libstdc++/32017 for some additional details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #13 from bonzini at gnu dot org 2007-05-21 09:32 --- So we'd just be replacing a weak workaround with a stronger (but not definitive) workaround. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-05-21 09:41 --- Subject: Re: [4.3 regression] : gcc.target/i386/pr21291.c matz at gcc dot gnu dot org wrote: --- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 --- Yes. The place where I would think the work-around to become definitive is exactly before regclass. Between it and reload nothing interesting happens transformation wise. I was thinking of the same. Also, if the patch included adding a cfun-have_asm_statement flag set during RTL expansion, it would probably cost little to do it in an entirely new pass before regclass. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug c/11051] -Wno-deprecated needed also for C
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-21 09:54 --- This bug will be fixed as soon as Tom's patch goes in. *** This bug has been marked as a duplicate of 22168 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-21 09:54 --- *** Bug 11051 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c
--- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 --- Yes. The place where I would think the work-around to become definitive is exactly before regclass. Between it and reload nothing interesting happens transformation wise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-21 10:13 --- My patch for PR31867 fixes this in all its manifestations: see http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00961.html The amusing thing is that I was hurting for testcases for this latter PR:) It shows what a limited imagination is incapable of. Thanks, Elizabeth. Perhaps FX or Jerry, you could review the above patch? I will incorporate Elizabeth and FX's examples into the PR31867 testscase. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||31867 AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-05-20 15:43:41 |2007-05-21 10:13:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug testsuite/32014] new gcc failures
--- Comment #1 from irar at il dot ibm dot com 2007-05-21 10:43 --- On PowerPC revision 124785 from May 17 we get: FAIL: gcc.dg/vect/vect-64.c (internal compiler error) FAIL: gcc.dg/vect/vect-64.c (test for excess errors) WARNING: gcc.dg/vect/vect-64.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-68.c (internal compiler error) FAIL: gcc.dg/vect/vect-68.c (test for excess errors) WARNING: gcc.dg/vect/vect-68.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-70.c (internal compiler error) FAIL: gcc.dg/vect/vect-70.c (test for excess errors) WARNING: gcc.dg/vect/vect-70.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times vectorized 1 loops 1 Revision 124739 from May 15 works fine. On today's snapshot (124895) we also see XPASS: gcc.dg/vect/vect-iv-4.c scan-tree-dump-times vectorized 1 loops 1 in addition to the above failures. Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug testsuite/32014] new gcc failures
--- Comment #2 from dominiq at lps dot ens dot fr 2007-05-21 10:58 --- vect-intfloat-conversion-4b.c is four days old, but the other tests seem pretty old so the failures are regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug libstdc++/31621] libstdc++ uses -xc++ which can cause exceptions to show up which causes __gxx_personality_v0 to be referenced
--- Comment #3 from paolo at gcc dot gnu dot org 2007-05-21 11:26 --- Subject: Bug 31621 Author: paolo Date: Mon May 21 10:25:52 2007 New Revision: 124896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124896 Log: 2007-05-21 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31621 * acinclude.m4 ([GLIBCXX_CHECK_LINKER_FEATURES]): Use the C compiler. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31621
[Bug libstdc++/31621] libstdc++ uses -xc++ which can cause exceptions to show up which causes __gxx_personality_v0 to be referenced
--- Comment #4 from paolo at gcc dot gnu dot org 2007-05-21 11:27 --- Subject: Bug 31621 Author: paolo Date: Mon May 21 10:26:49 2007 New Revision: 124897 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124897 Log: 2007-05-21 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31621 * acinclude.m4 ([GLIBCXX_CHECK_LINKER_FEATURES]): Use the C compiler. * configure: Regenerate. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_2-branch/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31621
[Bug libstdc++/31621] libstdc++ uses -xc++ which can cause exceptions to show up which causes __gxx_personality_v0 to be referenced
--- Comment #5 from pcarlini at suse dot de 2007-05-21 11:27 --- Fixed for 4.2.1. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31621
[Bug target/31167] ICE wnen using __int128_t on x86_64
--- Comment #8 from uros at gcc dot gnu dot org 2007-05-21 12:31 --- Subject: Bug 31167 Author: uros Date: Mon May 21 11:31:14 2007 New Revision: 124900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124900 Log: PR target/31167 Backport from mainline. * config/i386/i386.md (*addti3_1, *addti3_1 splitter): Use x86_64_general_operand as operand[2] predicate. Remove iF from operand constraints and use e constraint instead. (*subti3_1, *subti3_1 splitter): Ditto. (*negti2_1, *negti2_1 splitter): Use nonimmediate_operand as operand[1] predicate. PR target/30041 Backport from mainline. * config/i386/sse.md (*sse3_movddup): Use operands[0] and operands[1] in insn constraint. Correct type attribute to sselog1. testsuite/ChangeLog Backport from mainline. * gcc.target/i386/pr31167.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr31167.c - copied unchanged from r122945, trunk/gcc/testsuite/gcc.target/i386/pr31167.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/i386.md branches/gcc-4_2-branch/gcc/config/i386/sse.md branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
[Bug target/30041] FAIL: gcc.target/i386/sse3-movddup.c (internal compiler error)
--- Comment #6 from uros at gcc dot gnu dot org 2007-05-21 12:31 --- Subject: Bug 30041 Author: uros Date: Mon May 21 11:31:14 2007 New Revision: 124900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124900 Log: PR target/31167 Backport from mainline. * config/i386/i386.md (*addti3_1, *addti3_1 splitter): Use x86_64_general_operand as operand[2] predicate. Remove iF from operand constraints and use e constraint instead. (*subti3_1, *subti3_1 splitter): Ditto. (*negti2_1, *negti2_1 splitter): Use nonimmediate_operand as operand[1] predicate. PR target/30041 Backport from mainline. * config/i386/sse.md (*sse3_movddup): Use operands[0] and operands[1] in insn constraint. Correct type attribute to sselog1. testsuite/ChangeLog Backport from mainline. * gcc.target/i386/pr31167.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr31167.c - copied unchanged from r122945, trunk/gcc/testsuite/gcc.target/i386/pr31167.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/i386.md branches/gcc-4_2-branch/gcc/config/i386/sse.md branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30041
[Bug middle-end/32018] New: ICE on optimization
Attached code from CP2K crashes f951 on i686-pc-linux-gnu if these flags
FCFLAGS=-c -O2 -ftree-vectorize -msse2
are specified. All of them are necessary, omitting any will avoid the segfault.
The crash seems to be related to the length of the subroutine. Further reducing
the number of initializations avoid the segfault as well.
(gdb) run -O2 -ftree-vectorize -msse2 periodic_table.f90
Starting program:
/h/franke/packages/i686-pc-linux-gnu/gcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951
-O2 -ftree-vectorize -msse2 periodic_table.f90
init_periodic_table
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inline static-var pure-const
type-escape-varAssembling functions:
init_periodic_table {GC 5333k -
Program received signal SIGSEGV, Segmentation fault.
0x080f7413 in ggc_set_mark (p=0xa5a5a5a5) at
../../../svn/gcc/gcc/ggc-page.c:605
605 return base[L1][L2];
(gdb) bt
#0 0x080f7413 in ggc_set_mark (p=0xa5a5a5a5) at
../../../svn/gcc/gcc/ggc-page.c:605
#1 0x08253d98 in gt_ggc_mx_loop (x_p=0xb7ac5c94) at gtype-desc.c:302
#2 0x08253e00 in gt_ggc_mx_loop (x_p=0xb78d32e0) at gtype-desc.c:311
#3 0x08253de2 in gt_ggc_mx_loop (x_p=0xb7a9d114) at gtype-desc.c:309
#4 0x08253c83 in gt_ggc_mx_basic_block_def (x_p=0xb7a99ca8) at
gtype-desc.c:825
#5 0x08253d19 in gt_ggc_mx_tree_ann_d (x_p=0xb7bc8b2c) at gtype-desc.c:703
#6 0x080b14bf in gt_ggc_mx_lang_tree_node (x_p=0xb7dbfac4) at
./gt-fortran-f95-lang.h:358
#7 0x0824c99e in gt_ggc_mx_cgraph_edge (x_p=0xb7c09c98) at gtype-desc.c:159
#8 0x0824c98f in gt_ggc_mx_cgraph_edge (x_p=0xb7c09ccc) at gtype-desc.c:158
#9 0x0824c81c in gt_ggc_mx_cgraph_node (x_p=0xb7d5e780) at gtype-desc.c:183
#10 0x0824ca8f in gt_ggc_m_P11cgraph_node4htab (x_p=0xb7dc2a14) at
gtype-desc.c:1931
#11 0x0822bf09 in ggc_mark_roots () at ../../../svn/gcc/gcc/ggc-common.c:118
#12 0x080f7e38 in ggc_collect () at ../../../svn/gcc/gcc/ggc-page.c:1906
#13 0x0828112a in execute_one_pass (pass=0x87af720) at
../../../svn/gcc/gcc/passes.c:1087
#14 0x082812af in execute_pass_list (pass=0x87af720) at
../../../svn/gcc/gcc/passes.c:1117
#15 0x082812c2 in execute_pass_list (pass=0x87af620) at
../../../svn/gcc/gcc/passes.c:1118
#16 0x082812c2 in execute_pass_list (pass=0x87aee60) at
../../../svn/gcc/gcc/passes.c:1118
#17 0x08359f4c in tree_rest_of_compilation (fndecl=0xb7d5e680) at
../../../svn/gcc/gcc/tree-optimize.c:406
#18 0x084b3cf0 in cgraph_expand_function (node=0xb7d5e780) at
../../../svn/gcc/gcc/cgraphunit.c:1086
#19 0x084b6415 in cgraph_optimize () at ../../../svn/gcc/gcc/cgraphunit.c:1155
#20 0x080aeacc in gfc_be_parse_file (set_yydebug=0) at
../../../svn/gcc/gcc/fortran/f95-lang.c:307
#21 0x083004a8 in toplev_main (argc=5, argv=0xbf88fe24) at
../../../svn/gcc/gcc/toplev.c:1051
#22 0x080f263f in main (argc=Cannot access memory at address 0xc
) at ../../../svn/gcc/gcc/main.c:35
Valgrind:
init_periodic_table
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inline static-var pure-const
type-escape-varAssembling functions:
init_periodic_table {GC 5333k - ==22375== Invalid read of size 4
==22375==at 0x80F7413: ggc_set_mark (ggc-page.c:605)
==22375== Address 0x2968 is not stack'd, malloc'd or (recently) free'd
--
Summary: ICE on optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
[Bug middle-end/32018] ICE on optimization
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-05-21 12:33 --- Created an attachment (id=13594) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13594action=view) Described test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #98 from dfranke at gcc dot gnu dot org 2007-05-21 12:38 --- Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64 equivalent and got the ICE described in PR32018. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/32018] ICE on optimization
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-21 12:56:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-21 13:04 --- Sorry about the bad news, but I still have the very same failure with the patch: # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. /bin/sh ../../../gcc-4.3-20070519/libgcc/../mkinstalldirs . /sw/src/fink.build/gcc4-4.3.0-20070519/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.3.0-20070519/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin7/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin7/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin7/include -isystem /sw/lib/gcc4/powerpc-apple-darwin7/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib -nodefaultlibs -install_name /sw/lib/gcc4/lib/libgcc_s`if test . = ppc64 ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 -current_version 1.0 -g -O2 -mdynamic-no-pic -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o darwin-fallback_s.o emutls_s.o -lc /sw/lib/odcctools/bin/ld: warning -dylib_install_name /sw/lib/gcc4/lib/libgcc_s.1.dylib not found in segment address table LD_SEG_ADDR_TABLE /sw/var/lib/fink/prebound/seg_addr_table /sw/lib/odcctools/bin/ld: _enable_execute_stack_s.o has local relocation entries in non-writable section (__TEXT,__text) collect2: ld returned 1 exit status make[3]: *** [libgcc_s.dylib] Error 1 make[2]: *** [all-stage2-target-libgcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 Apparently '-mdynamic-no-pic' is hiding somewhere it is not expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug fortran/31930] [4.1/4.2 only] bes[jy]n intrinsics do not follow definition of elemental functions
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-21 13:05 --- Daniel cleared this one on trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31930
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #4 from andreast at gcc dot gnu dot org 2007-05-21 13:06 --- Nope. It clinches somehow with this one: config/mh-ppc-darwin. Here the BOOT_CFLAGS is set to -g -O2 -mdynamic-no-pic. In the libgcc Makefile.in I see that MULTILIB_CFLAGS is set to CFLAGS + extra stuff. CFLAGS itself is BOOT_CFLAGS, so the -mdynamic-no-pic in a shared lib :) I'll see if I understand a bit more later. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug testsuite/32014] new gcc failures
--- Comment #3 from ubizjak at gmail dot com 2007-05-21 13:06 --- (In reply to comment #1) FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times vectorized 1 loops 1 These are new test files, and either relevant conversion optabs should be added for ppc, or xfail for these test needs to be adjusted. Please look to PR tree-optimization/24695, Comment #14. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug c++/32019] New: Condition operator ?: and ambiguous convertions
The following program should not compile (without warnings) on two counts, but
in fact only fails on one, and not for the right reason, as far as I can see.
class C
{
public:
C(const char *);
operator const char *();
};
void
foo (bool b)
{
// Prove that the implicit convertions work both ways.
C c = 1;
const char * s = C(2);
// This is ambiguous; both operands may be converted to the other's type.
// However, the compiler accepts it without a diagnostic.
b ? 1 : C(2);
// This is basically the same as the previous statement, but it fails with
// the error operands to ?: have different types.
b ? c : s;
}
Both conditional operators should fall foul of clause 5.16, paragraph 3, of the
C++ standard. The last two operands are of different types, and each may be
implicitly converted to the opposite, as demonstrated by the assignments above.
The second conditional operator looks like a different way of writing the
first, but fails with an error stating that the operands have different types.
They do have different types, but again, the conversions should apply just the
same.
If I alter the program to use a type other than const char * (such as int, or
another class type) then I get different results again, which is surprising.
--
Summary: Condition operator ?: and ambiguous convertions
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32019
[Bug testsuite/32014] new gcc failures
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-21 13:15 --- Please look to PR tree-optimization/24695 Are you sure about the number? PR24695 is [csl-arm-branch] Bootstrap failure with current csl-arm-branch and has only three comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug c++/32020] New: Invalid template error on non-dependent name
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++ EE 2005.
Here is the source code:
class template_function
{
public:
template int N
int func()
{
return N;
};
};
class non_template_class
{
public:
template_function tf;
void run()
{
tf.func36(); // SUCCESS
}
};
// The PointLess template parameter makes gcc
// fail to see that tf is a non-dependent name
template int PonitLess
class template_class
{
public:
template_function tf;
void run()
{
tf.func42(); // FAIL
}
};
int main()
{
non_template_class ntc;
ntc.run();
template_class0 tc;
tc.run();
return 0;
}
Here is the output of G++:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/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
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/cpp0 -lang-c++ -D__GNUG__=3
-D__DEPRECATED -D__EXCEPTIONS -v -D__GNUC__=3 -D__GNUC_MINOR__=2
-D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix
-D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__
-D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1
-D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__
-D__tune_i386__ main.cpp -Wall main.ii
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (cpplib) (i386
Linux/ELF)
ignoring nonexistent directory /usr/i386-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/3.2.3
/usr/include/c++/3.2.3/i386-redhat-linux
/usr/include/c++/3.2.3/backward
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -Wall -version -o main.s
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (cpplib) (i386
Linux/ELF)
GNU C++ version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (i386-redhat-linux)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-34).
main.cpp: In member function `void template_classPonitLess::run()':
main.cpp:34: syntax error before `;' token
And here is the main.ii file:
# 1 main.cpp
# 1 built-in
# 1 command line
# 1 main.cpp
class template_function
{
public:
template int N
int func()
{
return N;
};
};
class non_template_class
{
public:
template_function tf;
void run()
{
tf.func36();
}
};
template int PonitLess
class template_class
{
public:
template_function tf;
void run()
{
tf.func42();
}
};
int main()
{
non_template_class ntc;
ntc.run();
template_class0 tc;
tc.run();
return 0;
}
--
Summary: Invalid template error on non-dependent name
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trundeg at hotmail dot com
GCC host triplet: Linux cfr1ll19 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55
EDT 200
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
[Bug testsuite/32014] new gcc failures
--- Comment #5 from ubizjak at gmail dot com 2007-05-21 14:01 --- (In reply to comment #4) Please look to PR tree-optimization/24695 Are you sure about the number? PR24695 is Oops, PR24659. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug fortran/31867] function result with character LEN computed at run time
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-21 14:16 --- Subject: Bug 31867 Author: pault Date: Mon May 21 13:16:06 2007 New Revision: 124903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124903 Log: 2007-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/31867 PR fortran/31994 * trans-array.c (gfc_conv_expr_descriptor): Obtain the stored offset for non-descriptor, source arrays and correct for stride not equal to one before writing to field of output descriptor. 2007-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/31867 * gfortran.dg/char_length_5.f90: New test. PR fortran/31994 * gfortran.dg/array_reference_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_reference_1.f90 trunk/gcc/testsuite/gfortran.dg/char_length_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-21 14:16 --- Subject: Bug 31994 Author: pault Date: Mon May 21 13:16:06 2007 New Revision: 124903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124903 Log: 2007-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/31867 PR fortran/31994 * trans-array.c (gfc_conv_expr_descriptor): Obtain the stored offset for non-descriptor, source arrays and correct for stride not equal to one before writing to field of output descriptor. 2007-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/31867 * gfortran.dg/char_length_5.f90: New test. PR fortran/31994 * gfortran.dg/array_reference_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_reference_1.f90 trunk/gcc/testsuite/gfortran.dg/char_length_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug fortran/31867] [4.2 only] function result with character LEN computed at run time
--- Comment #12 from pault at gcc dot gnu dot org 2007-05-21 14:18 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Summary|function result with|[4.2 only] function result |character LEN computed at |with character LEN computed |run time|at run time http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.
--- Comment #10 from pault at gcc dot gnu dot org 2007-05-21 14:21 --- Fixed on trunk. The patch will be backported to 4.2, as soon as the dust has settled on trunk and 4.2 is open again. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug libstdc++/32017] Exception-safety bug
--- Comment #2 from dave at boost-consulting dot com 2007-05-21 14:25 --- I won't push the subject any further, but again, if you don't adopt the tests mentioned in the threads cited above, you will almost certainly have further exception safety bugs lurking. Howard Hinnant can verify that this test works as he used it to validate the MSL. -- dave at boost-consulting dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug c++/32020] Invalid template error on non-dependent name
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 14:27 --- GCC 3.2 is no longer maintained. This works with the new C++ parser that went in for GCC 3.4.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
[Bug fortran/32021] New: Fix,document,remove GFORTRAN_* environment variables
The following environment variables exist in gfortran (inherited from g95, cf.
http://ftp.g95.org/G95Manual.pdf). They are not documented and don't seem to
work, however they are partially implemented.
GFORTRAN_FPU_PRECISION can probably be removed (cf. -mpc32, -mpc64 and -mpc80)
GFORTRAN_MEM_INIT sounds something which should be handled by the front end (w/
a flag) for speed reasons. (cf. -finit-local-zero, PR20441).
Similar for GFORTRAN_MEM_CHECK.
GFORTRAN_SIG* could be implemented, if someone needs it. (can be done via the
signal vendor intrinsic).
GFORTRAN_FPU_ROUND etc. could be handled by the Fortran 2003 IEEE rounding
modes - or is this environment variable needed?
--- gfortran.texi (Revision 124895)
+++ gfortran.texi (Arbeitskopie)
@@ -604,6 +612,51 @@
when @command{a.out} is the compiled Fortran program that you want to run.
Default is a single space.
[EMAIL PROTECTED] GFORTRAN_MEM_INIT
[EMAIL PROTECTED] @env{GFORTRAN_MEM_INIT}---Default initialization of allocated
memory
+
+This environment variable specifies how allocated memory is initialized.
+Default value is @samp{NONE} for no initialization (faster); other options
+are @samp{NAN} for not-a-number with mantissa @samp{0x40f95} or
+a custom hexadecimal value.
+
[EMAIL PROTECTED] GFORTRAN_MEM_CHECK
[EMAIL PROTECTED] @env{GFORTRAN_MEM_CHECK}---Default initialization of
allocated memory
+
+If the first letter is @samp{y}, @samp{Y} or @samp{1}, memory which is still
+allocated when the program ends is reported; it is not reported if the first
+letter is @samp{n}, @samp{N} or @samp{0}. Default is not to report.
+
[EMAIL PROTECTED] GFORTRAN_SIGHUP
[EMAIL PROTECTED] @env{GFORTRAN_SIGHUP}---Behavior on SIGHUP
+
+When the @env{GFORTRAN_SIGHUP} variable is set to @samp{IGNORE}, the signal
+SIGHUP is ignored. It it is set to @samp{ABORT}, the program aborts.
+Default is to abort.
+
[EMAIL PROTECTED] GFORTRAN_SIGINT
[EMAIL PROTECTED] @env{GFORTRAN_SIGINT}---Behavior on SIGINT
+
+When the @env{GFORTRAN_SIGINT} variable is set to @samp{IGNORE}, the signal
+SIGINT is ignored. It it is set to @samp{ABORT}, the program aborts.
+Default is to abort.
+
[EMAIL PROTECTED] GFORTRAN_FPU_ROUND
[EMAIL PROTECTED] @env{GFORTRAN_FPU_ROUND}---Floating point rounding
+
+The @env{GFORTRAN_FPU_ROUND} variable specifies the floating point
+rounding. Possible values are: to round to the @samp{NEAREST}
+integer, to always round @samp{UP}, to always round @samp{DOWN},
+or to round always towards @samp{ZERO}. Default is to round
+to the nearest integer.
+
[EMAIL PROTECTED] GFORTRAN_FPU_PRECISION
[EMAIL PROTECTED] @env{GFORTRAN_FPU_PRECISION}---Precision of intermediate
results
+
+The @env{GFORTRAN_FPU_PRECISION} variable specifies the precision
+of intermediate results. Possible values are
[EMAIL PROTECTED], @samp{53} and @samp{64}. Default is @samp{64}.
+
@node GFORTRAN_CONVERT_UNIT
@section @env{GFORTRAN_CONVERT_UNIT}---Set endianness for unformatted I/O
--
Summary: Fix,document,remove GFORTRAN_* environment variables
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32021
[Bug fortran/32021] Fix,document,remove GFORTRAN_* environment variables
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-21 14:29 --- For GFORTRAN_SIG* one could also add an option to backtrace/dump in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32021
[Bug c++/32022] New: Invalid template error on non-dependent name
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++ EE 2005.
Here is the source code:
class template_function
{
public:
template int N
int func()
{
return N;
};
};
class non_template_class
{
public:
template_function tf;
void run()
{
tf.func36(); // SUCCESS
}
};
// The PointLess template parameter makes gcc
// fail to see that tf is a non-dependent name
template int PonitLess
class template_class
{
public:
template_function tf;
void run()
{
tf.func42(); // FAIL
}
};
int main()
{
non_template_class ntc;
ntc.run();
template_class0 tc;
tc.run();
return 0;
}
Here is the output of G++:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/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
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/cpp0 -lang-c++ -D__GNUG__=3
-D__DEPRECATED -D__EXCEPTIONS -v -D__GNUC__=3 -D__GNUC_MINOR__=2
-D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix
-D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__
-D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1
-D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__
-D__tune_i386__ main.cpp -Wall main.ii
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (cpplib) (i386
Linux/ELF)
ignoring nonexistent directory /usr/i386-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/3.2.3
/usr/include/c++/3.2.3/i386-redhat-linux
/usr/include/c++/3.2.3/backward
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -Wall -version -o main.s
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (cpplib) (i386
Linux/ELF)
GNU C++ version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) (i386-redhat-linux)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-34).
main.cpp: In member function `void template_classPonitLess::run()':
main.cpp:34: syntax error before `;' token
And here is the main.ii file:
# 1 main.cpp
# 1 built-in
# 1 command line
# 1 main.cpp
class template_function
{
public:
template int N
int func()
{
return N;
};
};
class non_template_class
{
public:
template_function tf;
void run()
{
tf.func36();
}
};
template int PonitLess
class template_class
{
public:
template_function tf;
void run()
{
tf.func42();
}
};
int main()
{
non_template_class ntc;
ntc.run();
template_class0 tc;
tc.run();
return 0;
}
--
Summary: Invalid template error on non-dependent name
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trundeg at hotmail dot com
GCC host triplet: Linux cfr1ll19 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55
EDT 200
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32022
[Bug libstdc++/25288] std::list insert members should have no effects if an exception is thrown
--- Comment #7 from pcarlini at suse dot de 2007-05-21 15:00 --- *** Bug 32017 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25288
[Bug libstdc++/32017] Exception-safety bug
--- Comment #3 from pcarlini at suse dot de 2007-05-21 15:00 --- This specific bug is already fixed and must be marked as duplicate. Then we have 21772, more general. We know what we are doing, thanks. *** This bug has been marked as a duplicate of 25288 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug fortran/30964] optional arguments to random_seed
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:21 --- Created an attachment (id=13595) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13595action=view) Patch for that issue; not tested yet -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug fortran/31198] wrong code: Max() with optional arguments
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:25 --- Scanning the F2003 standard, MIN/MAX are the only intrinsics with a variable number of arguments. They probably need special handling. -- 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 Last reconfirmed|2007-03-16 13:42:06 |2007-05-21 15:25:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug c/32023] New: Invalid lvalue in void* increment error inconsitensy
The following program doesn't compile due to invalid lvalue in increment. The
most strange thing is that gcc somehow ignores type coercion
int main ()
{
int **a;
void **b;
*b++;/* works fine */
*((void **)a)++; / gives error */
return 0;
}
--
Summary: Invalid lvalue in void* increment error inconsitensy
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nshmyrev at yandex dot ru
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #16 from hjl at lucon dot org 2007-05-21 15:33 ---
Gcc 4.1/4.2/4.3 will fail and gcc 3.4 has no problem:
---
typedef unsigned long bngdigit;
typedef bngdigit *bng;
typedef unsigned int bngcarry;
typedef unsigned long bngsize;
bngdigit
bng_ia32_mult_sub_digit (bng a, bngsize alen, bng b, bngsize blen, bngdigit d)
{
bngdigit out, tmp;
bngcarry carry;
bngdigit a11;
int x = blen;
out = 0;
asm (
: +r (a), +r (b), +mr (blen), +mr (out), =r (tmp)
: mr (d)
: eax, edx);
if (alen == blen)
{
a11 = out;
goto t;
}
if (x == 0)
goto t;
a11 = 1;
t:
return a11;
}
---
--
hjl at lucon dot org changed:
What|Removed |Added
Summary|[4.3 regression] : |[4.1/4.2/4.3 regression] :
|gcc.target/i386/pr21291.c |can't find a register in
||class 'GENERAL_REGS' while
||reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #99 from jv244 at cam dot ac dot uk 2007-05-21 15:40 --- (In reply to comment #98) Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64 equivalent and got the ICE described in PR32018. thanks for adding this PR. Looking at PR32018, I notice that the segfault you've observed is actually in a different subroutine (file) than what I reported above (based on a run on an opteron). The file you've extracted compiles fine here. It could still be the same issue though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c++/32022] Invalid template error on non-dependent name
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 --- *** This bug has been marked as a duplicate of 32020 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32022
[Bug c++/32020] Invalid template error on non-dependent name
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 --- *** Bug 32022 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
[Bug c++/32020] Invalid template error on non-dependent name
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |3.4.0 Version|unknown |3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
[Bug bootstrap/29382] Bootstrap comparison failure!
--- Comment #3 from tru at pasteur dot fr 2007-05-21 15:43 --- [EMAIL PROTECTED] ~]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/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 --host=i386-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-58) [EMAIL PROTECTED] ~]$ rpm -q gcc gcc-3.2.3-58.i386 is failing too, but a plain gcc-3.4.6 can bootstrap gcc-4.2.0 -- tru at pasteur dot fr changed: What|Removed |Added CC||tru at pasteur dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382
[Bug c/32023] Invalid lvalue in void* increment error inconsitensy
--- Comment #1 from schwab at suse dot de 2007-05-21 15:45 --- A cast is not an lvalue. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
[Bug libstdc++/32017] consistent exception-safety container testing
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:57 --- Dave, just to clarify, this is bug 21772. We're working on it. ;) -benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Summary|Exception-safety bug|consistent exception-safety ||container testing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #100 from jv244 at cam dot ac dot uk 2007-05-21 15:58 ---
(In reply to comment #99)
(In reply to comment #98)
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
thanks for adding this PR.
Looking at PR32018, I notice that the segfault you've observed is actually in
a
different subroutine (file) than what I reported above (based on a run on an
opteron). The file you've extracted compiles fine here. It could still be the
same issue though.
might be a different issue, the trace I see here is :
(gdb) run -O3 -ftree-vectorize -ffast-math -march=opteron
semi_empirical_int_ana.f90
Starting program:
/scratch/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951
-O3 -ftree-vectorize -ffast-math -march=opteron semi_empirical_int_ana.f90
check_dterep_ana dterep_ana rotint_ana {GC 8106k - 5800k} dtaper_ana
dnucint_ana check_dnucint_ana invert_derivative invert_integral rotnuc_ana {GC
8112k - 7433k}
Analyzing compilation unit
{GC 10372k - 9175k}Performing interprocedural optimizations
visibility early_local_cleanups {GC 14010k - 13275k} inline
static-var pure-const type-escape-varAssembling functions:
dtaper_ana invert_integral invert_derivative check_dnucint_ana dnucint_ana {GC
17386k - 12699k} rotnuc_ana {GC 16571k - 13382k} dterep_ana {GC 17536k -
11295k}
Program received signal SIGSEGV, Segmentation fault.
verify_ssa_name (ssa_name=0xa5a5a5a5a5a5a5a5, is_virtual=0 '\0') at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:109
109 if (TREE_CODE (ssa_name) != SSA_NAME)
(gdb) bt
#0 verify_ssa_name (ssa_name=0xa5a5a5a5a5a5a5a5, is_virtual=0 '\0') at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:109
#1 0x00784305 in verify_ssa (check_modified_stmt=1 '\001') at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:716
#2 0x006082d5 in execute_function_todo (data=Variable data is not
available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:918
#3 0x0060803b in execute_todo (flags=Variable flags is not
available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:942
#4 0x0060851a in execute_one_pass (pass=0xcc4b80) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1087
#5 0x0060867c in execute_pass_list (pass=0xcc4b80) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1117
#6 0x0060868e in execute_pass_list (pass=0xcc4160) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1118
#7 0x0060868e in execute_pass_list (pass=0xcc3fe0) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1118
#8 0x0060868e in execute_pass_list (pass=0xcc3440) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1118
#9 0x006d2378 in tree_rest_of_compilation (fndecl=0x2a95b3ca00) at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:406
#10 0x0080ff50 in cgraph_expand_function (node=0x2a95c34700) at
/scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1086
#11 0x008123f2 in cgraph_optimize () at
/scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1155
#12 0x00465ebd in gfc_be_parse_file (set_yydebug=Variable set_yydebug
is not available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:307
#13 0x006818e4 in toplev_main (argc=Variable argc is not available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/toplev.c:1051
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug libstdc++/21772] exception safety testing allocator
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:58 --- This is now integrated, but the tests are still ad-hoc. We need a more consistent application of eh-safety tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug bootstrap/32024] New: ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
The bootstrap hardly runs for a few minutes and then I get an ICE. Screen output: ... make[3]: Leaving directory `/opt/gcc-4_3-build/gcc' mkdir -p -- i686-pc-linux-gnu/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in i686-pc-linux-gnu/libgcc configure: creating cache ./config.cache ... checking whether decimal floating point is supported... yes checking for __attribute__((visibility(hidden)))... yes updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: executing default commands make[3]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libgcc' # If this is the top-level multilib, build all the other # multilibs. /opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/root/downloads/gcc-4_3-trunk/libgcc -I/root/downloads/gcc-4_3-trunk/libgcc/. -I/root/downloads/gcc-4_3-trunk/libgcc/../gcc -I/root/downloads/gcc-4_3-trunk/libgcc/../include -I/root/downloads/gcc-4_3-trunk/libgcc/../libdecnumber/bid -I/root/downloads/gcc-4_3-trunk/libgcc/../libdecnumber -I../../libdecnumber -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3': /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_muldi3.o] Error 1 make[3]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/opt/gcc-4_3-build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/opt/gcc-4_3-build' make: *** [all] Error 2 # gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.3.0 20070521 (experimental) The _exact_ same ./configure commands work on gcc 4.2.0/1 (last few weeks). I have saved a make screen output log (and the whole build directory). No rush, I'll play with 4.2.1 while I wait to see if this clears up. -- Summary: ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|bootstrap |middle-end Keywords||build, ice-checking, ice-on- ||valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug libgomp/32013] Use posix95 for libgomp on Irix 6.2
--- Comment #3 from gcc-tgc at jupiterrise dot com 2007-05-21 16:19 --- (In reply to comment #2) patches get sent to gcc-patches@, make sure you read http://gcc.gnu.org/contribute.html also. I noticed and I just did. Perhaps I should have started there ;) I haven't signed any FSF paperwork and have no intention of doing so either. I don't think the patch constitutes a major contribution so no paperwork needed? The patch was tested, test results are here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01003.html A suitable ChangeLog entry I think could look like this: PR libgomp/32013 * configure.tgt: mips-sgi-irix6.2 must use posix95 locking primitives -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32013
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #18 from patchapp at dberlin dot org 2007-05-21 16:25 --- Subject: Bug number PR18923 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01264.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug testsuite/32014] new gcc failures
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-21 16:25 --- FAIL: gcc.dg/vect/vect-64.c (internal compiler error) I think the all of the ICEs were due to: 2007-05-16 Eric Christopher [EMAIL PROTECTED] * config/rs6000/rs6000.c (rs6000_emit_prologue): Move altivec register saving after stack push. Set sp_offset whenever we push. (rs6000_emit_epilogue): Move altivec register restore before stack push. The vect-intfloat-conversion-4?.c testcases should just be xfailed until implemented for ppc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug c++/32025] New: left bitshift is broken with 128-bit TIMode
With gcc 4.0.x, left bitshift on 128-bit TIMode doesn't seem to be working properly. For example, using the attached code and compiled under 4.0.4, I initialize a 128-bit TIMode variable called mask to 1U, left-shift it by the entered number of bits and compute 0U-mask, while printing the contents of that 128-bit variable in hex at each step. The code compiled with gcc 4.0.4 produced the following: ./test_128_404 Enter the number of bits for left shift: 8 mask initialized to 1U: 0001 After the left shift by 8 bits: 0100 0U-mask=ff00 On the very same box compiled with gcc 3.4.6: ./test_128_346 Enter the number of bits for left shift: 8 mask initialized to 1U: 0001 After the left shift by 8 bits: 0100 0U-mask= ff00 Compiling under gcc 4.1.1 gets the same results as 3.4.6, i.e., it appears that only 4.0.x compilers are broken. This is 100% reproducible - I got identical results on several different boxes with different variants of Fedora/CentOS and gcc 4.0.2 and 4.0.4, all AMD boxes though. For the record, here is my OS data: uname -a Linux Centos4.roundbox.com 2.6.9-42.0.3.ELsmp #1 SMP Fri Oct 6 06:28:26 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : Dual Core AMD Opteron(tm) Processor 175 stepping: 2 cpu MHz : 1809.293 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext lm 3dnowext 3 dnow pni bogomips: 3622.46 TLB size: 1088 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : Dual Core AMD Opteron(tm) Processor 175 stepping: 2 cpu MHz : 1809.293 cache size : 1024 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext lm 3dnowext 3 dnow pni bogomips: 3622.46 TLB size: 1088 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp -- Summary: left bitshift is broken with 128-bit TIMode Product: gcc Version: 4.0.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igor at roundbox dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
[Bug c++/32025] left bitshift is broken with 128-bit TIMode
--- Comment #1 from igor at roundbox dot com 2007-05-21 16:45 --- Created an attachment (id=13596) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13596action=view) Simple test code to reproduce the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
[Bug libstdc++/31970] set::iterator vs type-safety
-- pcarlini at suse dot de changed: What|Removed |Added Severity|major |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970
[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.
--- Comment #29 from pluto at agmk dot net 2007-05-21 17:01 --- (In reply to comment #28) Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var = vi-id instead of rhs.var = id Remove the id variable declaration. This would have only affected fortran thx, this change fixes bootstrap. will you commit this for 4.2.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug fortran/31198] wrong code: Max() with optional arguments
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-21 17:01 --- I've asked in comp.lang.fortran: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5804a24398086e50/fd2b07668628a90d -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Comment #16 from eweddington at cso dot atmel dot com 2007-05-21 17:03 --- Fails with 4.1.2. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Known to fail|4.0.0 4.0.2 4.1.1 |4.0.0 4.0.2 4.1.1 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug target/19636] [4.0/4.1/4.2 regression] Can't compile large switch statement
--- Comment #17 from eweddington at cso dot atmel dot com 2007-05-21 17:09 --- Fails on 4.2.0. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Known to fail|4.0.0 4.0.2 4.1.1 4.1.2 |4.0.0 4.0.2 4.1.1 4.1.2 ||4.2.0 Summary|Can't compile ethernut OS |[4.0/4.1/4.2 regression] |(avr-gcc) |Can't compile large switch ||statement Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug libstdc++/21772] exception safety testing allocator
--- Comment #5 from dave at boost-consulting dot com 2007-05-21 17:16 --- Just adding a throwing allocator (especially one that throws randomly like this one) will not test the library guarantees anywhere nearly as effectively as the STLPort tests do. The technique is outlined in http://www.boost.org/more/generic_exception_safety.html Use this technique. In fact, if you can, use my code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug target/19636] [4.0/4.1/4.2 regression] Can't compile large switch statement
--- Comment #18 from eweddington at cso dot atmel dot com 2007-05-21 17:17 --- Using the target specific option -mno-tablejump fixes the bug for 4.1.2 and 4.2.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.
--- Comment #30 from dberlin at gcc dot gnu dot org 2007-05-21 17:53 --- Subject: Re: [4.2 Regression] possible quadratic behaviour. On 21 May 2007 16:01:29 -, pluto at agmk dot net [EMAIL PROTECTED] wrote: --- Comment #29 from pluto at agmk dot net 2007-05-21 17:01 --- (In reply to comment #28) Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var = vi-id instead of rhs.var = id Remove the id variable declaration. This would have only affected fortran thx, this change fixes bootstrap. will you commit this for 4.2.1? Sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug libstdc++/21772] exception safety testing allocator
--- Comment #6 from pcarlini at suse dot de 2007-05-21 18:12 --- (In reply to comment #5) Use this technique. In fact, if you can, use my code. In fact, Howard already mentioned that, at some point. To be clear, and avoid misunderstandings, I want to clearly state that I consider your offer very kind. Thanks. However, the normal way to manage that would be you filing a copyright assignment and the contributing the code, with full acknowledgment of your help. I'm not sure we can speed-up the procedure much... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #26 from manu at gcc dot gnu dot org 2007-05-21 18:16 --- Can someone from GCC confirm me that Joerg Wunsch has a copyright assignment in-place? If so, I will commit the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug libstdc++/30464] -Wconversion triggers warnings for deque::push_back()
--- Comment #20 from manu at gcc dot gnu dot org 2007-05-21 18:32 --- (In reply to comment #19) I think we can safely at least remove the scary [regression] from the Summary: first, thanks c++/30500 is now fixed and the warnings are always suppressed; second, Manuel is splitting out -Wconversion-sign from -Wconversion. Wconversion does not enable Wsign-conversion for C++. So this is not an issue anymore. Marking as fixed for GCC 4.3 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug c++/32025] left bitshift is broken with 128-bit TIMode
-- igor at roundbox dot com changed: What|Removed |Added Severity|normal |major Component|middle-end |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
[Bug middle-end/32025] left bitshift is broken with 128-bit TIMode
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-21 19:08 --- What options are you using to compile the test program? If you use -O2, then you have an C/C++ aliasing violation in your code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #1 from rob1weld at aol dot com 2007-05-21 19:09 --- I did some more testing on this issue. I started pulling off configure option a half dozen at a time. 1st I removed: --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-decimal-float --with-long-double-128 --with-tls Next I removed: --enable-objc-gc --enable-concept-checks --enable-libstdcxx-debug --enable-static --enable-shared --enable-version-specific-runtime-libs --enable-gc-debug Then I removed: --enable-libssp --enable-libmudflap --enable-libgomp --enable-nls --with-included-gettext --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-interpreter --with-system-zlib --enable-libada It still broke each time in the _exact_ same place. Finally I removed _ALL_ options and simply used ./configure. A grep of the Makefile's BUILD_CONFIGARGS says: '--enable-languages=c,c++,fortran,java,objc' which are not enough for what I prefer - but now it builds I can add some more options back in. So now my xgcc says this: #gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_3-trunk/configure Thread model: posix gcc version 4.3.0 20070521 (experimental) The make of gcc has now passed the point where the prior ICE occurred. I did a diff -q of the ICE'd build directory and the (so far) successful directory and came up with this output (hand-edited output of diff): Files ../gcc-4_3-build-ICE-1/Makefile and ../gcc-4_3-build/Makefile differ Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/fixincludes/config.log and ../gcc-4_3-build/build-i686-pc-linux-gnu/fixincludes/config.log differ Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/fixincludes/config.status and ../gcc-4_3-build/build-i686-pc-linux-gnu/fixincludes/config.status differ Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/fixincludes/mkheaders Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/fixincludes/mkheaders.almost Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/libiberty/Makefile Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/libiberty/config.log Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/libiberty/config.status Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/libiberty/libiberty.a Files ../gcc-4_3-build-ICE-1/config.log Files ../gcc-4_3-build-ICE-1/config.status Files ../gcc-4_3-build-ICE-1/gcc/Make-hooks Files ../gcc-4_3-build-ICE-1/gcc/Makefile Files ../gcc-4_3-build-ICE-1/gcc/ada/Makefile Files ../gcc-4_3-build-ICE-1/gcc/auto-host.h Files ../gcc-4_3-build-ICE-1/gcc/config.cache Files ../gcc-4_3-build-ICE-1/gcc/config.log Files ../gcc-4_3-build-ICE-1/gcc/config.status Files ../gcc-4_3-build-ICE-1/gcc/configargs.h Files ../gcc-4_3-build-ICE-1/gcc/gccbug Files ../gcc-4_3-build-ICE-1/gcc/libada-mk Files ../gcc-4_3-build-ICE-1/intl/Makefile Files ../gcc-4_3-build-ICE-1/intl/config.cache Files ../gcc-4_3-build-ICE-1/intl/config.h Files ../gcc-4_3-build-ICE-1/intl/config.intl Files ../gcc-4_3-build-ICE-1/intl/config.log Files ../gcc-4_3-build-ICE-1/intl/config.status Files ../gcc-4_3-build-ICE-1/libiberty/Makefile Files ../gcc-4_3-build-ICE-1/libiberty/alloca.o Files ../gcc-4_3-build-ICE-1/libiberty/argv.o Files ../gcc-4_3-build-ICE-1/libiberty/choose-temp.o Files ../gcc-4_3-build-ICE-1/libiberty/concat.o Files ../gcc-4_3-build-ICE-1/libiberty/config.cache Files ../gcc-4_3-build-ICE-1/libiberty/config.log Files ../gcc-4_3-build-ICE-1/libiberty/config.status Files ../gcc-4_3-build-ICE-1/libiberty/cp-demangle.o Files ../gcc-4_3-build-ICE-1/libiberty/cp-demint.o Files ../gcc-4_3-build-ICE-1/libiberty/cplus-dem.o Files ../gcc-4_3-build-ICE-1/libiberty/dyn-string.o Files ../gcc-4_3-build-ICE-1/libiberty/fdmatch.o Files ../gcc-4_3-build-ICE-1/libiberty/fibheap.o Files ../gcc-4_3-build-ICE-1/libiberty/filename_cmp.o Files ../gcc-4_3-build-ICE-1/libiberty/floatformat.o Files ../gcc-4_3-build-ICE-1/libiberty/fnmatch.o Files ../gcc-4_3-build-ICE-1/libiberty/fopen_unlocked.o Files ../gcc-4_3-build-ICE-1/libiberty/getopt.o Files ../gcc-4_3-build-ICE-1/libiberty/getopt1.o Files ../gcc-4_3-build-ICE-1/libiberty/getpwd.o Files ../gcc-4_3-build-ICE-1/libiberty/getruntime.o Files ../gcc-4_3-build-ICE-1/libiberty/hashtab.o Files ../gcc-4_3-build-ICE-1/libiberty/hex.o Files ../gcc-4_3-build-ICE-1/libiberty/lbasename.o Files ../gcc-4_3-build-ICE-1/libiberty/libiberty.a Files ../gcc-4_3-build-ICE-1/libiberty/lrealpath.o Files ../gcc-4_3-build-ICE-1/libiberty/make-relative-prefix.o Files ../gcc-4_3-build-ICE-1/libiberty/make-temp-file.o Files ../gcc-4_3-build-ICE-1/libiberty/md5.o Files ../gcc-4_3-build-ICE-1/libiberty/mkstemps.o Files ../gcc-4_3-build-ICE-1/libiberty/objalloc.o Files ../gcc-4_3
[Bug middle-end/32025] left bitshift is broken with 128-bit TIMode
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-21 19:09 --- Also if only 4.0.x is broken, then this is fixed as 4.0.x is no longer being maintained. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
[Bug middle-end/32025] left bitshift is broken with 128-bit TIMode
--- Comment #4 from igor at roundbox dot com 2007-05-21 19:17 --- Sorry, I should've mentioned that - no -O2, here is my command line: g++ -g test_128.cpp -o test_128 And yes, this does seem to be specific to 4.0.x only - gcc 4.1 works fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
[Bug middle-end/32025] left bitshift is broken with 128-bit TIMode
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-21 19:49 --- So closing as fixed as 4.0.x is no longer being maintained. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
[Bug fortran/25095] Disallowed intrinsic in initialization statement
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-21 20:07 --- Confirmed by majority vote. $ ifort -warn all pr25095.f90 fortcom: Error: pr25095.f90, line 2: This expression cannot be evaluated. [MODULO] DATA (i(MODULO(j,5)),j=1,4) /4*0/ ^ fortcom: Info: pr25095.f90, line 1: This variable has not been used. [I] INTEGER :: i(10), j ---^ compilation aborted for pr25095.f90 (code 1) $ sunf95 -w4 pr25095.f90 DATA (i(MODULO(j,5)),j=1,4) /4*0/ ^ pr25095.f90, Line = 2, Column = 9: ERROR: This function name must not appear in a DATA statement expression. f90comp: 3 SOURCE LINES f90comp: 1 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI $ gfortran-svn -v gcc version 4.3.0 20070517 (experimental) still accepts this code. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-21 20:07:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095
[Bug fortran/31197] [4.3/4.2 regression^2] TRANSPOSE/RESHAPE and strings
--- Comment #11 from elizabeth dot l dot yip at boeing dot com 2007-05-21 20:10 --- Ignore Comment #10. I resubmitted my test case as a new bug (31994) last Friday. The bug is fixed this morning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/25252] ICE on invalid code
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-05-21 20:16 --- The testcase of comment #7 seen through valgrind: pr25252.f90:3.26: module procedure X, Y, 1 Error: Syntax error in MODULE PROCEDURE statement at (1) ==12169== Invalid read of size 2 ==12169==at 0x80660ED: check_interface0 (interface.c:945) ==12169== Address 0x42121AA is 34 bytes inside a block of size 128 free'd ==12169==at 0x402119F: free (vg_replace_malloc.c:233) ==12169==by 0x80A4D9A: gfc_undo_symbols (symbol.c:2359) [more to follow] This is indeed similar to PR18923, as pointed out in comment #9. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug middle-end/32026] New: misc.c:899: error: 'const struct real_format' has no member named 'log2_b'
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict -prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -I. -Iada -I. ./../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include -I../../gcc/gcc/../l ibcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/d pd -I../libdecnumber../../gcc/gcc/ada/decl.c -o ada/decl.o gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict -prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -I. -Iada -I. ./../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include -I../../gcc/gcc/../l ibcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/d pd -I../libdecnumber../../gcc/gcc/ada/misc.c -o ada/misc.o ../../gcc/gcc/ada/misc.c: In function 'enumerate_modes': ../../gcc/gcc/ada/misc.c:899: error: 'const struct real_format' has no member na med 'log2_b' 2007-05-21 Andreas Krebbel [EMAIL PROTECTED] * defaults.h (IBM_FLOAT_FORMAT): Macro definition removed. * doc/tm.texi (IBM_FLOAT_FORMAT): Documentation entry removed. * real.c (encode_i370_single, decode_i370_single, encode_i370_double, decode_i370_double): Functions removed. (i370_single_format, i370_double_format): Initializations removed. (real_maxval, round_for_format, exact_real_truncate, significand_size): Consider the log2_b field to always be one. (ieee_single_format, mips_single_format, coldfire_single_format, ieee_double_format, mips_double_format, coldfire_double_format, ieee_extended_motorola_format, ieee_extended_intel_96_format, ieee_extended_intel_128_format, ieee_extended_intel_96_round_53_format, ibm_extended_format, mips_extended_format, ieee_quad_format, mips_quad_format, vax_f_format, vax_d_format, vax_g_format, decimal_single_format, decimal_double_format, decimal_quad_format, c4x_single_format, c4x_extended_format, real_internal_format): Remove initialization of log2_b. * real.h (i370_single_format, i370_double_format): Declarations removed. * c-cppbuiltin.c (builtin_define_float_constants): Consider the log2_b field to always be one. -- Summary: misc.c:899: error: 'const struct real_format' has no member named 'log2_b' Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32026
[Bug fortran/27698] subroutine _foo draws unclassifiable statement instead of a useful error.
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-05-21 20:24 --- Can this be considered fixed? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
[Bug target/10768] ICEs on compilation of ada support library for avr
--- Comment #18 from rolf dot ebert dot gcc at gmx dot de 2007-05-21 20:35 --- Created an attachment (id=13597) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13597action=view) Bernd's patch that fixes the problem Bernd's patch as mentioned in comment #16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #2 from rob1weld at aol dot com 2007-05-21 21:05 --- The BUG is somewhere in here: I put back ALL my origonal (lengthy) configure options but left off the checking. It gets past the ICE. That is not good though... Situation A): The checker is working fine and the code produced is incorrect and this is being caught by the checker. Situation B): The checker is incorrect and the code produced is OK, the checker is wrongly complaining about code that is OK. I check back in a day or two ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug fortran/31399] Wrong code for do loop with large interation count
--- Comment #6 from hjl at lucon dot org 2007-05-21 21:10 --- This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking if Linux/ia32 is also miscompiled. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31399
[Bug fortran/31399] Wrong code for do loop with large interation count
--- Comment #7 from hjl at lucon dot org 2007-05-21 21:19 --- (In reply to comment #6) This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking if Linux/ia32 is also miscompiled. Tonto is also miscompiled on Linux/ia32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31399
[Bug fortran/31399] Wrong code for do loop with large interation count
--- Comment #8 from hjl at lucon dot org 2007-05-21 21:36 ---
According to the comment, before the change, we performed
[evaluate loop bounds and step]
count = (to + step - from) / step;
dovar = from;
for (;;)
{
body;
cycle_label:
dovar += step
count--;
if (count =0) goto exit_label;
}
exit_label:
After the change, we did
[evaluate loop bounds and step]
empty = (step 0 ? to from : to from);
countm1 = (to - from) / step;
dovar = from;
if (empty) goto exit_label;
for (;;)
{
body;
cycle_label:
dovar += step
countm1--;
if (countm1 ==0) goto exit_label;
}
exit_label:
Didn't we do one loop less than before?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31399
[Bug fortran/31399] Wrong code for do loop with large interation count
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-21 21:41 --- (In reply to comment #6) This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking if Linux/ia32 is also miscompiled. Can you file a new bug rather than reopening this one (mark it as blocking this bug)? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31399
[Bug middle-end/32026] [4.3 Regression] misc.c:899: error: 'const struct real_format' has no member named 'log2_b'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build Summary|misc.c:899: error: 'const |[4.3 Regression] misc.c:899: |struct real_format' has no |error: 'const struct |member named 'log2_b' |real_format' has no member ||named 'log2_b' Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32026
[Bug fortran/31399] Wrong code for do loop with large interation count
--- Comment #10 from hjl at lucon dot org 2007-05-21 21:54 --- (In reply to comment #9) (In reply to comment #6) This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking if Linux/ia32 is also miscompiled. Can you file a new bug rather than reopening this one (mark it as blocking this bug)? I don't have a small testcase. It will take a while to find a small testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31399
[Bug c/31924] gcc accepts invalid suffixes for decimal float constants
--- Comment #2 from janis at gcc dot gnu dot org 2007-05-21 22:17 --- Subject: Bug 31924 Author: janis Date: Mon May 21 21:17:23 2007 New Revision: 124913 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124913 Log: libcpp/ PR c/31924 * expr.c (interpret_float_suffix): Check for invalid suffix. gcc/testsuite/ PR c/31924 * gcc.dg/fltconst-1.c: New test. Modified: branches/ibm/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/ibm/gcc-4_1-branch/libcpp/ChangeLog branches/ibm/gcc-4_1-branch/libcpp/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31924
[Bug c++/32016] sizeof(class) always a multiple of 4 on 32 bit machine
--- Comment #2 from bliss1940-bbs at yahoo dot com 2007-05-21 22:18 ---
(In reply to comment #1)
I don't think I said GCC was in error, but just different.
Maybe we can come to an agreement here, or maybe not. Let's see.
I certainly would expect the ARM7 would prefer that 4 byte operands (ints, in
this case) would be on addresses that are a multiple of 4, 2 byte operands
(shorts) would want to be at addresses that are a multiple of two, and 1 byte
operands (chars) have no alignment requirement so could go anywhere.
I would expect to see that somewhere in the ABI. I would also expect to see
that in the ABI for the Intel Pentium. I would not expect to see anything in
the ABI concerning structs as the hardware knows nothing about them. They are
the figment of the imagination of the compiler and programmer.
So I would expect the Microsoft compiler targeting the PC and the GNU compiler
targeting the ARM7 would align shorts and ints accordingly. Indeed, that's
what I see when I examine the code.
By the way, there is a good explanation of this on Wikipedia: It mentions that
compilers usually arrange structs so the primitive objects they contain are at
appropriate addresses. It explains why it's more efficient for the hardware,
and it also explains how the GNU and Microsoft compilers do it when targeting
the PC. So far, so good.
http://en.wikipedia.org/wiki/Data_structure_alignment
But the GNU compiler does something else. It makes the size of all structs a
multiple of 4. I can think of one reason to do this. GNU compiled code can
copy any struct by accessing memory 4 bytes at a time. That is, it can
consider every struct to be composed of ints, and they will all be aligned
correctly. If this is a good enough reason to make all structs a multiple of
4, then so be it. But it's confusing to mention the ABI, because the ABI has
nothing to do with such things. And it's confusing to mention data alignment
because it's an artificial requirement due to the way GNU copies structs. It
has nothing to do with the struct data members as seen by the programmer.
Here are some examples of structs compiled by Microsoft for the PC, and also
compiled by GNU for the ARM7 (Analog Devices ADuC7024). These are the only
compilers I currently have.
Microsoft GNU
struct Char1 { sizeof() == 1sizeof() == 4
char char1;
};
struct Char2 { sizeof() == 2sizeof() == 4
char char1;
char char2;
};
struct Char3 { sizeof() == 3sizeof() == 4
char char1;
char char2;
char char3;
};
struct Char4 { sizeof() == 4sizeof() == 4
char char1;
char char2;
char char3;
char char4;
};
struct Char5 { sizeof() == 5sizeof() == 8
char char1;
char char2;
char char3;
char char4;
char char5;
};
Note that the above structs only have chars so by definition they are aligned
correctly. But Microsoft's structs are only as large as necessary, GNU's are
padded to a multiple of 4 bytes. This has nothing to do with the alignment of
the data members as they have no particular alignment requirement. But as
mentioned before, GNU can copy any struct accessing memory 4 bytes at a time.
There is no other reason I can think of to pad these structs to a multiple of 4
bytes.
Here are some structs that contain shorts (2 byte) to show what data alignment
means to me, to the wiki, to the hardware, and I think also to most people.
Microsoft GNU
class Short1 {
char char1; sizeof() == 4sizeof() == 4
short short1;
};
class Short2 {sizeof() == 6sizeof() == 8
char char1;
short short1;
short short2;
};
Here a hole is inserted after the char. This is required to align the 2 byte
short on the appropriate address. Both Microsoft and GNU agree, as do most
everyone. This is an ABI issue. But notice the second class, Short2. I added
a second short which will automatically have the correct alignment because it
immediately follows another short. It doesn't require padding to be aligned
correctly. Everyone agrees on this. But the Microsoft compiler gives the size
as 6. As always, the GNU compiler adds two pad bytes to make the struct have a
size which is a multiple of 4. But the struct doesn't require this. Neither
would a following struct in an array of structs, as long as the compiler didn't
try accessing these structs as if they contained ints. The only alignment
requirement obvious to the programmer is that the shorts be on addresses that
are a multiple of two bytes.
To beat a dead horse again, the data members
[Bug c++/32016] sizeof(class) always a multiple of 4 on 32 bit machine
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-21 22:24 ---
(In reply to comment #2)
To beat a dead horse again, the data members are suitably aligned in
Microsoft's struct. For the GNU folk to say the extra padding is for data
alignment or is an ABI issue is misleading at best. It's only an
alignment/ABI
issue if the compiler makes it so by generating code that accesses the structs
as if they contained ints, probably for quick copying. But if that's the
case,
I wish they would say that.
Try:
struct a33
{
struct Char1 a1;
struct Char1 a2;
};
And see what size/offset the structs are at. Again this is an ABI issue and
you did not say what exact target you are compiling for, only arm7 which does
not help because there are many different ABIs for the arm. (like arm-elf or
arm-coff or arm-eabi).
And if you want a packed struct use the attribute packed, it also packs the
size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32016
[Bug fortran/32002] [4.2/4.3 regression] insufficient conformance check when assigning the result of an elemental function to an array
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-05-21 22:37 --- Related report: PR26976 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32002
