[Bug middle-end/32533] New: [4.2] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native
derived from CP2K and discussed in PR 29975, the following is miscompiled with the current 4.2 branch : [EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/src cat test.f90 SUBROUTINE T(nsubcell,sab_max,subcells) INTEGER, PARAMETER :: dp=KIND(0.0D0) REAL(dp) :: sab_max(3), subcells,nsubcell(3) nsubcell(:) = MIN(MAX(1,NINT(0.5_dp*subcells/sab_max(:))),20) write(6,*) nsubcell END SUBROUTINE INTEGER, PARAMETER :: dp=KIND(0.0D0) REAL(dp) :: sab_max(3), subcells,nsubcell(3) subcells=2.00 sab_max=0.590060749244805_dp write(6,*) NINT(0.5_dp*subcells/sab_max(1)) CALL T(nsubcell,sab_max,subcells) END [EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/src gfortran -v -O3 -ffast-math -ftree-vectorize -march=native test.f90 Driving: gfortran -v -O3 -ffast-math -ftree-vectorize -march=native test.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_4_2_branch/gcc/configure --prefix=/data03/vondele/gcc_4_2_branch/build --with-gmp=/data03/vondele/ --with-mpfr=/data03/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.2.1 20070627 (prerelease) /data03/vondele/gcc_4_2_branch/build/libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/f951 test.f90 -march=k8 -mtune=k8 -quiet -dumpbase test.f90 -auxbase test -O3 -version -ffast-math -ftree-vectorize -I /data03/vondele/gcc_4_2_branch/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/finclude -o /tmp/ccTYHMGd.s GNU F95 version 4.2.1 20070627 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.1 20070627 (prerelease). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 as -V -Qy -o /tmp/ccs8OyYj.o /tmp/ccTYHMGd.s GNU assembler version 2.16.91.0.5 (x86_64-suse-linux) using BFD version 2.16.91.0.5 20051219 (SUSE Linux) /data03/vondele/gcc_4_2_branch/build/libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /data03/vondele/gcc_4_2_branch/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/crtbegin.o -L/data03/vondele/gcc_4_2_branch/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.1 -L/data03/vondele/gcc_4_2_branch/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/data03/vondele/gcc_4_2_branch/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/../../.. /tmp/ccs8OyYj.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /data03/vondele/gcc_4_2_branch/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/crtfastmath.o /data03/vondele/gcc_4_2_branch/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/crtend.o /usr/lib/../lib64/crtn.o [EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/src ./a.out 2 20.020.020.0 [EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/src gfortran -O0 test.f90 [EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/src ./a.out 2 2.002.002.00 the result is incorrectly 20.0 instead of 2.0 with optimization -- Summary: [4.2] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #127 from jv244 at cam dot ac dot uk 2007-06-28 06:08 --- (In reply to comment #126) As Andrew pointed out in PR 32521 the valgrind warning was fixed in 4.2.1 (prerelease). I've now built the 4.2_branch, and the warning is indeed gone, but unfortunately the same qs_neighbor_lists module is still miscompiled (i.e. same wrong answers obtained from 4.2_branch). The fact that the miscompilation is now completely silent makes it a bit harder to find I'm afraid. serious looking miscompilation added with a small testcase as PR 32533 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/32493] [4.3 Regression] Fails to inline varargs function with unused arguments
--- Comment #9 from bangerth at dealii dot org 2007-06-28 06:48 --- Monologues don't help. Get your fingers out of the pockets and help us fix bugs instead of complaining. Richard has already acknowledged that you found a bug two days after you filed it (and quite humorously). Your attitude only discourages everyone to help you with a fix. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug c/32529] ICE, typedef of function taking VLA
--- Comment #4 from bangerth at dealii dot org 2007-06-28 06:52 --- Apparently not a dup. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug other/31400] enable static linking of support libraries through -static-libXY
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-06-28 07:00 --- FX, thanks for your patch :) As libgfortran is one of many, at least -static-libgomp would be nice to have as well (others?). Reopening, so the request is not lost. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
[Bug fortran/31205] aliased operator assignment produces wrong result
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-28 08:04 --- (In reply to comment #4) (In reply to comment #2) This is related to PR 14771, most likely the parentheses are being ignored. The parentheses are being ignored - in fact they disappear completely; I presume that gfc_simplify_expr is the culprit. Not so - it is matchexp.c, where there is an incorrect interpretation of the standard, such that parentheses are not applied to non-numeric expressions. All expressions in parentheses are data entities. Applying this (modifying gfc_get_parentheses to resolve the expression before doing anything with it.) causes one or two regressions because character lengths need to be carried over (I think!). The second test in this PR now works. In addition, a temporary needs to be made for intent(out), derived types with a default initializer and the initialization applied to that, when the variable is aliassed. I note that other compilers apply the initialization in the callee, whereas gfortran leaves that duty to the caller. I think that the former is cleaner Applying gfc_get_parentheses for this case, in resolve_code at the point where module operator assignments are detected, fixes the 1st test in thi PR, as long as the initialization is shifted to the callee. This latter was effected by writing a helper function to write an lvalue expression from a symbol; this has at least one other existing client and does not apparently cause any regressions. in some sense and that we should make the change. Thus, this little beauty comprises at least two bugs and should probably be three PRs:-) I propose that, for the sake of tractability, it should be left as it is. Paul I am down to 5 regressions for the overall patch, so I had better assign myself the PR! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-17 07:26:16 |2007-06-28 08:04:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31205
[Bug tree-optimization/32533] [4.2 regression] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native
--- Comment #1 from ubizjak at gmail dot com 2007-06-28 08:13 --- Looks like problems in tree ifcvt pass. Before ifcvt, we have: M.2_16 = (int4) D.1257_15; if (M.2_16 1) goto L7; else goto L9; L7:; if (M.2_16 20) goto L10; else goto L9; # M.2_64 = PHI M.2_16(6), 1(5); L9:; pretmp.118_78 = (real8) M.2_64; # prephitmp.119_79 = PHI 2.0e+1(6), pretmp.118_78(7); # M.2_4 = PHI 20(6), M.2_64(7); L10:; But ifcvt creates: D.1446_84 = M.2_16 1; D.1447_85 = M.2_16 20; _ifc_.127_86 = D.1446_84 D.1447_85; D.1449_87 = M.2_16 1; D.1450_88 = M.2_16 = 20; _ifc_.128_89 = D.1449_87 D.1450_88; M.2_64 = M.2_16 1 ? M.2_16 : 1; pretmp.118_78 = (real8) M.2_64; prephitmp.119_79 = M.2_16 1 ? 2.0e+1 : pretmp.118_78; M.2_4 = M.2_16 1 ? 20 : M.2_64; Note the last two lines, where we compare M.2_16 1 instead of M.2_16 20. This bug could be hidden in 4.3.0 as we use MIN_EXPR and MAX_EXPR here. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-28 08:13:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
[Bug tree-optimization/32533] [4.2 regression] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native
--- Comment #2 from ubizjak at gmail dot com 2007-06-28 08:14 --- (In reply to comment #1) This bug could be hidden in 4.3.0 as we use MIN_EXPR and MAX_EXPR here. To clear the typo - we use MIN_EXPR and MAX_EXPR in 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
[Bug c/32529] ICE, typedef of function taking VLA
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2007-06-28 08:34:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #9 from ubizjak at gmail dot com 2007-06-28 08:36 --- (In reply to comment #7) This is what I get without -ftree-vectorize, with -ftree-vectorize (default cost model off) and with -ftree-vectorize -fvect-cost-model respectively on an AMD x86-64 (with trunk plus the patch posted by Dorit at http://gcc.gnu.org/ml/gcc-patches/2007-06/txt00156.txt ) Case 1: (no vectorization) gfortran -static -march=opteron -msse3 -O3 -ffast-math -funroll-loops pr32084.f90 -o 4.3.novect.out time ./4.3.novect.out real0m4.414s user0m4.312s sys 0m0.000s Case 2: (vectorization without cost model) gfortran -static -ftree-vectorize -march=opteron -msse3 -O3 -ffast-math -funroll-loops -fdump-tree-vect-details -fno-show-column pr32084.f90 -o 4.3.nocost.out time ./4.3.nocost.out real0m4.776s user0m4.668s sys 0m0.004s In short, the 8% advantage that the scalar version has over the vector version disappears with the cost model. Unless I am missing something, the inner loops at lines 207 and 319 (do k = 1, 9) dont get vectorized (irrespective of the cost model). No, it is OK (but for core2 and nocona -ftree-vectorize has 50% disadvantage compared to scalar versions). The problem is that vectorized loop is not unrolled anymore in the RTL unroller. My speculation is, that by unrolling the vectorized loop, the runtimes of vectorized version will be _faster_ than scalar versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug tree-optimization/32533] [4.2 regression] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Known to fail|4.0.2 |4.2.0 Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
[Bug c/32496] fno-builtin-* not working
--- Comment #3 from schwab at suse dot de 2007-06-28 08:42 --- A freestanding implementation is required to provide long long support. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32496
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #5 from irar at il dot ibm dot com 2007-06-28 09:02 --- I think it is better to check that the statement is not NULL before calling bsi_insert_on_edge_immediate. I am going to prepare a patch for this. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug other/31400] enable static linking of support libraries through -static-libXY
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org URL|http://gcc.gnu.org/ml/gcc- | |patches/2007- | |06/msg00956.html| Status|REOPENED|NEW Keywords|patch | Target Milestone|4.3.0 |--- Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #10 from ubizjak at gmail dot com 2007-06-28 09:20 --- Well, well - what can be found in _.146r.loop_unroll: Loop 10 is simple: simple exit 40 - 42 number of iterations: (const_int 8 [0x8]) upper bound: 8 ;; Unable to prove that the loop rolls exactly once ;; Considering peeling completely ;; Not peeling loop completely, rolls too much (8 iterations 8 [maximum peelings]) Really funny... Since when is 8 more than 8? ;( However, gcc has no problems when unrolling without --ftree-vectorize: Loop 8 is simple: simple exit 28 - 30 number of iterations: (const_int 8 [0x8]) upper bound: 8 ;; Unable to prove that the loop rolls exactly once ;; Considering peeling completely ;; Decided to peel loop completely Investigating... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #6 from pcarlini at suse dot de 2007-06-28 10:22 --- Ok, I'm implementing the idea. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-28 10:22:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug c++/32534] New: gcc fails to initialize template's static data members before their use in some cases
the following programm
---
#include iostream
struct A
{
A() : value(0) {}
int value;
};
templateclass T
struct B
{
static A a;
};
templateclass T A BT::a;
//template A Bint::a;
templateclass T
struct C
{
C() { Bint::a.value = 1; }
};
Cfloat c;
main()
{
std::cout Bint::a.value std::endl;
}
-
prints 0 instead of expected 1.
It is important that C is template. Otherwise (if C is ordinary class) the
output is 1.
If I use template A Bint::a; instead of templateclass T A BT::a; I
got linker error: undefined reference to 'Bint::a'.
I can't use template A Bint::a = something; form (which would help)
because I have only empty ctor (like in the case of map).
--
Summary: gcc fails to initialize template's static data members
before their use in some cases
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vlbel at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32534
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #11 from ubizjak at gmail dot com 2007-06-28 11:39 --- (In reply to comment #10) ;; Not peeling loop completely, rolls too much (8 iterations 8 [maximum peelings]) This is meant that original + 8 unroll iterations 8. So, loop has 46 insns, and 9 copies of loops is more than PARAM_MAX_COMPLETELY_PEELED_INSNS (currently 400) and unroll is rejeceted. However, even with unrolled vectorized loop, we are still 50% slower. It looks that tight sequences of subsd/subpd and mulsd/mulpd kill performance in -ftree-vectorize: movapd %xmm6, %xmm0 movsd %xmm1, -200(%ebp) subsd %xmm5, %xmm0 subpd (%ebx), %xmm3 mulsd %xmm0, %xmm0 mulpd %xmm3, %xmm3 haddpd %xmm3, %xmm3 movapd %xmm3, %xmm2 movsd w2gauss.1408+8, %xmm3 addsd %xmm2, %xmm0 mulsd w1gauss.1411-8(,%eax,8), %xmm3 sqrtsd %xmm0, %xmm1 It looks that there is no other help but -fvect-cost-model. The results for induct.f90 (gfortran -march=nocona -msse3 -O3 -ffast-math -mfpmath=sse -funroll-loops) are: induct.f90, -ftree-vectorize without -fvect-cost-model: user1m34.046s induct.f90, -ftree-vectorize with -fvect-cost-model: user0m45.447s induct.f90 without -ftree-vectorize: user0m45.215s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-28 11:40 --- I suspect the vectorizer leaves us with too much dead statements that confuse the complete unrollers size cost metric. Running dce after vectorization might fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #6 from irar at il dot ibm dot com 2007-06-28 11:41 --- ((float*) (((sbuf_header_t *) ((buf) == (buf)-buf[0]))-buf[0]))[i] = val; is (after ommiting the casts) *(1B + (i * 4)) = val; Is that legal? Vectorizer assumes that every data-ref has base_address. In the above case we get the following data-ref structure: base_address: 0B offset from base address: 0 constant offset from base address: 1 step: 4 aligned to: 128 base_object: *0B symbol tag: SMT.5 therefore, creating an empty stmt for the first access of the data-ref in the loop. Before Zdenek's rewrite of data-refs analysis, it failed to create a dr here, and thus no segfault occurred. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug middle-end/31150] [4.1/4.2/4.3 Regression] Not promoting an whole array to be static const
--- Comment #5 from eres at il dot ibm dot com 2007-06-28 11:55 ---
(Form off-line discussion with Richard Guenther)
For-
char str[2][16] = {thisis16charslo,thisis16charslo};
On ppc64 we will get -
static char C.0[2][16] = {thisis16charslo, thisis16charslo};
while on x86_64 -
str[0] = thisis16charslo;
str[1] = thisis16charslo;
and this patch makes this output much worse (although it should be
applied only on sparse data)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #13 from burnus at gcc dot gnu dot org 2007-06-28 12:03 --- core2 AMD 0m45.215s 0m4.312s (no vectorize) 1m34.046s 0m4.668s -ftree-vectorize 0m45.447s 0m4.300s -ftree-vectorize -fvect-cost-model i.e. -ftree-vectorize -fvect-cost-model is marginally faster than without -ftree-vectorize on AMD but slower on Intel; and on Intel -ftree-vectorize alone has a huge impact (80% slower) whereas on AMD only it is only 8% slower. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug fortran/32535] New: namelist with private items contained in sub-sub-procedure of a module rejected
Janus, how about submitting a patch for this bug including a testcase? As Janus Weil found out: http://gcc.gnu.org/ml/fortran/2007-06/msg00488.html If a namelist in a procedure contained in a module procedure contains a private item as element, a bogus error message is printed: Error: PRIVATE symbol 'r' cannot be member of PUBLIC namelist at (1) This fails if the symbol is not in the parent, but in the parent-parent namespace. One solution would be to add !(sym-ns-parent-parent == nl-sym-ns) module mod real, private :: r contains subroutine x contains subroutine y namelist /n/ r end subroutine y end subroutine x end module mod end -- Summary: namelist with private items contained in sub-sub- procedure of a module rejected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid 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=32535
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #7 from rguenther at suse dot de 2007-06-28 12:20 --- Subject: Re: [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize On Thu, 28 Jun 2007, irar at il dot ibm dot com wrote: --- Comment #6 from irar at il dot ibm dot com 2007-06-28 11:41 --- ((float*) (((sbuf_header_t *) ((buf) == (buf)-buf[0]))-buf[0]))[i] = val; is (after ommiting the casts) *(1B + (i * 4)) = val; Is that legal? Legal as far as that you are not allowed to reject it at compile-time. Of course runtime behavior looks completely undefined ;) Vectorizer assumes that every data-ref has base_address. In the above case we get the following data-ref structure: base_address: 0B offset from base address: 0 constant offset from base address: 1 step: 4 aligned to: 128 base_object: *0B symbol tag: SMT.5 therefore, creating an empty stmt for the first access of the data-ref in the loop. Before Zdenek's rewrite of data-refs analysis, it failed to create a dr here, and thus no segfault occurred. I suppose rejecting NULL bases should work here? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #8 from irar at il dot ibm dot com 2007-06-28 12:29 --- (In reply to comment #7) I suppose rejecting NULL bases should work here? Yes, only it's not NULL it's zero (0B). We can reject it in the vectorizer or not create a dr for it... Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #9 from rguenther at suse dot de 2007-06-28 12:30 --- Subject: Re: [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize On Thu, 28 Jun 2007, irar at il dot ibm dot com wrote: --- Comment #8 from irar at il dot ibm dot com 2007-06-28 12:29 --- (In reply to comment #7) I suppose rejecting NULL bases should work here? Yes, only it's not NULL it's zero (0B). We can reject it in the vectorizer or not create a dr for it... I suppose all INTEGER_CST bases should be rejected. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #10 from irar at il dot ibm dot com 2007-06-28 12:38 --- (In reply to comment #9) I suppose all INTEGER_CST bases should be rejected. Richard. Right. The value actually doesn't matter since the constant part is split to the init part in (tree-data-ref.c:656): split_constant_offset (base_iv.base, base_iv.base, dinit); I only don't know where it is better to fail - in dr analysis on in the vectorizer. Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #14 from ubizjak at gmail dot com 2007-06-28 12:59 --- (In reply to comment #13) core2 AMD 0m45.215s 0m4.312s (no vectorize) Ehm, the first is full induct.f90 run on _nocona_, whereas AMD is the result of running the attached test. The table with comparable results is then: (gfortran -march=nocona -msse3 -O3 -ffast-math -mfpmath=sse -funroll-loops) nocona(32) AMD(64) 0m4.176s 0m4.312s (no vectorize) 0m8.169s 0m4.668s -ftree-vectorize 0m4.108s 0m4.300s -ftree-vectorize -fvect-cost-model -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug target/32523] disastrous scheduling for POWER5
--- Comment #8 from whaley at cs dot utsa dot edu 2007-06-28 14:18 --- I've been doing further testing on the g5 (the only machine where I have local and root access), and this problem does not occur with stock gcc 4.1.1 either. Therefore, whatever problem is avoided by throwing -fno-schedule-insns was not in 4.1.1. BTW, as on the Power5, the best kernel does not get all it's performance back by throwing this flag, even though the simplified example does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32523
[Bug c/32536] New: wrong generated code on complex statement;
sample code:
#include stdio.h
int main()
{
char cp[2];
cp[0] = 'A';
cp[1] = 'B';
printf(%x %x\n,cp[0],cp[1]);
cp[0] ^= (cp[1]^=(cp[0]^=cp[1]));
printf(%x %x\n,cp[0],cp[1]);
return 0;
}
The complex byte swapping instruction is far fetched but seems legal.
It actually swaps bytes if compiled with gcc -O3. Without optimization,
one of the bytes receives a '\0'.
This instruction seemed to work properly with versions 3.
Environment:
System: Linux lpnp204 2.4.21-47.0.1.EL.cernsmp #1 SMP Thu Oct 19 16:35:52 CEST
2006 i686 i686 i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure
How-To-Repeat:
Compile the code above with various degrees of optimization.
--
Summary: wrong generated code on complex statement;
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astier at lpnp204 dot in2p3 dot fr
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=32536
[Bug bootstrap/32537] New: Boostrap failure: ICE when compiling gengtype-lex.c
When configured and made with
[descartes:gcc/objdirs/objdir-mainline] gcc-test% cat
../../mainline/build-and-check-gcc
#!/bin/tcsh
/bin/rm -rf *; env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../../mainline/configure
--build=powerpc64-apple-darwin8.9.0 --host=powerpc64-apple-darwin8.9.0
--target=powerpc64-apple-darwin8.9.0 --with-gmp=/pkgs/gmp-4.2.1-64/
--with-mpfr=/pkgs/gmp-4.2.1-64/ --prefix=/pkgs/gcc-4.3.0-64; make -j 2
bootstrap BOOT_LDFLAGS='-Wl,-search_paths_first' build.log (make install)
(make -k -j 4 check RUNTESTFLAGS=--target_board 'unix{-mcpu=970/-m64}'
check.log ; make mail-report.log)
bootstrap fails with
/Users/gcc-test/programs/gcc/objdirs/objdir-mainline/./prev-gcc/xgcc
-B/Users/gcc-test/programs/gcc/objdirs/objdir-mainline/./prev-gcc/
-B/pkgs/gcc-4.3.0-64/powerpc64-apple-darwin8.9.0/bin/ -c -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings
-Werror -fno-common -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I../../../mainline/gcc -I../../../mainline/gcc/build
-I../../../mainline/gcc/../include -I./../intl
-I../../../mainline/gcc/../libcpp/include -I/pkgs/gmp-4.2.1-64//include
-I/pkgs/gmp-4.2.1-64//include -I../../../mainline/gcc/../libdecnumber
-I../../../mainline/gcc/../libdecnumber/dpd -I../libdecnumber-o
build/gengtype-lex.o gengtype-lex.c
gengtype-lex.c: In function 'yy_get_next_buffer':
gengtype-lex.c:1614: warning: old-style function definition
gengtype-lex.c: In function 'yy_get_previous_state':
gengtype-lex.c:1746: warning: old-style function definition
gengtype-lex.c: In function 'input':
gengtype-lex.c:1859: warning: old-style function definition
gengtype-lex.c: In function 'yylex':
gengtype-lex.c:1602: 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[3]: *** [build/gengtype-lex.o] Error 1
make[2]: *** [all-stage3-gcc] Error 2
make[1]: *** [stage3-bubble] Error 2
make: *** [all] Error 2
with this version of gcc
[descartes:~/programs/gcc/mainline] gcc-test% cat LAST_UPDATED
Tue Jun 26 16:03:55 EDT 2007
Tue Jun 26 20:03:55 UTC 2007 (revision 126036M)
--
Summary: Boostrap failure: ICE when compiling gengtype-lex.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc64-apple-darwin8.9.0
GCC host triplet: powerpc64-apple-darwin8.9.0
GCC target triplet: powerpc64-apple-darwin8.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32537
[Bug c/32536] wrong generated code on complex statement;
--- Comment #1 from schwab at suse dot de 2007-06-28 16:54 --- You are modifying the same object twice between two sequence points. *** This bug has been marked as a duplicate of 11751 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32536
[Bug c/11751] wrong evaluation order of an expression
--- Comment #77 from schwab at suse dot de 2007-06-28 16:54 --- *** Bug 32536 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||astier at lpnp204 dot in2p3 ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug libgomp/32538] New: All libgomp tests fail to link on IRIX 6: copysignl undefined
All libgomp tests fail to link on IRIX 6: Executing on host: /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/xgcc -B/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/ /vol/gcc/src/gcc-dist/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90 -B/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/ -I/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp -I/vol/gcc/src/gcc-dist/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O0 -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/.libs -lgomp -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/../libgfortran/.libs -lgfortranbegin -lgfortran -lm -o ./a.16.1.exe(timeout = 300) ld32: ERROR 33 : Unresolved data symbol copysignl -- 1st referenced by /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/libgcc.a(_divtc3.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: INFO152: Output file removed because of error. collect2: ld returned 2 exit status compiler exited with status 1 This happens because libgcc contains an undefined reference to copysignl. This function is present in libm, but libm is before libgcc on the linker command line, as can be seen with -v: /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/collect2 -call_shared -no_unresolved -init __gcc_init -fini __gcc_fini -_SYSTYPE_SVR4 -woff 131 -n32 -o ./a.16.1.exe /usr/lib32/mips3/crt1.o /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/irix-crti.o /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/crtbegin.o -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/.libs -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/../libgfortran/.libs -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp -L/lib/../lib32 -L/usr/lib/../lib32 /var/tmp//ccCchLrr.o -lgomp -lgfortranbegin -lgfortran -lm -lgomp -dont_warn_unused -lgcc -lgcc_eh -warn_unused -L/usr/lib32/mips3 -L/usr/lib32 -dont_warn_unused -lpthread -lc -warn_unused -dont_warn_unused -lgcc -lgcc_eh -warn_unused /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/crtend.o /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/irix-crtn.o /usr/lib32/mips3/crtn.o The 4.2 branch is affected as well. Environment: System: IRIX64 columba 6.5 07010238 IP27 host: mips-sgi-irix6.5 build: mips-sgi-irix6.5 target: mips-sgi-irix6.5 configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --with-gnu-as --with-as=/vol/gcc/lib/gas-2.17 --enable-libgcj --with-gmp=/vol/gcc --with-mpfr=/vol/gcc --disable-libmudflap --enable-languages=c,ada,c++,fortran,objc --no-create --no-recursion How-To-Repeat: Bootstrap and test as described above. --- Comment #1 from ro at techfak dot uni-bielefeld dot de 2007-06-28 17:35 --- Fix: There are two possible solutions: * add -lgcc -lm to the link_gomp spec (this is obviously a hack) * add -lm to the libgcc spec (this seems to be the proper solution) Comments? -- Summary: All libgomp tests fail to link on IRIX 6: copysignl undefined Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: mips-sgi-irix6.5 GCC host triplet: mips-sgi-irix6.5 GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32538
[Bug c/32529] [4.1 only] ICE, typedef of function taking VLA
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-28 18:01 --- This works for me in both 4.2.0 and the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.4 Known to work||4.2.0 4.3.0 Summary|ICE, typedef of function|[4.1 only] ICE, typedef of |taking VLA |function taking VLA Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug c/32448] Security - abs / printf bug
--- Comment #22 from rob1weld at aol dot com 2007-06-28 18:32 --- Why is it a bad idea to leave this flaw in GCC ? Format String Bugs and Exploits http://www.geocities.com/ravecoolr/fmt.doc or if you like: http://www.enderunix.org/docs/formatstr.txt Allowing GCC to stay as-is and permit someone to use a user supplied format string to print an integer opens a whole field of exploits that could be closed by fixing this. -- rob1weld at aol dot com changed: What|Removed |Added Summary|abs / printf bug|Security - abs / printf bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c/28504] [4.0/4.1 regression] ICE with variable sized array
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-28 18:49 --- *** Bug 32529 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28504
[Bug c/32529] [4.1 only] ICE, typedef of function taking VLA
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-28 18:49 --- No, this is a dup as the bug there still has not been fixed for 4.1.x. *** This bug has been marked as a duplicate of 28504 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug c/32448] abs / printf bug
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-06-28 18:51 --- There is a -Wformat for a reason, use it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Security - abs / printf bug |abs / printf bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs (in aff_combination_add_elt, tree-affine.c)
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-28 19:04 --- Subject: Bug 32417 Author: pinskia Date: Thu Jun 28 19:03:49 2007 New Revision: 126082 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126082 Log: 2007-06-28 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/32417 * tree-affine.c (aff_combination_add_elt): Handle pointer addition specially. 2007-06-28 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/32417 * gfortran.fortran-torture/compile/pr32417.f90: New test. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr32417.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-affine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-28 19:06 --- Again please read What I wrote about what the C99 standard requires. It requires long long support for a freestanding compiler. So that is provided with libgcc. If the Linux kernel team decides that they don't want to use libgcc, how can this be a GCC bug then? -- 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=32494
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs (in aff_combination_add_elt, tree-affine.c)
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-28 19:06 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
--- Comment #3 from e9fritte at etek dot chalmers dot se 2007-06-28 19:29 --- At that time I was probably using binutils 2.16 (Ubunty Edgy). It seems Feisty still has that version. It's great if this has been resolved in 4.2, although my workaround does its job for now. Thanks to whoever fixed it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
[Bug libgcj/30999] support for GCC4.0's fvisibility option in JNIEXPORT macro
--- Comment #3 from tromey at gcc dot gnu dot org 2007-06-28 19:35 --- Subject: Bug 30999 Author: tromey Date: Thu Jun 28 19:35:25 2007 New Revision: 126090 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126090 Log: 2007-06-28 Jan Nijtmans [EMAIL PROTECTED] PR libgcj/30999: * jni_md.h: Add the possibility to compile jni code with. -fvisibility=hidden. This causes all symbols to be hidden except the JNI functions which need to be exported. Modified: trunk/libjava/ChangeLog trunk/libjava/include/jni_md.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30999
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
--- Comment #4 from eweddington at cso dot atmel dot com 2007-06-28 19:48 --- Closing bug as WORKSFORME. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
[Bug libgcj/30999] support for GCC4.0's fvisibility option in JNIEXPORT macro
--- Comment #4 from tromey at gcc dot gnu dot org 2007-06-28 19:59 --- Fix checked in. -- tromey 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=30999
[Bug tree-optimization/32540] New: Exponential time behavior in PRE
int f(void);
void acceptloop_th(int *t) {
int options = 0;
if (f()) options |= 0x1 0;
if (f()) options |= 0x1 1;
if (f()) options |= 0x1 2;
if (f()) options |= 0x1 3;
if (f()) options |= 0x1 4;
if (f()) options |= 0x1 5;
if (f()) options |= 0x1 6;
if (f()) options |= 0x1 7;
if (f()) options |= 0x1 8;
if (f()) options |= 0x1 9;
if (f()) options |= 0x1 10;
if (f()) options |= 0x1 11;
if (f()) options |= 0x1 12;
if (f()) options |= 0x1 13;
if (f()) options |= 0x1 14;
if (f()) options |= 0x1 15;
if (f()) options |= 0x1 16;
if (f()) options |= 0x1 17;
if (f()) options |= 0x1 18;
if (f()) options |= 0x1 19;
if (f()) options |= 0x1 20;
if (f()) options |= 0x1 21;
if (f()) options |= 0x1 22;
if (f()) options |= 0x1 23;
if (f()) options |= 0x1 24;
if (f()) options |= 0x1 25;
if (f()) options |= 0x1 26;
*t = options;
}
takes many minutes to compile with 4.3. No problem with 4.2. Timing report
shows PRE, and -fno-tree-pre makes it go really fast.
Some timings, where the first number is the number of if-lines:
10 gcc -c -O3 mini2.c -DN=$n 0.17s user 0.01s system 97% cpu 0.184 total
11 gcc -c -O3 mini2.c -DN=$n 0.20s user 0.02s system 97% cpu 0.221 total
12 gcc -c -O3 mini2.c -DN=$n 0.28s user 0.01s system 95% cpu 0.306 total
13 gcc -c -O3 mini2.c -DN=$n 0.42s user 0.03s system 97% cpu 0.463 total
14 gcc -c -O3 mini2.c -DN=$n 0.76s user 0.02s system 97% cpu 0.805 total
15 gcc -c -O3 mini2.c -DN=$n 1.52s user 0.03s system 97% cpu 1.604 total
16 gcc -c -O3 mini2.c -DN=$n 3.24s user 0.07s system 97% cpu 3.396 total
17 gcc -c -O3 mini2.c -DN=$n 7.00s user 0.12s system 97% cpu 7.314 total
18 gcc -c -O3 mini2.c -DN=$n 15.01s user 0.21s system 96% cpu 15.748 total
19 gcc -c -O3 mini2.c -DN=$n 33.21s user 0.49s system 94% cpu 35.600 total
20 gcc -c -O3 mini2.c -DN=$n 76.29s user 0.87s system 96% cpu 1:19.94 total
I'll also attach the original source this test case was extracted from.
--
Summary: Exponential time behavior in PRE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug tree-optimization/32540] Exponential time behavior in PRE
--- Comment #1 from falk at debian dot org 2007-06-28 20:15 --- Created an attachment (id=13801) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13801action=view) Original test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug tree-optimization/32540] [4.3 Regression] Exponential time behavior in PRE
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-28 20:25 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-28 20:25:29 date|| Summary|Exponential time behavior in|[4.3 Regression] Exponential |PRE |time behavior in PRE Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #7 from paolo at gcc dot gnu dot org 2007-06-28 22:58 --- Subject: Bug 32509 Author: paolo Date: Thu Jun 28 22:58:32 2007 New Revision: 126096 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126096 Log: 2007-06-28 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/32509 * acinclude.m4 (GLIBCXX_ENABLE_CLOCALE): Carry out the checks involving the de_DE locale only if an auto locale config is used for a target suitable for the gnu locale model. * docs/html/install.html: Update. * configure: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/docs/html/install.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #8 from paolo at gcc dot gnu dot org 2007-06-28 22:59 --- Subject: Bug 32509 Author: paolo Date: Thu Jun 28 22:59:00 2007 New Revision: 126097 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126097 Log: 2007-06-28 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/32509 * acinclude.m4 (GLIBCXX_ENABLE_CLOCALE): Carry out the checks involving the de_DE locale only if an auto locale config is used for a target suitable for the gnu locale model. * docs/html/install.html: Update. * configure: Regenerated. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug fortran/30940] Fortran 2003: Scalar CHARACTER supplied to array dummy
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-28 23:01 --- Created an attachment (id=13802) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13802action=view) tests, early draft of a patch Attached is some tests plus some minimal patch. Using the patch most valid cases should work. However, some invalid cases are allowed (no range check). The tests have been verified using NAG f95, except for the fourth case in char_argument_3.f90 for which f95 does not give an error. One should re-read the standard and check whether I miss some invalid/valid cases, which should be covered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30940
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #9 from paolo at gcc dot gnu dot org 2007-06-28 23:02 --- Subject: Bug 32509 Author: paolo Date: Thu Jun 28 23:02:05 2007 New Revision: 126098 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126098 Log: 2007-06-28 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/32509 * acinclude.m4 (GLIBCXX_ENABLE_CLOCALE): Carry out the checks involving the de_DE locale only if an auto locale config is used for a target suitable for the gnu locale model. * docs/html/install.html: Update. * configure: Regenerated. Modified: branches/gcc-4_2-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_2-branch/libstdc++-v3/configure branches/gcc-4_2-branch/libstdc++-v3/docs/html/install.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #10 from pcarlini at suse dot de 2007-06-28 23:04 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug tree-optimization/32120] missed PRE/FRE of a*2+4 and (a+2)*2
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-29 03:05 ---
Note we should also optimize:
int f(int a, int b)
{
int c = a+4;
int d = c*2;
int e = a*2;
int f = e+4;
return f+d;
}
into a*2 + 12; (or (a+6)*2 ) so that only one mutliplication is there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120
[Bug tree-optimization/32527] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-29 03:23 --- Testing a patch for this right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
[Bug fortran/32483] edit descriptor checking: Compile-time check for zero width for reading
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-29 03:28 --- What was status on this? I think the patch was OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32483
[Bug c/32542] New: When -msdata is set, gcc sent -memb to gas.
I have a question about the behavior of gcc for powerpc. I think the arguments -msdata and -msdata=default have same effect to gcc. But gcc sent different argument to gas. When -msdata is set, gcc sent -memb to gas. When -msdata=default is set, gcc doesn't send -memb to gas. I think `specs' has an error. Is it correct? Environment: gcc version 4.1.1 Configured with: ../gcc-4.1.1/configure --prefix=/work/te/tool/Linux-i686 --target=powerpc-unknown-linux --with-gnu-as --with-gnu-ld --disable-threads --enable-languages=c --enable-version-specific-runtime-libs --disable-libstdcxx-pch --disable-shared GNU assembler version 2.17 (powerpc-unknown-linux) using BFD version 2.17 host: i686-pc-linux-gnu Example $ /work/te/tool/Linux-i686/bin/powerpc-unknown-linux-gcc -save-temps -v -msdata -c -o main.o main.c . . /work/te/tool/Linux-i686/powerpc-unknown-linux/bin/as -mppc -many -V -Qy -memb -o main.o main.s $ /work/te/tool/Linux-i686/bin/powerpc-unknown-linux-gcc -save-temps -v -msdata=default -c -o main.o main.c . . /work/te/tool/Linux-i686/powerpc-unknown-linux/bin/as -mppc -many -V -Qy -o main.o main.s Regards. -- Summary: When -msdata is set, gcc sent -memb to gas. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tanaka at personal-media dot co dot jp GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32542
