[Bug fortran/29580] integer -2147483648 out of range: bug or feature?
--- Comment #5 from kloedej at knmi dot nl 2006-10-25 07:16 --- Thanks for your additional explanation, and the link to the original mail in the mailing list. A last remark on my side is then about the actual text of this error message. People not familiar with the choice made in the fortran standard to handle the minus here as a unary operator will still be puzzled (like I was) by a message like: i=-2147483648 1 Error: Integer too big for its kind at (1) Maybe it is possible to make the error message a bit more verbose, like: i=-2147483648 1 Error: Integer 2147483648 in unary_minus(2147483648) at (1) too big for its kind This way it is clear to everybody how it is implemented and what is happening. best regards, Jos. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
[Bug fortran/29565] [4.1/4.2/4.3 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-25 07:18 ---
This fixes it but has not been regtested. I was hoping to have found a
slightly cleaner way to fix this but did not alight on anything that would not
be a big performance. It's OK for rank 1 arrays but for rank 2 or higher,
carries baggage in the form of various other declarations from the loopinfo
that was never used.
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 117860)
--- gcc/fortran/trans-expr.c(working copy)
*** gfc_conv_aliased_arg (gfc_se * parmse, g
*** 1708,1716
}
else
{
! /* Make sure that the temporary declaration survives. */
! tmp = gfc_finish_block (body);
! gfc_add_expr_to_block (loop.pre, tmp);
}
/* Add the post block after the second loop, so that any
--- 1708,1721
}
else
{
! /* Make sure that the temporary declaration survives by merging
!all the loop declarations into the current context. */
! for (n = 0; n loop.dimen; n++)
! {
! gfc_merge_block_scope (body);
! body = loop.code[loop.order[n]];
! }
! gfc_merge_block_scope (body);
}
/* Add the post block after the second loop, so that any
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.
--- Comment #6 from uros at kss-loka dot si 2006-10-25 07:33 --- Revision 118024 clears the way for MOD and MODULO implementation: http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00703.html BTW: I don't know fortran requirements, but built-in functions produce faster code if errno is not needed. -mno-math-errno should be used in this case. -- uros at kss-loka dot si changed: What|Removed |Added CC||uros at kss-loka dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug fortran/29523] ICE with some non up-to date .mod files
--- Comment #3 from keinstein_junior at gmx dot net 2006-10-25 07:41 --- Created an attachment (id=12488) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12488action=view) one failing and one working set of .mod files In the tar archive there are two subtrees: src-ICE has all loaded .mod files from the .F90 file, which fails src the same as above, but after rebuilding all .mod files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29523
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #13 from kreckel at ginac dot de 2006-10-25 07:54 --- (In reply to comment #12) It doesn't disappear with -fno-tree-ter, as I would assume if it were a TER bug. I just discovered that it does disappear with -fno-tree-sink, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-25 07:57 --- So what is happening is there explict barrier for the divide so we assume we can move it. I don't know what the correct thing is really, scheduling will have the same issue and so will being able to delete the divide as it is not used (and that is not a regression). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug middle-end/29092] [4.0/4.1 Regression] vector int a = (vector int) { 1,1,2,2} is rejected as non constant
--- Comment #9 from bonzini at gnu dot org 2006-10-25 08:11 --- Subject: Bug 29092 Author: bonzini Date: Wed Oct 25 08:11:26 2006 New Revision: 118025 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118025 Log: 2006-10-25 Paolo Bonzini [EMAIL PROTECTED] PR c/29092 * c-typeck.c (digest_init): Always allow initializing vectors that have static storage duration with compound literals. * tree.c (build_type_attribute_qual_variant): New, based on build_type_attribute_variant. (build_type_attribute_variant): Rewrite using the former. (make_vector_type): Use build_type_attribute_qual_variant to build type variants. Use type_hash_canon on the others. 2006-10-25 Paolo Bonzini [EMAIL PROTECTED] * gcc.dg/simd-5.c, gcc.dg/simd-6: New testcases. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/simd-5.c - copied unchanged from r117696, trunk/gcc/testsuite/gcc.dg/simd-5.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/simd-6.c - copied unchanged from r117696, trunk/gcc/testsuite/gcc.dg/simd-6.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/c-typeck.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29092
[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-25 08:19
---
I'm adding Steve Kargl to the CC list, since he's our arithmetics expert :)
(In reply to comment #6)
Revision 118024 clears the way for MOD and MODULO implementation:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00703.html
Just to be sure I understand: we are garanteed that BUILT_IN_REMAINDER{F,,L}
and BUILT_IN_FMOD{F,,L} are always available, right?
BTW: I don't know fortran requirements, but built-in functions produce faster
code if errno is not needed. -mno-math-errno should be used in this case.
[Hum... I think you mean -fno-math-errno.]
gfortran doesn't have a need for errno to be set after math functions are
called. However, we do want that have correct results in all cases: Inf, NaN,
subnormals, etc. From my reading of the manual, -fno-math-errno would imply
that we do not get such correct results, am I right?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||kargl at gcc dot gnu dot org
Last reconfirmed|2006-10-22 21:01:38 |2006-10-25 08:19:20
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug bootstrap/28400] install-driver is missing $(exeext) from gcc-$(version)
--- Comment #3 from vladimir at codesourcery dot com 2006-10-25 08:54 --- I've confirmed that the patch does adds the exe extension for $target-gcc-$version, when building arm-none-eabi. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28400
[Bug target/28909] Missed optimization with x86 sync builtins
--- Comment #4 from uros at gcc dot gnu dot org 2006-10-25 10:14 --- Subject: Bug 28909 Author: uros Date: Wed Oct 25 10:14:41 2006 New Revision: 118028 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118028 Log: PR target/28909 * config/i386/sync.md (sync_addmode, sync_submode): Use inc and dec instructions for TARGET_USE_INCDEC. (*sync_compare_and_swapmode): Fix -masm=intel template. (sync_double_compare_and_swapmode): Likewise. (*sync_double_compare_and_swapdi_pic): Likewise. (*sync_compare_and_swap_ccmode): Likewise. (sync_double_compare_and_swap_ccmode): Likewise. (*sync_double_compare_and_swap_ccdi_pic): Likewise. (sync_old_addmode): Likewise. (sync_lock_test_and_setmode): Likewise. (sync_lock_test_and_setmode): Likewise. (sync_addmode): Likewise. (sync_submode): Likewise. (sync_iormode): Likewise. (sync_andmode): Likewise. (sync_xormode): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sync.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28909
[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.
--- Comment #8 from uros at kss-loka dot si 2006-10-25 11:48 ---
(In reply to comment #7)
Just to be sure I understand: we are garanteed that BUILT_IN_REMAINDER{F,,L}
and BUILT_IN_FMOD{F,,L} are always available, right?
Yes. The expansion does not depend on -ffast-math anymore. However, the named
pattern should be present in .md files. Currently, i386 provides named pattern
for -mfpmath=387, but not for -mfpmath=sse. In the later case, expansion will
fall-back to normal library call.
gfortran doesn't have a need for errno to be set after math functions are
called. However, we do want that have correct results in all cases: Inf,
NaN, subnormals, etc. From my reading of the manual, -fno-math-errno would
imply that we do not get such correct results, am I right?
Fortunatelly, no. The result will be correct. You can see the effect of
-fno-math-errno at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01158.html.
Fixup code detects NaN (as an abnormal return from builtin funcion) and calls
library function in order to set global variable errno. If global variable
errno is not needed (as I suspect is the case with fortran libraries), fixup
code is not needed, so -fno-math-errno shoul be used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #6 from uros at kss-loka dot si 2006-10-25 12:04 --- (In reply to comment #5) With more registers (x86_64) the stack moves are gone, but: (!) (testing done on AMD Athlon fam 15 model 35 stepping 2) On Xeon 3.6, SSE is now faster: gcc -O2 -march=pentium4 -mfpmath=387 pr19780.c time ./a.out Start? Stop! Result = 0.00, 0.00, 1.00 real0m0.805s user0m0.804s sys 0m0.000s gcc -O2 -march=pentium4 -mfpmath=sse pr19780.c time ./a.out Start? Stop! Result = 0.00, 0.00, 1.00 real0m0.707s user0m0.704s sys 0m0.004s vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.60GHz stepping: 10 cpu MHz : 3600.970 cache size : 2048 KB The question is now, why is Athlon so slow with SFmode SSE? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
Re: [Bug tree-optimization/29585] [4.2/4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
On 25 Oct 2006 05:23:00 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 05:22 --- _ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream # _ZTI13basic_ostream = V_MAY_DEF _ZTI13basic_ostream_16; # _ZTIN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE = V_MAY_DEF _ZTIN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE_17; # _ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream = V_MAY_DEF _ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream; # _ZTSN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE = V_MAY_DEF _ZTSN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE; # _ZTVN10__cxxabiv120__si_class_type_infoE = V_MAY_DEF _ZTVN10__cxxabiv120__si_class_type_infoE; # _ZTI8ios_base = V_MAY_DEF _ZTI8ios_base; # _ZTS13basic_ostream = V_MAY_DEF _ZTS13basic_ostream; # _ZTVN10__cxxabiv121__vmi_class_type_infoE = V_MAY_DEF _ZTVN10__cxxabiv121__vmi_class_type_infoE; # _ZTS8ios_base = V_MAY_DEF _ZTS8ios_base; # _ZTVN10__cxxabiv117__class_type_infoE = V_MAY_DEF _ZTVN10__cxxabiv117__class_type_infoE; # SFT.5 = V_MAY_DEF SFT.5; # SFT.6 = V_MAY_DEF SFT.6; # SFT.7 = V_MAY_DEF SFT.7; # SFT.8 = V_MAY_DEF SFT.8; # SFT.9 = V_MAY_DEF SFT.9; # NONLOCAL.15 = V_MAY_DEF NONLOCAL.15; this_9-_vptr.basic_ostream = iftmp.1_13; Uh, this is pretty weird. *all* of these should have been marked for renaming, not just NONLOCAL.
[Bug tree-optimization/29585] [4.2/4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-10-25 12:12 --- Subject: Re: [4.2/4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558 On 25 Oct 2006 05:23:00 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 05:22 --- _ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream # _ZTI13basic_ostream = V_MAY_DEF _ZTI13basic_ostream_16; # _ZTIN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE = V_MAY_DEF _ZTIN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE_17; # _ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream = V_MAY_DEF _ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream; # _ZTSN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE = V_MAY_DEF _ZTSN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE; # _ZTVN10__cxxabiv120__si_class_type_infoE = V_MAY_DEF _ZTVN10__cxxabiv120__si_class_type_infoE; # _ZTI8ios_base = V_MAY_DEF _ZTI8ios_base; # _ZTS13basic_ostream = V_MAY_DEF _ZTS13basic_ostream; # _ZTVN10__cxxabiv121__vmi_class_type_infoE = V_MAY_DEF _ZTVN10__cxxabiv121__vmi_class_type_infoE; # _ZTS8ios_base = V_MAY_DEF _ZTS8ios_base; # _ZTVN10__cxxabiv117__class_type_infoE = V_MAY_DEF _ZTVN10__cxxabiv117__class_type_infoE; # SFT.5 = V_MAY_DEF SFT.5; # SFT.6 = V_MAY_DEF SFT.6; # SFT.7 = V_MAY_DEF SFT.7; # SFT.8 = V_MAY_DEF SFT.8; # SFT.9 = V_MAY_DEF SFT.9; # NONLOCAL.15 = V_MAY_DEF NONLOCAL.15; this_9-_vptr.basic_ostream = iftmp.1_13; Uh, this is pretty weird. *all* of these should have been marked for renaming, not just NONLOCAL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #7 from uros at kss-loka dot si 2006-10-25 12:18 --- (In reply to comment #6) On Xeon 3.6, SSE is now faster: ... but for -ffast-math: SSE: user0m0.756s x87: user0m0.612s Yes, x87 is faster for -ffast-math by some 20%. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug other/29442] insn-attrtab has grown too large
--- Comment #3 from JoeGTN1 at NetZero dot net 2006-10-25 12:44 --- I think the pertinent part of this bug is: Is it possible to split this file? It took 6-8 hours to compile this file alone on my xbox, which only has 64m of memory but should be considered a sufficiently modern machine. My understanding is that this is a generated file, containing information about lots of different architectures. Might it be possible to generate a file per architecture, or per group of architectures? This is not a new problem, this file is what made me give up on Linux for the Dreamcast (Which might not be considered a sufficiently modern machine.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
[Bug target/28803] No SSE inline expansion for lrint
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-25 13:09 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28803
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #15 from kreckel at ginac dot de 2006-10-25 13:22 --- (In reply to comment #14) Maybe scheduling would have the same issue. The fact that the result of the division is not used is a red herring, though. Of course, the assumption is that it's actually used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-25 13:53 --- (In reply to comment #8) In the later case, expansion will fall-back to normal library call. OK. So on system where the math library doesn't have remainderl, for example, we shouldn't use BUILT_IN_REMAINDERL or it will be missing at link-time? If that's the case, then we can't implement MOD/MODULO with these built-ins. Fortunatelly, no. The result will be correct. You can see the effect of -fno-math-errno at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01158.html. And now, a harder question: could we activate no-math-errno on a per-call basis? That is, have the front-end emit a call to BUILT_IN_FOO and specify that, for this call, errno doesn't have to be set? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug preprocessor/29588] /usr/local/include should not be in the default include path
--- Comment #2 from vincent at vinc17 dot org 2006-10-25 14:00 --- (In reply to comment #1) So this sounds like a bug in your installation. This cannot be with my installation in particular as the bug occurred on various Linux machines (only one is mine). However it could be due to bad defaults in Linux distributions. FYI, I've opened a bug here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395177 against libc6 (there could be a fix there), but perhaps ld should be fixed too, as the bug occurs whether -static is given or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29588
[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.
--- Comment #10 from uros at kss-loka dot si 2006-10-25 14:16 --- (In reply to comment #9) In the later case, expansion will fall-back to normal library call. OK. So on system where the math library doesn't have remainderl, for example, we shouldn't use BUILT_IN_REMAINDERL or it will be missing at link-time? If that's the case, then we can't implement MOD/MODULO with these built-ins. You can check for TARGET_C99_FUNCTIONS before they are used. Fortunatelly, no. The result will be correct. You can see the effect of -fno-math-errno at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01158.html. And now, a harder question: could we activate no-math-errno on a per-call basis? That is, have the front-end emit a call to BUILT_IN_FOO and specify that, for this call, errno doesn't have to be set? errno expansion for this particular built-in is inhibited in line 1995 of builtins.c. For a per-call basis, we need an argument to expand_builtin() function to disable errno expansion. However, the rationale for this is unclear to me. IMO - either we use errno, or we don't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug c++/29590] New: ice with -Os on legal code
I just tried to compile Suse Linux 10.1 package abiword-2.4.5-6 with the new GNU C compiler version 4.3 snapshot 20061023 on a x86_64 machine. The compiler said ap_Menu_Functions.cpp: In function 'EV_Menu_ItemState ap_GetState_SetPosImage(AV_View*, XAP_Menu_Id)': ap_Menu_Functions.cpp:1588: internal compiler error: in build2_stat, at tree.c:2963 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -Os required. -- Summary: ice with -Os on legal code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29590
[Bug c++/29590] ice with -Os on legal code
--- Comment #1 from dcb314 at hotmail dot com 2006-10-25 14:29 --- Created an attachment (id=12489) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12489action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29590
[Bug c++/29590] ice with -Os on legal code
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-25 14:39 --- *** This bug has been marked as a duplicate of 29567 *** -- 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=29590
[Bug tree-optimization/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-25 14:39 --- *** Bug 29590 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29567
[Bug middle-end/29092] [4.0 Regression] vector int a = (vector int) { 1,1,2,2} is rejected as non constant
--- Comment #10 from bonzini at gnu dot org 2006-10-25 14:55 --- Subject: Bug 29092 Author: bonzini Date: Wed Oct 25 14:55:09 2006 New Revision: 118034 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118034 Log: 2006-10-26 Paolo Bonzini [EMAIL PROTECTED] PR c/29092 * c-typeck.c (digest_init): Always allow initializing vectors that have static storage duration with compound literals. * tree.c (build_type_attribute_qual_variant): New, based on build_type_attribute_variant. (build_type_attribute_variant): Rewrite using the former. (make_vector_type): Use build_type_attribute_qual_variant to build type variants. Use type_hash_canon on the others. testsuite: 2006-10-26 Paolo Bonzini [EMAIL PROTECTED] * gcc.dg/simd-5.c, gcc.dg/simd-6: New testcases. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/simd-5.c - copied unchanged from r117696, trunk/gcc/testsuite/gcc.dg/simd-5.c branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/simd-6.c - copied unchanged from r117696, trunk/gcc/testsuite/gcc.dg/simd-6.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/c-typeck.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29092
[Bug middle-end/29092] [4.0 Regression] vector int a = (vector int) { 1,1,2,2} is rejected as non constant
--- Comment #11 from bonzini at gnu dot org 2006-10-25 14:55 --- committed to all branches -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.0 4.1.1 |4.0.3 4.1.1 Known to work|3.4.0 4.2.0 4.1.2 |3.4.0 4.2.0 4.1.2 4.0.4 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29092
[Bug c/29592] New: Unending loops
After compilation test1.c with -O2 program loops unending.. Yeah I know is
possible cause -fstrict-aliasing and program works compilated with -O2
-fno-strict-aliasing
It works too if it was compilated just only with -fstrict-aliasing so it loops
when some other optimization was turned on.
It works too (not loops unending) if in loop while (* ((char *) str))
we `printf(0x%x\n, str);` (maybe some other code which evaluate and use that
exp works too, i don't really know) [test2.c]
If it's not gcc bug, I'm really sorry inconvience.. (something code like that
was used in ekg2
#v+
(functions:
http://webcvs.ekg2.org/_checkout_/ekg2/plugins/ncurses/ecurses.c?rev=1.3
usage:
while (__S(str, 0)) { /* while (*str) */
__SN(str, 1); /* str++ */
attr++;
}
loops unending, however if __SN() was declared not inline it works... for me it
was really strange, in testcases keyword 'inline' doesn't change behavior.
#v-
If it's not gcc bug, but mine, once again i'm really sorry... Sorry for me
English too.
testcase tested with:
gcc (GCC) 4.1.1 (Gentoo 4.1.1-r1)
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
gcc (GCC) 4.1.0 (SUSE Linux)
--
Summary: Unending loops
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: darkjames at darkjames dot ath dot cx
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=29592
[Bug c/29592] Unending loops
--- Comment #1 from darkjames at darkjames dot ath dot cx 2006-10-25 16:12 --- Created an attachment (id=12490) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12490action=view) First testcase First testcase loops unending with -O2, not loops with -O2 -fno-strict-aliasing || -fstrict-aliasing -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29592
[Bug c/29592] Unending loops
--- Comment #2 from darkjames at darkjames dot ath dot cx 2006-10-25 16:13 --- Created an attachment (id=12491) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12491action=view) Second testcase test1.c + added printf() to loop, not loops with -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29592
[Bug bootstrap/29509] gcj MetalLookAndFeel.java causes gcj to SIGILL on PPC Linux
--- Comment #4 from billt at tutsys dot com 2006-10-25 16:13 --- No luck using gcc 4.1.1 as the bootstrap compiler: I used the existing compiler to build and install just the C compiler, which worked fine. make bootstrap failed to build gcj using 4.1.1 as the C compiler. I then built and installed the 4.1.1 versions of C and C++, and used *those* to make bootstrap, but still end up crashing when using make bootstrap build gcj (as well as the C and C++ compilers): make[7]: Entering directory `/tmp/gcc-4.1.1/820/powerpc-unknown-linux-gnu/nof/libjava/classpath/lib' true top_builddir=.. top_srcdir=../../../../../../libjava/classpath /bin/sh ./gen-classlist.sh standard Adding java source files from srcdir '../../../../../../libjava/classpath'. Adding java source files from VM directory /tmp/gcc-4.1.1/libjava Adding java source files from VM directory /tmp/gcc-4.1.1/820/powerpc-unknown-linux-gnu/nof/libjava Adding generated files in builddir '..'. make -f ../../../../../../libjava/classpath/lib/Makefile.gcj \ GCJ='/tmp/gcc-4.1.1/820/gcc/gcj -B/tmp/gcc-4.1.1/820/powerpc-unknown-linux-gnu/nof/libjava/ -B/tmp/gcc-4.1.1/820/gcc/' \ compile_classpath='..:/tmp/gcc-4.1.1/libjava:/tmp/gcc-4.1.1/820/powerpc-unknown-linux-gnu/nof/libjava:../../../../../../libjava/classpath:../../../../../../libjava/classpath/external/w3c_dom:../../../../../../libjava/classpath/external/sax:.:' \ top_srcdir=../../../../../../libjava/classpath make[7]: *** [compile-classes] Illegal instruction make[7]: Leaving directory `/tmp/gcc-4.1.1/820/powerpc-unknown-linux-gnu/nof/libjava/classpath/lib' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29509
[Bug c/29592] Unending loops
--- Comment #3 from darkjames at darkjames dot ath dot cx 2006-10-25 16:20 --- By the way, it's possible to fix the code in other way than using unions? It just need to work both for wchar_t strings and normal strings... If you have some ideas how, it'll be nice if you give me some hint... maybe use char * everywhere and use: real_char_index = index * (config_use_unicode * sizeof(wchar_t)) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29592
[Bug other/29442] insn-attrtab has grown too large
--- Comment #4 from rick at hartmantech dot com 2006-10-25 16:23 --- The problem is not only confined to sufficiently modern machines. Some of us have a conservationist sort of outlook, and are happy to find a use for an older machine as a router, firewall, Kerberos server or whatever. Linux supports this sort of thing well - a floppy firewall with no hard drive will run just fine on an 8M machine, and a 486/33 will keep up with all that an ordinary ADSL connection can transmit. With insn-attrtab excluded, gcc-4.1.1 compiles quickly and well on 52M, and quite possibly on smaller machines, though I have no very recent experience to prove it. It seems a pity that a single source file, and an automatically-generated one at that, should essentially block an excellent compiler from a lot of smaller machines, new and old, and cause enough of a slowdown even on a 512M machine to arouse concern. If there is a rational reason for this file to be huge, well and good, but if it is readily split that would seem like a worthwhile thing to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
[Bug c/29592] Unending loops
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 16:45 --- In the both case, you are accessing wchar * via char * which causes an alias violation. -- 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=29592
[Bug c++/29593] New: Missing warning.
The following code has a subtle bug:
#include assert.h
class Blah
{
public:
const unsigned int myfoo;
Blah(const unsigned int p):
myfoo(p) {}
const unsigned int getfoo()
{
return myfoo;
}
};
int main()
{
int foo(42);
Blah baz(foo);
++foo;
assert(foo == baz.getfoo());
return 0;
}
When foo is passed to the constructor for baz, as foo is not unsigned a
temporary is made and a constant reference to it is passed to Blah.
No warnings for this code appear in 4.2.0 at the highest warning levels. Would
it be possible to add a warning, such as reference is bound to converted
temporary? I'm not sure how many false-positives would be generated, but I do
know this bug too a long time to find for someone.
--
Summary: Missing warning.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29593
[Bug c/29592] Unending loops
--- Comment #5 from darkjames at darkjames dot ath dot cx 2006-10-25 17:11 --- Yeah, I know, but why gcc generate good code if we add that printf to test1.c (test2.c) ? It's still wchar * - char * still aliasing violation. or if we replace: __SN(str, 1); with str = (CHAR_T *) (((char *) str) + 1); it generate good code too. it's still aliasing violation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29592
[Bug c/29592] Unending loops
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-25 17:18 --- (In reply to comment #5) Yeah, I know, but why gcc generate good code if we add that printf to test1.c (test2.c) ? It's still wchar * - char * still aliasing violation. Yes but there is a barrier which cause optimizations not to happen. or if we replace: __SN(str, 1); with str = (CHAR_T *) (((char *) str) + 1); it generate good code too. it's still aliasing violation? No, that is legal as you are not accessing str (wchar_t*) as a char* any longer but as a wchar_t*. You access str as a wchar_t* and then cast that value to a char* and then add one and then cast back to wchar_t* which causes the above code to be valid and defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29592
[Bug c/29592] Unending loops
--- Comment #7 from darkjames at darkjames dot ath dot cx 2006-10-25 17:24 --- Ok, one more question, is it possible to gcc print some warnings about code like that? Cause even with -Wall it doesn't ;( gcc4 is quite more verbose than gcc3 so I think It'll be better to print warning about situation which doesn't even generate invalid code... which actually -Wstrict-aliasing does (according to manpage), but neither -Wstrict-aliasing nor -Wstrict-aliasing=2 prints warning in that testcode... I hope it's possible, thx for all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29592
[Bug libgcj/29594] New: jv-convert with no args NPE
If I run jv-convert with no arguments I see an NPE: opsy. jv-convert Exception in thread main java.lang.NullPointerException at gnu.gcj.convert.IOConverter.canonicalize(libgcj.so.7) at gnu.gcj.convert.BytesToUnicode.getDecoder(libgcj.so.7) at java.io.InputStreamReader.init(libgcj.so.7) at gnu.gcj.convert.Convert.main(libgcj.so.7) Arguably we ought to fix this problem by replacing jv-convert with Classpath's native2ascii. -- Summary: jv-convert with no args NPE Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29594
[Bug c++/29593] Missing warning.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 18:56 --- This warning is hard to get right as there are many many pieces of code that depends on binding an rvalue to an constant reference. This bug is related to PR 986. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29593
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-10-25 20:11 --- (In reply to comment #1) Thomas, Have you written Adrain about his plans concerning his patch? Not yet (I tried CC'ing him with this, but apparently this doesn't work). IIRC (and Adrian, please correct me) his patch concerned the per-unit setting of four-byte markers. Here, I'm trying to implement the Intel subrecord markers. BTW, I think the Intel subrecord approach is probably the best solution to the large record problem. I'm glad we agree on this. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-25 20:11:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug c/29595] New: gcc miscompilation of some stuff
I noticed this while developing/debugging the source file, the code is in a very rough and buggy state but the behavior I'm getting seems to be tied to a properly formed printf(). $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) File will be attached. Sample output: WITH THE PRINTF (note the Most common lines): Current: 1 Most common: 1 9 :: 1 Current: 1 Current: 19 Most common: 4 15 :: 19 Current: 1 Current: 1 Current: 1 Current: 1 Current: 20 Most common: c 1c :: 20 Current: 1 Current: 1 Current: 1 Current: 1 Current: 1 Current: 68 Most common: 11 11 :: 68 Current: 1 Current: 1 Current: 77 Most common: 11 19 :: 77 Current: 5 Current: 1 Current: 4 Current: 1 Current: 4 Current: 11 Current: 5 Current: 7 Current: 2 Current: 6 Current: 1 Current: 3 Current: 16 Current: 7 Current: 1 Current: 19 Current: 4 Current: 8 Current: 6 Current: 8 Current: 9 Current: 8 [output trimmed...] Most common: 11 19 :: 77 0 0 :: 516 Key size: 134513244 WITHOUT THE PRINTF (Current: %i\n lines no longer printing): Most common: 0 0 :: 0 0 0 :: 516 Key size: 134513244 -- Summary: gcc miscompilation of some stuff Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nigelenki at comcast dot net GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
[Bug fortran/29397] Constant logical expression with parameter array
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-10-25 20:39 --- This is not a maxloc bug per se. Look at this: $ cat a9.f90 INTEGER :: K(3)=1 INTEGER, PARAMETER :: J(3)=2 write (6,*) J1 END $ gfortran -fdump-tree-original a9.f90 $ ./a.out F Output should be F F F instead. This is correct when the logical expression isn't constant: $ cat a10.f90 INTEGER :: K(3)=1 INTEGER, PARAMETER :: J(3)= (/0, 1, 2 /) write (6,*) J1 END $ gfortran a10.f90 $ ./a.out T F F Looks like overzelous simplification, somewhere. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Summary|Problem with MAXLOC where |Constant logical expression |mask involves a parameter |with parameter array |array | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29397
[Bug c/29595] gcc miscompilation of some stuff
--- Comment #1 from nigelenki at comcast dot net 2006-10-25 20:41 --- Created an attachment (id=12492) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12492action=view) decrypt_1.2.c C source file, there's a big block that says GCC MISCOMPILATION above the printf triggering this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #15 from ghazi at gcc dot gnu dot org 2006-10-25 20:44 --- Subject: Bug 29335 Author: ghazi Date: Wed Oct 25 20:44:09 2006 New Revision: 118042 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118042 Log: PR middle-end/29335 * builtins.c (fold_builtin_cbrt, fold_builtin_logarithm): Calculate compile-time constants using MPFR. (fold_builtin_1): Likewise handle BUILT_IN_ERF, BUILT_IN_ERFC, BUILT_IN_EXPM1 and BUILT_IN_LOG1P. testsuite: * gcc.dg/torture/builtin-math-2.c (TESTIT): Use new helper macro. Add checks for log, log2, log10 and log1p. * gcc.dg/torture/builtin-math-3.c: Add checks for -0.0 everywhere we already test 0.0. Add checks for expm1, log, log2, log10, log1p, cbrt, erf and erfc. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-math-2.c trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug c/29595] gcc miscompilation of some stuff
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-25 20:45 --- How did you build it? It says t.c: In function a_hash: t.c:95: warning: right shift count = width of type also it seems to need proper input... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
[Bug c/29595] gcc miscompilation of some stuff
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-25 20:51 --- Eh, we're not going to debug your code for you. It looks too buggy and segfaults on me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
[Bug c/29595] gcc miscompilation of some stuff
--- Comment #4 from nigelenki at comcast dot net 2006-10-25 21:42 --- Issue was passing an unsigned long int to a %i instead of %li format specifier in printf(). I didn't know my C library altered anything if %n wasn't specified... oh well, my bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
[Bug c++/29596] New: overloaded function not found
Please find attached a sample program, which does not compile. Unfortunately this program depends on boost. I use the current boost version 1.33.1. The include files algorithm and iostream are the ones belonging to gcc-4.1.1. -- Summary: overloaded function not found Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: again at gmx dot de GCC build triplet: i686-pc-gnu-linux GCC host triplet: i686-pc-gnu-linux GCC target triplet: i686-pc-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #1 from again at gmx dot de 2006-10-25 21:45 --- Created an attachment (id=12493) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12493action=view) test.cpp (sample program that does not compile) This program does not compile (commandline g++ test.cpp -o test) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-25 21:48 --- Can you provide the preprocessed source which you can get via -save-temps and it will be called something .ii. Also you can provide the error message you get? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #3 from again at gmx dot de 2006-10-25 21:50 --- Created an attachment (id=12494) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12494action=view) output of g++ test.cpp -o test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #4 from again at gmx dot de 2006-10-25 21:51 --- Created an attachment (id=12495) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12495action=view) output of Visual C++ .NET 2003 plus output of compiled program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #5 from again at gmx dot de 2006-10-25 21:53 --- test.ii produced by `g++ -v -save-temps test.cpp -o test' is to bug for bugzilla -- you can find it here: http://schlotter.org/pub/test.ii (1.2MB) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #6 from again at gmx dot de 2006-10-25 21:57 --- Remark to test.cpp:23: std::cout boost::lambda::_1 '\n' This should find the overloaded operator defined in boost/tuple_io.hpp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29597] New: log expression returns different results when casting
The following code should return the base2 logarithm of 64 (ie 6) double d = log(64.0) / log(2.0); int i = (int)d; cout i; And indeed it does output 6. However, if you attempt to cast it on the same line, then it returns 5. int i2 = (int)( log(64.0) / log(2.0) ); int i3 = static_castint( log(64.0) / log(2.0) ); cout i2 i3; This outputs 55 instead of the expected 66. Visual Studio 2003 outputs 66. gcc 4.1.0, Suse Linux 10.1. -- Summary: log expression returns different results when casting Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brad_atcheson at yahoo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29597
[Bug c++/29597] log expression returns different results when casting
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 22:05 --- This comes from precission of the floating point. *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29597
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #84 from pinskia at gcc dot gnu dot org 2006-10-25 22:05 --- *** Bug 29597 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||brad_atcheson at yahoo dot ||ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug middle-end/29519] [4.2/4.3 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #10 from daney at gcc dot gnu dot org 2006-10-25 22:29 --- Subject: Bug 29519 Author: daney Date: Wed Oct 25 22:29:10 2006 New Revision: 118044 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118044 Log: PR middle-end/29519 * rtlanal.c (nonzero_address_p): Remove check for values wrapping. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/rtlanal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug middle-end/29519] [4.2/4.3 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #11 from daney at gcc dot gnu dot org 2006-10-25 22:34 --- With the (now committed) patches, my testing shows the problem as fixed. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug libstdc++/29529] purify with iostream reports 128 uninitialized memory reads
--- Comment #2 from mstaley at lanl dot gov 2006-10-25 22:38 --- (In reply to comment #1) This is most likely a purify problem. Have you tried using valgrind instead? I just tried valgrind. I'm not really familiar with valgrind, but as far as I can tell it reports no problems. So, either purify is wrong, valgrind is wrong, or they're both wrong in different ways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29529
[Bug tree-optimization/29598] New: FAIL: gcc.dg/tree-ssa/loadpre1.c and loadpre1[45].c scan-tree-dump-times Eliminated: 1 1
Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .2/objdir/gcc/ /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/tree-ssa/loadpre1 .c -O2 -fdump-tree-pre-stats -fno-show-column -S -o loadpre1.s(timeout = 300) PASS: gcc.dg/tree-ssa/loadpre1.c (test for excess errors) FAIL: gcc.dg/tree-ssa/loadpre1.c scan-tree-dump-times Eliminated: 1 1 Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .2/objdir/gcc/ /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/tree-ssa/loadpre1 4.c -O2 -fdump-tree-pre-stats -fno-show-column -S -o loadpre14.s(timeout = 300) PASS: gcc.dg/tree-ssa/loadpre14.c (test for excess errors) FAIL: gcc.dg/tree-ssa/loadpre14.c scan-tree-dump-times Eliminated: 1 1 Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .2/objdir/gcc/ /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/tree-ssa/loadpre1 5.c -O2 -fdump-tree-pre-stats -fno-show-column -S -o loadpre15.s(timeout = 300) PASS: gcc.dg/tree-ssa/loadpre15.c (test for excess errors) FAIL: gcc.dg/tree-ssa/loadpre15.c scan-tree-dump-times Eliminated: 1 1 These fails are regressions in behavior. They started close to the time the 4.2 branch was created. -- Summary: FAIL: gcc.dg/tree-ssa/loadpre1.c and loadpre1[45].c scan-tree-dump-times Eliminated: 1 1 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29598
[Bug tree-optimization/29598] FAIL: gcc.dg/tree-ssa/loadpre1.c and loadpre1[45].c scan-tree-dump-times Eliminated: 1 1
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 23:04 --- This is mentioned in: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01003.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa*-*-* | GCC host triplet|hppa*-*-* | GCC target triplet|hppa*-*-* | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29598
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Comment #37 from ghazi at gcc dot gnu dot org 2006-10-26 00:59 --- A request for this optimization made by Bruce in Sept 2000. :-) http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00877.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu
2006-10-26 04:03 ---
Subject: Re: Intrinsic MOD incorrect for large arg1/arg2 and slow.
On Wed, Oct 25, 2006 at 08:19:21AM -, fxcoudert at gcc dot gnu dot org
wrote:
I'm adding Steve Kargl to the CC list, since he's our arithmetics expert :)
You flatter me. :-O
(In reply to comment #6)
Revision 118024 clears the way for MOD and MODULO implementation:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00703.html
Just to be sure I understand: we are garanteed that BUILT_IN_REMAINDER{F,,L}
and BUILT_IN_FMOD{F,,L} are always available, right?
If a target supports the builtin, then gfortran can be made to
use it. In fact, you can't disable builtins.
troutmask:sgk[274] gfc -fno-builtin -c sqrt90.f90
f951: warning: command line option -fno-builtin is valid for
C/C++/ObjC/ObjC++ but not for Fortran
If a target does not have builtins for fmod and remainder and
configure provides HAVE_FMOD and HAVE_REMAINDER macros, gfortranr
could punt to library routines like we do for spacing, rrspacing, etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug libstdc++/29529] purify with iostream reports 128 uninitialized memory reads
--- Comment #3 from pcarlini at suse dot de 2006-10-26 04:22 --- (In reply to comment #2) I just tried valgrind. I'm not really familiar with valgrind, but as far as I can tell it reports no problems. So, either purify is wrong, valgrind is wrong, or they're both wrong in different ways. Maybe wrong is too strong a statement, in this case. In practice, what often makes a difference is that valgrind knows about many details of the GNU environment (for instance about the underlying glibc) and is thus able to automatically filter out many potential false positives. It does that via a constantly updated so-called suppression file (see the manual, about that). Anyway, I will double check myself in a few days... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29529
[Bug c++/18313] Missing warning for superfluous const's in return types
-- mueller at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18313
[Bug fortran/29563] Internal read loses data.
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-10-26 04:35 --- Subject: Bug 29563 Author: jvdelisle Date: Thu Oct 26 04:35:45 2006 New Revision: 118059 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118059 Log: 2006-10-25 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/29563 * io/io.h (st_parameter_dt): Add new flag at_eof. * io/list_read.c (next_char): Set flag when EOF and return '\n' to signal EOR. Check flag on next call and jump out. * io/unit.c (get_internal_unit): Initialize new flag. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
[Bug fortran/29563] Internal read loses data.
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-10-26 04:42 --- Subject: Bug 29563 Author: jvdelisle Date: Thu Oct 26 04:41:55 2006 New Revision: 118060 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118060 Log: 2006-10-26 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/29563 * gfortran.dg/arrayio_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/arrayio_9.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
[Bug c++/29033] %s substituted with left/right can't be properly translated
-- mueller at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29033
