[Bug c++/14875] When using 'or' keyword, the error message speaks of a '||' token
--- Comment #11 from spiridenok at tut dot by 2007-11-22 08:39 --- Since when are "or"/"and"/"xor" C++ keywords? (In reply to comment #1) > In C++ or is a keyword for |, so this is invalid. > > Also the follow are keywords: > and& > xor^ -- spiridenok at tut dot by changed: What|Removed |Added CC||spiridenok at tut dot by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14875
[Bug fortran/34143] alloc_comp_constructor.f90 fails with -fdefault-integer-8
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-22 08:56 --- Erik, Paul, as authors of the original patch and testcases, can you confirm my conclusion that the code in comment #4 (and thus, the gfortran.dg/alloc_comp_constructor_1.f90 testcase) is not legal, for the reason I indicate in the comment? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||erik dot edelmann at iki dot ||fi, pault at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-22 09:09
---
It's not even MERGE-related:
$ cat a.f90
integer :: i(1) = 0
write(*,*) foo([1]+i)
end
$ gfortran a.f90
a.f90: In function MAIN__:
a.f90:1: internal compiler error: in gfc_trans_create_temp_array, at
fortran/trans-array.c:592
The assertion in fails because the loop->from[0] is equal to 1, but we want it
to be zero. It is set to 1 in gfc_conv_loop_setup:
/* Set the extents of this range. */
cshape = loopspec[n]->shape;
if (cshape && INTEGER_CST_P (info->start[n])
&& INTEGER_CST_P (info->stride[n]))
{
loop->from[n] = info->start[n];
mpz_set (i, cshape[n]);
mpz_sub_ui (i, i, 1);
/* To = from + (size - 1) * stride. */
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug rtl-optimization/33848] [4.2 Regression] reference to non-existent label at -O1 on mips/mipsel
--- Comment #11 from rsandifo at gcc dot gnu dot org 2007-11-22 09:28 --- Subject: Bug 33848 Author: rsandifo Date: Thu Nov 22 09:27:55 2007 New Revision: 130344 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130344 Log: gcc/ PR rtl-optimization/33848 * reload.c (subst_reloads): When replacing a LABEL_REF with a register, only add a REG_LABEL note if the label is the target of the jump. gcc/testsuite/ PR rtl-optimization/33848 * gcc.dg/torture/pr33848.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr33848.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/reload.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33848
[Bug rtl-optimization/33848] [4.2 Regression] reference to non-existent label at -O1 on mips/mipsel
--- Comment #12 from rsandifo at gcc dot gnu dot org 2007-11-22 09:30 --- Subject: Bug 33848 Author: rsandifo Date: Thu Nov 22 09:30:02 2007 New Revision: 130345 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130345 Log: gcc/testsuite/ PR rtl-optimization/33848 * gcc.dg/torture/pr33848.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr33848.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33848
[Bug fortran/31213] ICE on valid code with gfortran
--- Comment #9 from pault at gcc dot gnu dot org 2007-11-22 09:30 --- Note that I posted an example to comp.lang.fortran that fails because of this bug: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6fea2c0227d1d430#657c2f8659a0024e I'll get the patch submitted just as soon as all the wrinkles in my fix for PR33541 are sorted out. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31213
[Bug rtl-optimization/33848] [4.2 Regression] reference to non-existent label at -O1 on mips/mipsel
--- Comment #13 from rsandifo at gcc dot gnu dot org 2007-11-22 09:32 --- Patch applied to 4.2. Mainline was already OK, so only the testcase went there. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.0 |4.2.2 Known to work|4.1.3 |4.1.3 4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33848
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #6 from rguenther at suse dot de 2007-11-22 09:35 --- Subject: Re: [4.3 Regression] SCCVN breaks gettext On Thu, 22 Nov 2007, dberlin at dberlin dot org wrote: > --- Comment #4 from dberlin at gcc dot gnu dot org 2007-11-22 04:48 > --- > Subject: Re: [4.3 Regression] SCCVN breaks gettext > > The real problem seems to me, at least unless you guys haven't pasted > that part of the trace, that nitems_19 isn't part of the SCC but > should be. By the time iteration of the SCC finishes, we should have > discovered that nitems_19 does not have the value 0. The SCC looks complete. The IL before FRE is : : # nitems_21 = PHI <0(2), nitems_20(9)> : # nitems_1 = PHI D.1574_5 = hash_find_entry (&list); if (D.1574_5 == 0) goto ; else goto ; : list.0_6 = list; D.1576_7 = *list.0_6; len2_8 = (size_t) D.1576_7; new_max_9 = nitems_1 + len2_8; if (new_max_9 != len2_8) goto ; else goto ; : dest_10 = foo (new_max_9); goto ; : destptr_15 = destptr_3 + 8; : # destptr_3 = PHI # len2_2 = PHI len2_14 = len2_2 + 0x0; if (len2_2 != 0) goto ; else goto ; : destptr.2_16 = (long int) destptr_3; dest.3_17 = (long int) dest_10; D.1581_18 = destptr.2_16 - dest.3_17; D.1582_19 = D.1581_18 /[ex] 8; nitems_20 = (size_t) D.1582_19; goto ; : return 0; and the offending SCC contains: SCC consists of: nitems_21 nitems_1 new_max_9 dest_10 destptr_3 destptr.2_16 dest.3_17 D.1581_18 D.1582_19 nitems_20 destptr_15 where it goes wrong is in the 2nd iteration where it doesn't figure that destptr_3 != dest_10. Note that I also don't believe arbitrary wrong information in the optimistic table can ever lead to always correct information with a new table in just one iteration. Because in our case we set the value number of nitems_20 to zero (and thus the VN of nitems_21), so even with the correct tables we start (and thus never change) with nitems_21 == 0. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug target/34174] gcc produces erroneous asm for movdi
--- Comment #5 from markus dot heigl at fme dot fujitsu dot com 2007-11-22 09:39 --- When trying to build a cross compiler with this patch I get following error: dp-bit.c: In function â__muldf3â: dp-bit.c:964: internal compiler error: in change_address_1, at emit-rtl.c:1783 build options: ../gcc-4.2.2/configure --target=fr30-elf --prefix=/fme/users/mhaigl/unstable-gcc --with-gnu-as --with-gnu-ld --without-headers --with-newlib --enable-languages=c --disable-shared -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug c/34185] New: -Os seems to be broken on alpha
I had trouble building firefox on alpha. In the first moment I thought it's a binutils bug, since when I add --no-relax to ld, the build goes trough. However, the produced result doesn't actually work. In http://sources.redhat.com/bugzilla/show_bug.cgi?id=5276#c6, H.J.Lu tought it might be a compiler bug and Jay Estabrook gave me the hint to use -O2 instead of -Os and that actually worked fine. Another ref to the rhbz# https://bugzilla.redhat.com/show_bug.cgi?id=379551 You can find a build.log of a try to build firefox with -Os here: http://buildsys.zero42.at/koji/taskinfo?taskID=61352 If you need any additional information, please let me know! -- Summary: -Os seems to be broken on alpha Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oliver at linux-kernel dot at GCC build triplet: alpha-redhat-linux GCC host triplet: alpha-redhat-linux GCC target triplet: alpha-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34185
[Bug fortran/34079] Bind(C): Character argument/return value problems
--- Comment #9 from burnus at gcc dot gnu dot org 2007-11-22 09:56 --- Subject: Bug 34079 Author: burnus Date: Thu Nov 22 09:55:47 2007 New Revision: 130346 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130346 Log: 2007-11-22 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34079 * trans-expr.c (gfc_conv_function_call): Do not append string length arguments when calling bind(c) procedures. * trans-decl.c (create_function_arglist): Do not append string length arguments when declaring bind(c) procedures. 2007-11-22 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34079 * gfortran.dg/bind_c_usage_10.f03: Remove .mod file afterwards. * gfortran.dg/bind_c_usage_13.f03: New. * gfortran.dg/bind_c_usage_14.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_usage_13.f03 trunk/gcc/testsuite/gfortran.dg/bind_c_usage_14.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079
[Bug c++/30293] [4.0/4.1/4.2/4.3 regression] ICE with extern "Java" in store_init_value
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-22 10:11 --- Testing a patch which does that. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 14:52:47 |2007-11-22 10:11:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30293
[Bug c++/30294] [4.0/4.1/4.2/4.3 regression] ICE with extern "Java" in ocp_convert
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-22 10:11 --- Testing a patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 14:53:11 |2007-11-22 10:11:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30294
[Bug libstdc++/33893] [parallel mode] Algorithms rely on omp_set_dynamic(false)
--- Comment #1 from singler at gcc dot gnu dot org 2007-11-22 10:13 --- Subject: Bug 33893 Author: singler Date: Thu Nov 22 10:13:08 2007 New Revision: 130347 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130347 Log: 2007-11-22 Johannes Singler <[EMAIL PROTECTED]> PR libstdc++/33893 * include/parallel/multiway_merge.h: made omp_dynamic-safe * include/parallel/workstealing.h: made omp_dynamic-safe * include/parallel/base.h: infrastructure, cleanup * include/parallel/par_loop.h: made omp_dynamic-safe * include/parallel/features.h: activate loser tree variant * include/parallel/quicksort.h: made omp_dynamic-safe * include/parallel/compiletime_settings.h: settings overridable * include/parallel/equally_split.h: made omp_dynamic-safe * include/parallel/omp_loop_static.h: made omp_dynamic-safe * include/parallel/random_shuffle.h: made omp_dynamic-safe * include/parallel/balanced_quicksort.h: made omp_dynamic-safe * include/parallel/set_operations.h: made omp_dynamic-safe * include/parallel/unique_copy.h: made omp_dynamic-safe * include/parallel/multiway_mergesort.h: made omp_dynamic-safe * include/parallel/search.h: made omp_dynamic-safe * include/parallel/partition.h: made omp_dynamic-safe * include/parallel/partial_sum.h: made omp_dynamic-safe * include/parallel/find.h: made omp_dynamic-safe * include/parallel/omp_loop.h: made omp_dynamic-safe * include/parallel/losertree.h: avoid default constructor Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/balanced_quicksort.h trunk/libstdc++-v3/include/parallel/base.h trunk/libstdc++-v3/include/parallel/compiletime_settings.h trunk/libstdc++-v3/include/parallel/equally_split.h trunk/libstdc++-v3/include/parallel/features.h trunk/libstdc++-v3/include/parallel/find.h trunk/libstdc++-v3/include/parallel/losertree.h trunk/libstdc++-v3/include/parallel/multiway_merge.h trunk/libstdc++-v3/include/parallel/multiway_mergesort.h trunk/libstdc++-v3/include/parallel/omp_loop.h trunk/libstdc++-v3/include/parallel/omp_loop_static.h trunk/libstdc++-v3/include/parallel/par_loop.h trunk/libstdc++-v3/include/parallel/partial_sum.h trunk/libstdc++-v3/include/parallel/partition.h trunk/libstdc++-v3/include/parallel/quicksort.h trunk/libstdc++-v3/include/parallel/random_shuffle.h trunk/libstdc++-v3/include/parallel/search.h trunk/libstdc++-v3/include/parallel/set_operations.h trunk/libstdc++-v3/include/parallel/unique_copy.h trunk/libstdc++-v3/include/parallel/workstealing.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33893
[Bug libstdc++/33893] [parallel mode] Algorithms rely on omp_set_dynamic(false)
--- Comment #2 from singler at gcc dot gnu dot org 2007-11-22 10:15 --- Fixed by patch. -- singler at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33893
[Bug libstdc++/33893] [parallel mode] Algorithms rely on omp_set_dynamic(false)
--- Comment #3 from singler at gcc dot gnu dot org 2007-11-22 10:22 --- Subject: Bug 33893 Author: singler Date: Thu Nov 22 10:22:08 2007 New Revision: 130348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130348 Log: Closing branch, corresponding patch to fix PR libstdc++/33893 has been checked in into trunk with revision 130347. Removed: branches/libstdc++-v3-parallel-mode-openmp-cleanup/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33893
[Bug fortran/34186] New: dump-parse-tree: ICE for ts->cl->length, if ts->cl == NULL
gfortran -fdump-parse-tree crashes for the following program as
ts->cl == NULL for dump-parse-tree.c's gfc_show_typespec
case BT_CHARACTER:
gfc_show_expr (ts->cl->length);
break;
After disabling the gfc_show_expr if ts->cl == NULL, there is an internal error
shown unless one adds:
--- misc.c (revision 130347)
+++ misc.c (working copy)
@@ -141,0 +142,3 @@ gfc_basic_typename (bt type)
+case BT_VOID:
+ p = "VOID";
+ break;
Additionally, we need to check for missing attributes etc. in the dumps, which
were not added for BIND(C); e.g. the following is missing:
--- dump-parse-tree.c (revision 130347)
+++ dump-parse-tree.c (working copy)
@@ -584,0 +588,2 @@ gfc_show_attr (symbol_attribute *attr)
+ if (attr->is_bind_c)
+gfc_status (" BIND(C)");
Test case:
function func0(x) result(result_func0) bind(c)
use, intrinsic :: iso_c_binding
real(c_double) :: result_func0
real(c_double), value, intent(in) :: x
result_func0 = 1.0_c_double
end function func0
--
Summary: dump-parse-tree: ICE for ts->cl->length, if ts->cl ==
NULL
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
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=34186
[Bug fortran/34187] New: BIND(C): Public generic with private bind(c) specific does not use bind(C) name
As reported by Chris: For the following code, the bind(C) is ignored when calling the private specific subroutine "test" via calling the generic procedure "gen". Result: The procedure "test_" is called and the linker complains. If one makes "test" public, it works. As -fdump-parse-tree shows (after applying the fixes from PR34186), in "main" "test" has the "bind(c)" attribute. subroutine test() bind(c) end subroutine test module mod private public :: gen interface gen subroutine test() bind(c) end subroutine test end interface gen end module mod program main use mod call gen end program main -- Summary: BIND(C): Public generic with private bind(c) specific does not use bind(C) name Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code 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=34187
[Bug bootstrap/34188] New: xgcc: Internal error: Segmentation fault (program cc1plus)
make[4]: *** [i686-pc-linux-gnu/bits/extc++.h.gch/O2g.gch] Error 1 Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2) === $ ../gcc-4.3-20071116_SVN/configure --prefix=/home/compiler/gcc-4.3-20071116_SVN_final/ --enable-languages=c,c++ -- Summary: xgcc: Internal error: Segmentation fault (program cc1plus) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rene at gsse dot at 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=34188
[Bug bootstrap/34188] xgcc: Internal error: Segmentation fault (program cc1plus)
--- Comment #1 from rene at gsse dot at 2007-11-22 11:44 --- Created an attachment (id=14601) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14601&action=view) config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34188
[Bug bootstrap/34188] xgcc: Internal error: Segmentation fault (program cc1plus)
-- rene at gsse dot at changed: What|Removed |Added Severity|blocker |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34188
[Bug bootstrap/34189] New: Kernel hangs while booting when compiled with gcc-4.3 snapshot.
Hello all, I have successfully built SH4-Linux toolchain based on (binutils-2.17.50, gcc-4.3-20071012, glibc-2.6) for Renesas SH target I am facing problem while booting the Linux kernel on SH target. Targets Used for Testing: SH7751R2D+ and SH7780 Highlander RP I have successfully compiled Linux kernel using toolchain but kernel hangs after following message: Disk drive detected: TOSHIBA THNCF128MMG 3.10 STCB21M85008B24183C8 Set Transfer Mode result: 51 Initialize Device Parameters result: 50 IDLE result: 50 LILO boot: first-image Loading linuxdone. It is not even printing the banner of the kernel. The same kernel when compiled with gcc-4.2.1 based toolchain, it boots successfully on the target hardware Any help on this will be highly appreciated. Regards, Ashay Jaiswal KPIT Cummins Infosystems Ltd, Pune (INDIA) ~~ Free download of GNU based SH-Linux toolchains for Renesas' SHSeries. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU SH-Linux tools were released on October 19, 2007. ~~ -- Summary: Kernel hangs while booting when compiled with gcc-4.3 snapshot. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ashay dot Jaiswal at kpitcummins dot com GCC build triplet: i686-pc-linux GCC host triplet: sh4-unknown-linux GCC target triplet: sh4-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34189
[Bug fortran/34187] BIND(C): Public generic with private bind(c) specific does not use bind(C) name
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-22 11:56 --- Some more debugging. The problem is that in gfc_conv_function_call / gfc_sym_mangled_function_id of "main", is_bind_c=1 but binding_label = '\0'. Actually, already for gfc_search_interface, I get sym=test and bind= '\0'. Educated guess: The problem is in module.c; the binding label is properly written into the .mod file (from looking at it) but in load_generic_interfaces, the "gfc_get_symbol (p, NULL, &sym);" returns for p = "test" no binding name. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34187
[Bug bootstrap/34190] New: libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared
In file included from /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/char_traits.h:48, from /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/string:47, from ../../../../gcc-4.3-20071116/libstdc++-v3/src/compatibility.cc:49: /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:103: error: '::clearerr' has not been declared /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:104: error: '::fclose' has not been declared /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:105: error: '::feof' has not been declared /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:106: error: '::ferror' has not been declared /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:107: error: '::fflush' has not been declared /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:108: error: '::fgetc' has not been declared /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:109: error: '::fgetpos' has not been declared /iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:110: error: '::fgets' has not been declared -- Summary: libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rene at gsse dot at GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34190
[Bug bootstrap/34190] libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared
--- Comment #1 from rene at gsse dot at 2007-11-22 11:58 --- Created an attachment (id=14602) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14602&action=view) config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34190
[Bug bootstrap/34190] libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared
--- Comment #2 from rene at gsse dot at 2007-11-22 11:59 --- Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --enable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34190
[Bug c/34191] New: Using gcc with -mptr64 option produces the following message: the internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669
The gcc (at least versions 3.3.2 till 4.2.1) on Solaris 5.9 issues an internal error message while compiling a trivial programme (attached): [EMAIL PROTECTED]>/usr/local/gcc-4.2.1/bin/gcc -v -mptr64 -W -Wall -Wextra -pedantic -std=c99 -I. -o sizeof3 sizeof3.c Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../gcc-4.2.1/configure --prefix=/usr/local/gcc-4.2.1 --disable-shared --enable-languages=c,c++ Thread model: posix gcc version 4.2.1 /usr/local/gcc-4.2.1/libexec/gcc/sparc-sun-solaris2.9/4.2.1/cc1 -quiet -v -I. -D__sparcv8 sizeof3.c -quiet -dumpbase sizeof3.c -mptr64 -mcpu=v9 -auxbase sizeof3 -W -Wall -Wextra -pedantic -std=c99 -version -o /var/tmp//ccdldVVn.s ignoring nonexistent directory "/usr/local/gcc-4.2.1/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../sparc-sun-solaris2.9/include" #include "..." search starts here: #include <...> search starts here: . /usr/local/include /usr/local/gcc-4.2.1/include /usr/local/gcc-4.2.1/lib/gcc/sparc-sun-solaris2.9/4.2.1/include /usr/include End of search list. GNU C version 4.2.1 (sparc-sun-solaris2.9) compiled by GNU C version 4.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 9e0484c08da0f561a4f4189fd65650a4 sizeof3.c:7: warning: return type defaults to 'int' sizeof3.c: In function 'main': sizeof3.c:23: warning: large integer implicitly truncated to unsigned type sizeof3.c:13: internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: Using gcc with -mptr64 option produces the following message: the internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pmendez at orga-systems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34191
[Bug c/34191] Using gcc with -mptr64 option on Solaros 5.9 produces the following message: the internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669
--- Comment #1 from pmendez at orga-systems dot com 2007-11-22 12:10 --- Created an attachment (id=14603) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14603&action=view) Complete compiler output as required by the guidelines Output from /usr/local/gcc-4.2.1/bin/gcc -v -mptr64 -W -Wall -Wextra - pedantic -std=c99 -I. -o sizeof3 sizeof3.c -save-temp and uname -a -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34191
[Bug c/34191] Using gcc with -mptr64 option on Solaros 5.9 produces the following message: the internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669
--- Comment #2 from pmendez at orga-systems dot com 2007-11-22 12:13 --- Created an attachment (id=14604) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14604&action=view) the preprocessed file (*.i*) that triggers the bug as required by the guidelines Please notice that when using both -m64 -mptr64 this internal error does not occur. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34191
[Bug bootstrap/34190] libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared
--- Comment #3 from pcarlini at suse dot de 2007-11-22 12:13 --- This must be a Gentoo-only issue: literally tens if not hundreds of GCC developers are daily bootstrapping multiple times on x86_64-linux and everything works fine. I would suggest searching Bugzilla a little more, may well be a duplicate... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34190
[Bug target/34174] gcc produces erroneous asm for movdi
--- Comment #6 from rask at gcc dot gnu dot org 2007-11-22 12:31 --- Created an attachment (id=14605) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14605&action=view) patch v1 for GCC 4.2.2 Here's a different patch which hopefully doesn't ICE on GCC 4.2.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug target/34174] gcc produces erroneous asm for movdi
--- Comment #7 from markus dot heigl at fme dot fujitsu dot com 2007-11-22
12:50 ---
Building with this patch produces following error.
Same build options as last time.
../../gcc-4.2.2/gcc/libgcc2.c: In function â__udivmoddi4â:
../../gcc-4.2.2/gcc/libgcc2.c:1054: error: insn does not satisfy its
constraints:
(insn 908 907 903 52 ../../gcc-4.2.2/gcc/libgcc2.c:962 (set (reg:DI 2 r2)
(mem/c:DI (reg:SI 2 r2) [27 rr+0 S8 A32])) 7 {*movdi_insn} (nil)
(nil))
../../gcc-4.2.2/gcc/libgcc2.c:1054: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:392
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #29 from pcarlini at suse dot de 2007-11-22 12:58 --- *** Bug 34190 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||rene at gsse dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug bootstrap/34190] libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared
--- Comment #4 from pcarlini at suse dot de 2007-11-22 12:58 --- *** This bug has been marked as a duplicate of 30915 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34190
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #25 from jakub at gcc dot gnu dot org 2007-11-22 13:05 --- Don't see the point of keeping this bug open for the trunk: with g++ -O2 -m32 pr25505.ii from #c1 on ppc64-linux g++ 3.2.3 sed -n 's/^[[:blank:]]*stwu 1,//p' pr25505.s | sort -nur -16(1) -32(1) -48(1) -64(1) -80(1) -96(1) -128(1) -192(1) -320(1) -336(1) -384(1) -512(1) -592(1) -688(1) -7232(1) g++ 4.1.2 sed -n 's/^[[:blank:]]*stwu 1,//p' pr25505.s | sort -nur -16(1) -32(1) -48(1) -64(1) -80(1) -96(1) -112(1) -128(1) -224(1) -272(1) -320(1) -336(1) -352(1) -432(1) -1024(1) -13168(1) trunk sed -n 's/^[[:blank:]]*stwu 1,//p' pr25505.s | sort -nur -16(1) -32(1) -48(1) -64(1) -80(1) -96(1) -112(1) -144(1) -208(1) -224(1) -336(1) -400(1) -768(1) -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] gcc |gcc uses way too much stack |uses way too much stack |space for this code |space for this code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-22 13:06 --- Current mainline shows the same symptoms. I didn't verify the regression is fixed by reverting r126198. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2007-11-22 13:06:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug fortran/34143] alloc_comp_constructor.f90 fails with -fdefault-integer-8
--- Comment #6 from burnus at gcc dot gnu dot org 2007-11-22 13:18 --- (In reply to comment #4) > The Intel and Sun compilers complain that this code is not legal, because you > can't do "x = mytype(yy, bar)" if yy is not allocated. I cannot reproduce this with the Sun Compiler, only with ifort. Besides, following the Fortran 2003 standard, I believe the program is valid. "If a component of a derived type is allocatable, the corresponding constructor expression shall either be a reference to the intrinsic function NULL with no arguments, an allocatable entity of the same rank, or shall evaluate to an entity of the same rank. If the expression is a reference to the intrinsic function NULL, the corresponding component of the constructor has a status of unallocated. If the expression is an allocatable entity, the corresponding component of the constructor has the same allocation status as that allocatable entity and, if it is allocated, the same dynamic type, bounds, and value;" (Fortran 2003 standard, "4.5.9 Construction of derived-type values") -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-22 13:28 --- Created an attachment (id=14606) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14606&action=view) patch doing TBAA pruning on the access site But this patch makes the regression in the particular function go away. In other functions the alias information would allow hoisting invariant loads after this patch but neither PRE nor LIM do it there, possibly because they do not try to prove that # VUSE D.627356_122 = p_121->engine_m.data_m; cannot trap (I'm not 100% sure that can be proven). The patch doesn't cause any notable performance improvement though (probably because of the above reason). Also the missing V_MUST_DEFs cause missing propagation/dce of trivial copies in arrays. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug middle-end/32624] r126198 causes tramp3d slowdown w/o leafify
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-22 13:29 --- I'll make this just a non-regression enhancement PR for now. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2007-11-22 13:06:59 |2007-11-22 13:29:26 date|| Summary|[4.3 Regression] r126198|r126198 causes tramp3d |causes tramp3d slowdown w/o |slowdown w/o leafify |leafify | Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug fortran/34192] New: problem with NEAREST intrinsic function
PROGRAM test WRITE(*,*) NEAREST(0.d0,1.d0) END >> gfortran test.f90 t.f90:3.21: WRITE(*,*) NEAREST(0.d0,1.d0) 1 Error: Result of NEAREST underflows its kind at (1) -- Summary: problem with NEAREST intrinsic function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: francois dot jacq at irsn dot fr GCC host triplet: Linux i686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34192
[Bug target/34174] gcc produces erroneous asm for movdi
--- Comment #8 from rask at gcc dot gnu dot org 2007-11-22 13:54 --- Created an attachment (id=14607) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14607&action=view) patch v2 for GC 4.2.2 Weird. I don't understand why GCC 4.2.2 is having problems with that. This patch tries to fix fr30_move_double(), which has been broken ever since it was added seven and a half years ago. The instruction sequence now looks like this: ldi:32 a, r3 ; 13movsi_internal/4[length = 6] ldi:8 #248, r1; 52movsi_internal/1[length = 2] extsb r1 ; 53extendqisi2 [length = 2] addnfp, r1 ; 16addsi_regs [length = 2] mov r1, r2 ; 74movsi_internal/5[length = 2] ld @r1, r1 ; 75movsi_internal/7[length = 2] addn4, r2 ; 76addsi_small_int/1 [length = 2] ld @r2, r2 ; 77movsi_internal/7[length = 2] st r1, @r3 ; 78movsi_internal/6[length = 2] mov r3, r0 ; 79movsi_internal/5[length = 2] addn4, r0 ; 80addsi_small_int/1 [length = 2] st r2, @r0 ; 81movsi_internal/6[length = 2] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug target/32130] [4.3 Regression] linking problems: multiple definition of `__DTOR_END__'
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-22 13:56 --- Alternative patch posted: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01161.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-14 16:02:11 |2007-11-22 13:56:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32130
[Bug testsuite/23610] obj-c++.dg/bitfield-[14].mm, obj-c++.dg/layout-1.mm fails with the GNU runtime
--- Comment #7 from danglin at gcc dot gnu dot org 2007-11-22 13:57 --- Currently, with the trunk on hppa64-hp-hpux11.11, we have an ICE: Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/obj-c++/../../g++ -B/test/ gnu/gcc/objdir/gcc/testsuite/obj-c++/../../ /test/gnu/gcc/gcc/gcc/testsuite/obj- c++.dg/bitfield-1.mm -nostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/lib stdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11 /libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc /gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/ut il -fmessage-length=0 -Wpadded -Wabi -I/test/gnu/gcc/gcc/gcc/testsuite/../../li bobjc-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -L /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -L/test/gnu/gc c/objdir/hppa64-hp-hpux11.11/./libiberty -L/test/gnu/gcc/objdir/hppa64-hp-hpux11 .11/./libobjc/.libs -lobjc -lm -o ./bitfield-1.exe(timeout = 300) In file included from /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:1 : /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:1: warning: padding str uct to align '::' /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:1: warning: padding str uct to align '::' /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:24: warning: padding st ruct size to alignment boundary /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:27: warning: padding st ruct size to alignment boundary /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:40: warning: padding st ruct size to alignment boundary /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:43: warning: padding st ruct size to alignment boundary /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:57: warning: padding st ruct size to alignment boundary /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:60: warning: padding st ruct size to alignment boundary /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:74: warning: padding st ruct size to alignment boundary /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:75: warning: padding st ruct size to alignment boundary /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:76: warning: padding st ruct size to alignment boundary /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:113: internal compiler error: tree check: expected tree that contains 'decl with RTL' structure, have ' field_decl' in assemble_external_real, at varasm.c:2220 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23610
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #7 from matz at suse dot de 2007-11-22 13:58 --- Subject: Re: [4.3 Regression] SCCVN breaks gettext Hi, On Thu, 22 Nov 2007, dberlin at dberlin dot org wrote: > Right, but this is the optimistic set of hash tables, so that is okay. I initially thought so too, but it really isn't. > At the end of SCC iteration, it is okay to keep optimistic > assumptions in the optimistic table, even if they turned out to be > wrong. It's okay only as long as you haven't proven them wrong. I.e. it's okay to have unproven but _consistent_ entries in the hash table. It is not okay to have inconsistent data in there, because it ripples through the whole SCC then. As in this case. > > ergo it enters (int)dest_9 into the hashtable, as having destptr.2_15 as > > value. I.e. (int)dest_9 == destptr.2_15. From there on everything breaks > > apart, because nobody is ever removing this association from the hash-table. > > In particular we still (wrongly) think that nitems_19 is zero. > > I don't see where above it has set nitems_19 to zero. I'll attach the complete dump. nitems_19 is zero because it is computed like so: Value numbering dest.3_16 stmt = dest.3_16 = (int) dest_9; Setting value number of dest.3_16 to destptr.2_15 Value numbering D.1214_17 stmt = D.1214_17 = destptr.2_15 - dest.3_16; RHS destptr.2_15 - dest.3_16 simplified to 0 has constants 0 Setting value number of D.1214_17 to 0 Value numbering D.1215_18 stmt = D.1215_18 = D.1214_17 /[ex] 8; RHS D.1214_17 /[ex] 8 simplified to 0 has constants 0 Setting value number of D.1215_18 to 0 Value numbering nitems_19 stmt = nitems_19 = (size_t) D.1215_18; RHS (size_t) D.1215_18 simplified to 0 has constants 0 Setting value number of nitems_19 to 0 So, because of the (in later passes invalid (!)) association of (int)dest_9 == destptr.2_15 --> D.1214_17 = destptr.2_15 - dest.3_16 == destptr.2_15 - destptr.2_15 == 0 --> D.1215_18 == 0 --> nitems_19 == 0 As the initial problem is the association of (int)dest_9 and destptr.2_15, and that stays in the hash table forever more we never notice that nitems_19 (and the other values in between) are _not_ zero. Not during the optimistic iterations at least. When we switch to valid_info (equivalent to deleting the hash table) we do notice that (we don't "discover" the invalid (int)dest_9 == destptr.2_15), nitems_19 isn't zero anymore. But nitems_19 happens to be traversed later than nitems_1 (later that nitems_20), so the now correct value of nitems_19 isn't used anymore. > There should be no need, as the fixpoint iteration of the optimistc > table should eventually end up with the values you want to insert into > the valid table. > That's in fact, the whole point. But as shown above it doesn't work that way. > > > so there has to be a way to either cleanup the hashtable after iterations > > (this also doesn't seem to be designed in this way), > > Again, it's okay for the optimistic assumptions to remain in the > table, and in fact, is designed for it to happen. > The paper goes into why this is so. The paper conveniently proves the algorithm which _deletes_ the hash table between iterations. And then handwaves over why it's also okay to not delete it. It's wrong. > No, this is also okay. > Again, it is fine for the optimistic hashtable to have invalid info. No, it's not. unproven but consistent is okay. provably false is not. > > version in it), but this canonicalization needs to happen when looking up > > the hash table, not when _inserting_ into it, as canonicalization is > > transient > > and changes from iteration to iteration. > > > Again, this isn't right. The paper goes into detail as to why it is > okay for the optimistic talbe to behave this way, It goes not. The RPO algorithm (the one proven) uses hash table deletes per iteration. About the SCC algorithm they have to say this: " º Â¥ «¤´ ¥¤ · § ¼´ ¯§¯ ¦ Â¥ © ± ¯§ ¥¤ · Â¥ ® ¯ ¸± ® ¤ « ª ¦ © § ¥¤ vc§1Y8Ey²cÂ|v(1¢Â¨d¾¨vÂÂ1c¦Yv6c§v1c© and why it is okay > to do algebraic simplification/etc on insert. > > The real problem seems to me, at least unless you guys haven't pasted > that part of the trace, that nitems_19 isn't part of the SCC but > should be. By the time iteration of the SCC finishes, we should have > discovered that nitems_19 does not have the value 0. > > The one in a real compiler I have of SCCVN both do canonicalization on > insert, as does the original code from Rice's massively scalar > compiler (which is where the algorithm comes from). > > Maybe we aren't traversing uses in function arguments during DFS walk? > > Given the code > > size_t new_max = nitems + len2; > > if (new_max != len2) > break; > dest = foo (new_max); > > destptr = dest; > wh
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-22 14:00 --- If you go through the SCCVN dump you realize that Michas analysis of the problem is correct btw: SCC consists of: nitems_21 nitems_1 new_max_9 dest_10 destptr_3 destptr.2_16 dest.3_17 D.1581_18 D.1582_19 nitems_20 destptr_15 Value numbering nitems_21 stmt = nitems_21 = PHI <0(2), nitems_20(9)> Setting value number of nitems_21 to 0 -- fine. nitems_20 is still VTOP --- Value numbering nitems_1 stmt = nitems_1 = PHI Setting value number of nitems_1 to 0 Value numbering new_max_9 stmt = new_max_9 = nitems_1 + len2_8; RHS nitems_1 + len2_8 simplified to len2_8 has constants 0 Setting value number of new_max_9 to len2_8 Value numbering dest_10 stmt = dest_10 = foo (new_max_9); Setting value number of dest_10 to dest_10 Value numbering destptr_3 stmt = destptr_3 = PHI Setting value number of destptr_3 to dest_10 --- also fine, destptr_15 is still VTOP --- Value numbering destptr.2_16 stmt = destptr.2_16 = (long int) destptr_3; Setting value number of destptr.2_16 to destptr.2_16 Value numbering dest.3_17 stmt = dest.3_17 = (long int) dest_10; Setting value number of dest.3_17 to destptr.2_16 Value numbering D.1581_18 stmt = D.1581_18 = destptr.2_16 - dest.3_17; RHS destptr.2_16 - dest.3_17 simplified to 0 has constants 0 Setting value number of D.1581_18 to 0 Value numbering D.1582_19 stmt = D.1582_19 = D.1581_18 /[ex] 8; RHS D.1581_18 /[ex] 8 simplified to 0 has constants 0 Setting value number of D.1582_19 to 0 Value numbering nitems_20 stmt = nitems_20 = (size_t) D.1582_19; RHS (size_t) D.1582_19 simplified to 0 has constants 0 Setting value number of nitems_20 to 0 --- also ok, this should be corrected later --- Value numbering destptr_15 stmt = destptr_15 = destptr_3 + 8; Setting value number of destptr_15 to destptr_15 --- now, destptr_15 is no longer VTOP! --- Value numbering nitems_21 stmt = nitems_21 = PHI <0(2), nitems_20(9)> Setting value number of nitems_21 to 0 Value numbering nitems_1 stmt = nitems_1 = PHI Setting value number of nitems_1 to 0 Value numbering new_max_9 stmt = new_max_9 = nitems_1 + len2_8; RHS nitems_1 + len2_8 simplified to len2_8 has constants 0 Setting value number of new_max_9 to len2_8 Value numbering dest_10 stmt = dest_10 = foo (new_max_9); Setting value number of dest_10 to dest_10 Value numbering destptr_3 stmt = destptr_3 = PHI Setting value number of destptr_3 to destptr_3 --- correct, destptr_3 is no longer dest_10 --- Value numbering destptr.2_16 stmt = destptr.2_16 = (long int) destptr_3; Setting value number of destptr.2_16 to destptr.2_16 Value numbering dest.3_17 stmt = dest.3_17 = (long int) dest_10; Setting value number of dest.3_17 to destptr.2_16 --- but whoops - why this? exactly because of the hashtable problem --- Value numbering D.1581_18 stmt = D.1581_18 = destptr.2_16 - dest.3_17; RHS destptr.2_16 - dest.3_17 simplified to 0 has constants 1 Setting value number of D.1581_18 to 0 Value numbering D.1582_19 stmt = D.1582_19 = D.1581_18 /[ex] 8; RHS D.1581_18 /[ex] 8 simplified to 0 has constants 1 Setting value number of D.1582_19 to 0 Value numbering nitems_20 stmt = nitems_20 = (size_t) D.1582_19; RHS (size_t) D.1582_19 simplified to 0 has constants 1 Setting value number of nitems_20 to 0 --- oh well - so we didn't correct nitems_20 to be non-null --- Value numbering destptr_15 stmt = destptr_15 = destptr_3 + 8; Setting value number of destptr_15 to destptr_15 Value numbering nitems_21 stmt = nitems_21 = PHI <0(2), nitems_20(9)> Setting value number of nitems_21 to 0 --- and thus now are converged to a wrong solution. --- Value numbering nitems_1 stmt = nitems_1 = PHI Setting value number of nitems_1 to 0 Value numbering new_max_9 stmt = new_max_9 = nitems_1 + len2_8; RHS nitems_1 + len2_8 simplified to len2_8 has constants 0 Setting value number of new_max_9 to len2_8 Value numbering dest_10 stmt = dest_10 = foo (new_max_9); Setting value number of dest_10 to dest_10 Value numbering destptr_3 stmt = destptr_3 = PHI Setting value number of destptr_3 to destptr_3 Value numbering destptr.2_16 stmt = destptr.2_16 = (long int) destptr_3; Setting value number of destptr.2_16 to destptr.2_16 Value numbering dest.3_17 stmt = dest.3_17 = (long int) dest_10; Setting value number of dest.3_17 to destptr.2_16 Value numbering D.1581_18 stmt = D.1581_18 = destptr.2_16 - dest.3_17; RHS destptr.2_16 - dest.3_17 simplified to 0 has constants 1 Setting value number of D.1581_18 to 0 Value numbering D.1582_19 stmt = D.1582_19 = D.1581_18 /[ex] 8; RHS D.1581_18 /[ex] 8 simplified to 0 has constants 1 Setting value number of D.1582_19 to 0 Value numbering nitems_20 stmt = nitems_20 = (size_t) D.1582_19; RHS (size_t) D.1582_19 simplified to 0 has constants 1 Setting value number of nitems_20 to 0 Value numbering destptr_15 stmt = destptr_15 = destptr_3 + 8; Setting value number of destptr_15 to destptr_15 --- no changes. Now the final run with the correct table --- Va
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug objc++/27247] FAIL: obj-c++.dg/cxx-ivars-2.mm execution test
--- Comment #1 from danglin at gcc dot gnu dot org 2007-11-22 14:01 --- Also now failing on hppa64-hp-hpux11.11. -- danglin at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa*-*-* (32-bit) |hppa*-*-* GCC host triplet|hppa*-*-* (32-bit) |hppa*-*-* GCC target triplet|hppa*-*-* (32-bit) |hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27247
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #9 from matz at suse dot de 2007-11-22 14:03 --- Subject: Re: [4.3 Regression] SCCVN breaks gettext [sorry for the breakage in last response] It does not. The RPO algorithm (the one proven) uses hash table deletes per iteration. About the SCC algorithm they have to say this: "Since we cannot remove the entries from the hash table after each pass as the RPO algorithm does, we will use two hash tables. The iterative phase uses an optimistic hash table. Once the value numbers in the SCC stabilize, entries are added to the valid table." Without proof that this actually has the same properties as the RPO algorithm. Had they gone through the hassle of trying to prove this they would have notived that it doesn't work. > > Maybe we aren't traversing uses in function arguments during DFS walk? No, that's not the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug c++/34094] [4.2/4.3 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-22 14:06 --- Subject: Bug 34094 Author: jakub Date: Thu Nov 22 14:06:06 2007 New Revision: 130351 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130351 Log: PR c++/34094 * decl2.c (cp_write_global_declarations): Issue error about static data members in anonymous namespace which are declared and used, but not defined. * g++.dg/ext/visibility/anon7.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/anon7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug objc++/32052] [4.3 Regression] encode-2.mm, encode-3.mm fail on at least powerpc-darwin
--- Comment #2 from danglin at gcc dot gnu dot org 2007-11-22 14:07 --- Also, see these on hppa64-hp-hpux11.11. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32052
[Bug c++/34094] [4.2 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-22 14:07 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 Regression]|[4.2 Regression] Undefined |Undefined static data member|static data member in |in anonymous namespace can |anonymous namespace can |acquire a definition anyway |acquire a definition anyway http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #10 from matz at gcc dot gnu dot org 2007-11-22 14:07 --- Created an attachment (id=14608) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14608&action=view) my dump (without patch) This is the dump I'm talking about. Richard uses a different compiler, so our SSA version numbers are sometimes different. But his above paste of the problematic part is as good as any, so this is just for completeness. Just with -O from the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug objc++/27232] encode-3.mm fails with "deprecated conversion" warning
--- Comment #2 from danglin at gcc dot gnu dot org 2007-11-22 14:08 --- Execution fails on hppa64-hp-hpux11.11. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27232
[Bug objc++/27249] FAIL: obj-c++.dg/encode-8.mm execution test
--- Comment #1 from danglin at gcc dot gnu dot org 2007-11-22 14:10 --- Also fails on hppa64. -- danglin at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa*-*-* (32-bit) |hppa*-*-* GCC host triplet|hppa*-*-* (32-bit) |hppa*-*-* GCC target triplet|hppa*-*-* (32-bit) |hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27249
[Bug objc++/34193] New: FAIL: obj-c++.dg/gnu-runtime-2.mm (test for excess errors)
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/obj-c++/../../g++ -B/test/ gnu/gcc/objdir/gcc/testsuite/obj-c++/../../ /test/gnu/gcc/gcc/gcc/testsuite/obj- c++.dg/gnu-runtime-2.mm -nostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/ libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11 .11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/ gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite /util -fmessage-length=0 -fgnu-runtime -I/test/gnu/gcc/gcc/gcc/testsuite/../../ libobjc -S -o gnu-runtime-2.s(timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/gnu-runtime-2.mm:25: error: second ar gument of 'int main(int, void**)' should be 'char **' compiler exited with status 1 output is: /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/gnu-runtime-2.mm:25: error: second ar gument of 'int main(int, void**)' should be 'char **' FAIL: obj-c++.dg/gnu-runtime-2.mm (test for excess errors) -- Summary: FAIL: obj-c++.dg/gnu-runtime-2.mm (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34193
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #11 from matz at gcc dot gnu dot org 2007-11-22 14:13 --- Btw. canonicalization/rewriting on INSERT is indeed okay. As long as the hash tables are deleted after every iteration (or otherwise invalidated). At least the now provably false information needs to be removed, which is a bit difficult to track when you do general rewriting, so invalidating the whole thing is probably easiest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug objc++/23616] obj-c++.dg/try-catch-[29].mm (objc exceptions are broken) fails with the GNU Runtime
--- Comment #9 from danglin at gcc dot gnu dot org 2007-11-22 14:18 --- Currently, obj-c++.dg/try-catch-9.mm fails with an ICE on hppa64-hp-hpux11.11: Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/obj-c++/../../g++ -B/test/ gnu/gcc/objdir/gcc/testsuite/obj-c++/../../ /test/gnu/gcc/gcc/gcc/testsuite/obj- c++.dg/try-catch-9.mm -nostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/li bstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.1 1/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gc c/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/u til -fmessage-length=0 -fobjc-exceptions -O2 -I/test/gnu/gcc/gcc/gcc/testsuite/ ../../libobjc -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/. libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -L/tes t/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libiberty -L/test/gnu/gcc/objdir/hppa64-h p-hpux11.11/./libobjc/.libs -lobjc -lm -o ./try-catch-9.exe(timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/try-catch-9.mm: In function '(static initializers for /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/try-catch-9.mm)': /test/gnu/gcc/gcc/gcc/testsuite/obj-c++.dg/try-catch-9.mm:65: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in set up_one_parameter, at tree-inline.c:1485 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23616
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #26 from dje at gcc dot gnu dot org 2007-11-22 14:52 --- Shall we declare that we won't backport the changes and close the bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug middle-end/34130] [4.1/4.2 Regression] the builtin abs() gives wrong result when used in some expression
--- Comment #5 from doko at gcc dot gnu dot org 2007-11-22 15:34 --- Subject: Bug 34130 Author: doko Date: Thu Nov 22 15:34:03 2007 New Revision: 130352 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130352 Log: 2007-11-22 Matthias Klose <[EMAIL PROTECTED]> Backport from mainline: 2007-11-17 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/34130 * fold-const.c (extract_muldiv_1): Do not move negative constants inside ABS_EXPR. PR middle-end/34130 * gcc.c-torture/execute/pr34130.c: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr34130.c - copied unchanged from r130258, trunk/gcc/testsuite/gcc.c-torture/execute/pr34130.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/fold-const.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34130
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #13 from dberlin at gcc dot gnu dot org 2007-11-22 15:35 --- Subject: Re: [4.3 Regression] SCCVN breaks gettext On 22 Nov 2007 14:03:35 -, matz at suse dot de <[EMAIL PROTECTED]> wrote: > > > --- Comment #9 from matz at suse dot de 2007-11-22 14:03 --- > Subject: Re: [4.3 Regression] SCCVN breaks > gettext > > [sorry for the breakage in last response] > > It does not. The RPO algorithm (the one proven) uses hash table deletes > per iteration. About the SCC algorithm they have to say this: > > "Since we cannot remove the entries from the hash table after each pass as > the RPO algorithm does, we will use two hash tables. The iterative phase > uses an optimistic hash table. Once the value numbers in the SCC > stabilize, entries are added to the valid table." > > Without proof that this actually has the same properties as the RPO > algorithm. Had they gone through the hassle of trying to prove this they > would have notived that it doesn't work. Of course it does. The only reason it wouldn't work is if you store side info that you don't replace after SCC iteration. It is quite careful to reset the value of has_constants/etc when necessary (at least it was when i was done :P). The RPO algorithm keeps invalid info about things all the time, and by deleting it at the end of each iteration, just gets it replaced by later more valid info. The SCC algorithm should be doing the same thing. The reason is leaves info is the same reason the RPO algorithm doesn't delete info after value numbering a given value for a given iteration, but instead leaves it until the end of the iteration (which means it will get invalid info for the iteration for a lot of values). There is a longer version of the paper that actually goes through the formal proofs somewhere, i'll find it for you. In the meanwhile, i'm just going to fix the bug. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug tree-optimization/33869] [4.3 Regression] ICE verify_ssa failed (missing definition for SSA_NAME)
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-11-22 15:32 --- I cannot reproduce this with # g++ -c -O3 t.ii -v Using built-in specs. Target: ia64-suse-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3.0 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --with-system-libunwind --build=ia64-suse-linux Thread model: posix gcc version 4.3.0 20071109 (experimental) [trunk revision 130038] (SUSE Linux) COLLECT_GCC_OPTIONS='-O3' '-v' '-c' '-o' 't.o' '-shared-libgcc' neither with the original nor with the reduced testcase. Martin, can you confirm that this is fixed? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING GCC target triplet||ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
[Bug tree-optimization/34195] New: missed optimization with store motion (vectorizer)
The following loop does not get vectorized
on powerpc64-linux, r130275, GCC 4.3.0:
#define M 10
struct S
{
float x;
float y;
} pS[100];
float a[1000];
float b[1000];
void
foo (int n)
{
int i, j;
for (i = 0; i < n; i++)
{
pS[i].x = 0;
pS[i].y = 0;
for (j = 0; j < M; j++)
{
pS[i].x += (a[i]+b[i]);
pS[i].y += (a[i]-b[i]);
}
}
}
Here is a snippet from the vectorizer dump file:
u3.c:17: note: dependence distance modulo vf == 0 between pS[i_37].x and
pS[i_37].x
u3.c:17: note: dependence distance = 0.
u3.c:17: note: accesses have the same alignment.
u3.c:17: note: dependence distance modulo vf == 0 between pS[i_37].y and
pS[i_37].y
u3.c:17: note: === vect_analyze_data_ref_accesses ===
u3.c:17: note: Detected interleaving of size 2
u3.c:17: note: not vectorized: complicated access pattern.
u3.c:17: note: bad data access.(get_loop_exit_condition
...
base_address: &pS
offset from base address: () ((unsigned int) i_37 *
8)
constant offset from base address: 0
step: 0
aligned to: 8
base_object: pS[0].x
symbol tag: pS
FAILED as dr address is invariant
u3.c:22: note: not vectorized: unhandled data-ref
u3.c:22: note: bad data references.
u3.c:14: note: vectorized 0 loops in function.
[Zdenek's patch which extends lim can help to do store motion and thus help to
the vectorizer - http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02331.html, but
AFAICT it is not applicable to current mainline)]
--
Summary: missed optimization with store motion (vectorizer)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34195
[Bug tree-optimization/33869] [4.3 Regression] ICE verify_ssa failed (missing definition for SSA_NAME)
--- Comment #16 from rguenther at suse dot de 2007-11-22 15:24 --- Subject: Re: [4.3 Regression] ICE verify_ssa failed (missing definition for SSA_NAME) On Thu, 22 Nov 2007, dorit at gcc dot gnu dot org wrote: > --- Comment #15 from dorit at gcc dot gnu dot org 2007-11-22 15:17 > --- > (In reply to comment #12) > ... > > > Richard, is this related to the issue you reported in > > > http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01127.html > > > (looks like the same error)? > ... > > Yes, these are likely similar problems. The only difference I see is > > that this one doesn't involve unions? > > Richard, any chance you could take a look? (I'm asking just cause it sounds > like you've had recent experience at looking at potentially exactly this kind > of problem...)? Well, the only non-nice thing with this report is that it involves IA64... (and no, it doesn't reproduce on x86_64 or i686) I'll try to have a look. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
[Bug tree-optimization/33319] [4.2 regression] g++.dg/tree-ssa/pr27549.C ICE with vectorization
--- Comment #14 from dorit at gcc dot gnu dot org 2007-11-22 15:22 --- closed, given recent feedback -- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
[Bug tree-optimization/33869] [4.3 Regression] ICE verify_ssa failed (missing definition for SSA_NAME)
--- Comment #15 from dorit at gcc dot gnu dot org 2007-11-22 15:17 --- (In reply to comment #12) ... > > Richard, is this related to the issue you reported in > > http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01127.html > > (looks like the same error)? ... > Yes, these are likely similar problems. The only difference I see is > that this one doesn't involve unions? Richard, any chance you could take a look? (I'm asking just cause it sounds like you've had recent experience at looking at potentially exactly this kind of problem...)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
[Bug tree-optimization/33869] [4.3 Regression] ICE verify_ssa failed (missing definition for SSA_NAME)
--- Comment #14 from dorit at gcc dot gnu dot org 2007-11-22 15:14 --- (In reply to comment #13) > Dorit, can you please take a look again? I will not be able to look into this in the next couple of weeks, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #12 from rguenther at suse dot de 2007-11-22 15:08 --- Subject: Re: [4.3 Regression] SCCVN breaks gettext On Thu, 22 Nov 2007, matz at gcc dot gnu dot org wrote: > --- Comment #11 from matz at gcc dot gnu dot org 2007-11-22 14:13 --- > Btw. canonicalization/rewriting on INSERT is indeed okay. As long as the hash > tables are deleted after every iteration (or otherwise invalidated). At least > the now provably false information needs to be removed, which is a bit > difficult to track when you do general rewriting, so invalidating the whole > thing is probably easiest. Though in the paper they state that they'd want to use the optimistic hashtable entries for further SCC processing. In which case you'd either have to invalidate only those entries you added during the current iteration or maybe instead of invalidating it, initialize it with the correct table contents. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug fortran/34194] New: problem with NEAREST intrinsic function
PROGRAM test WRITE(*,*) NEAREST(0.d0,1.d0) END >> gfortran test.f90 t.f90:3.21: WRITE(*,*) NEAREST(0.d0,1.d0) 1 Error: Result of NEAREST underflows its kind at (1) -- Summary: problem with NEAREST intrinsic function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: francois dot jacq at irsn dot fr GCC host triplet: Linux i686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34194
[Bug tree-optimization/34017] [4.2/4.3 Regression] ICE in lambda_loopnest_to_gcc_loopnest with -O2 -ftree-loop-linear
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-22 15:19 ---
On the simplified:
extern int s;
void
foo (int *x, int y, int z)
{
int m, n;
int o;
int p = x[0];
o = s;
for (m = 0; m < s; m++)
for (n = 0; n < s; n++)
{
if (x[n] != p)
continue;
if (m > z)
z = m;
if (n < o)
o = n;
}
for (m = y; m <= z; m++)
{
}
}
at -O2 -ftree-loop-linear, it fails everywhere I tried, on x86_64-linux with
both -m{32,64}, on i686-linux, on sparc64-linux with -m{32,64} and on
ppc64-linux
with -m{32,64}.
:
# o_42 = PHI
# n_40 = PHI
# z_35 = PHI
D.1559_19 = (long unsigned int) n_40;
D.1560_20 = D.1559_19 * 4;
D.1561_21 = x_11(D) + D.1560_20;
D.1562_22 = *D.1561_21;
if (D.1562_22 != p_12)
goto ;
else
goto ;
:
z_17 = MAX_EXPR ;
if (n_40 < o_42)
goto ;
else
goto ;
:
:
# o_8 = PHI
# z_2 = PHI
n_25 = n_40 + 1;
if (o_13 > n_25)
goto ;
else
goto ;
This is with IV n_40, oldiv_stmt is # n_40 = PHI and one
of the immediate uses is # o_8 = PHI
That could have been perhaps transformed into a MIN_EXPR, but unlike the
MAX_EXPR phiopt1 has not done that, because there weren't just 2 incoming
edges, but 3 (where two used one value and the third different one).
I don't see justification for the assert that none of the immediate uses of
the IV is a PHI_NODE - it can certainly happen and while it can be harder to
fix up, perhaps involving adding some statements on edges, it is nothing
that should prevent the transformations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34017
[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)
--- Comment #32 from jakub at gcc dot gnu dot org 2007-11-22 15:52 --- Or alternatively make sure to gimplify all inputs which allow reg or mem first, then gimplify those that don't allow either, which for -O0 should hopefully mean all such expressions stay in the same basic block as the asm and then if (!optimize) in expand_gimple_basic_block look at asm inputs and if some of them doesn't allow mem nor reg and is gimple register, walk back to find definitions within the bb and reconstruct the expression (kind of very lame TER alternative) and stop whenever some of the used gimple reg definitions can't be found, or once it is not TREE_CONSTANT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug fortran/34194] problem with NEAREST intrinsic function
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-22 15:53 --- *** This bug has been marked as a duplicate of 34192 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34194
[Bug fortran/34192] problem with NEAREST intrinsic function
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-22 15:53 --- *** Bug 34194 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34192
[Bug tree-optimization/33869] [4.3 Regression] ICE verify_ssa failed (missing definition for SSA_NAME)
--- Comment #18 from tbm at cyrius dot com 2007-11-22 15:58 --- (In reply to comment #17) > neither with the original nor with the reduced testcase. Martin, can you > confirm that this is fixed? Works for me with 20071116 too. I just checked again and the problem is there with 20071020. Should we ask Janis to find out what fixed this issue to see whether it's really fixed or just latent, or simply close the bug? -- tbm at cyrius dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
[Bug target/34174] gcc produces erroneous asm for movdi
--- Comment #9 from markus dot heigl at fme dot fujitsu dot com 2007-11-22 15:59 --- Seems to work for this testcase. I think the else path of if (reverse) should also be changed in the same way. Do you agree? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug tree-optimization/34195] missed optimization with store motion (vectorizer)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-22 16:01 --- Actually the refined patch at http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02550.html should be more up-to-date. Still the idea of an alias oracle needs to be done elsewhere. We'll be working on it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34195
[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)
--- Comment #31 from jakub at gcc dot gnu dot org 2007-11-22 15:41 ---
Could we perhaps for !optimize allow in ASM input operands arbitrary
tree expressions if TREE_CONSTANT for operands which !allows_mem &&
!allows_reg?
Then we'd just need to make sure the few -O0 passes are able to cope with it
and adjust gimplifier to do that and verification to accept that.
For -O0 expecting
int i = 1;
asm ("" :: "i" (i));
to work is certainly bad assumption, so it is enough to preserve what the user
used in the inline asm. I guess only nesting and omp passes would care, those
can transform a valid "i" operand into invalid one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug tree-optimization/33869] [4.3 Regression] ICE verify_ssa failed (missing definition for SSA_NAME)
--- Comment #19 from rguenther at suse dot de 2007-11-22 16:09 --- Subject: Re: [4.3 Regression] ICE verify_ssa failed (missing definition for SSA_NAME) On Thu, 22 Nov 2007, tbm at cyrius dot com wrote: > --- Comment #18 from tbm at cyrius dot com 2007-11-22 15:58 --- > (In reply to comment #17) > > neither with the original nor with the reduced testcase. Martin, can you > > confirm that this is fixed? > > Works for me with 20071116 too. > > I just checked again and the problem is there with 20071020. Should we > ask Janis to find out what fixed this issue to see whether it's really > fixed or just latent, or simply close the bug? I'd simply close the bug. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
[Bug c++/34196] New: [4.3 Regression] uninitialized variable warning in dead exception region
#include
template class AutoPtr {
_Tp* _M_ptr;
public:
explicit AutoPtr(_Tp* __p = 0) : _M_ptr(__p) {}
~AutoPtr() { delete _M_ptr; }
_Tp* operator->() const {
return _M_ptr;
}
};
struct A {
virtual ~A();
virtual A * unserialise(const std::string &s) const = 0;
};
A * wtx;
void
func(const std::string & s)
{
AutoPtr wt(wtx->unserialise(s.c_str()));
}
g++ -O -Wuninitialized -c remoteserver.cc
remoteserver.cc: In function 'void func(const std::string&)':
remoteserver.cc:9: warning: 'wt.AutoPtr::_M_ptr' is used uninitialized in
this function
remoteserver.cc:26: note: 'wt.AutoPtr::_M_ptr' was declared here
because in the late uninitalized variable pass we discover
:;
save_filt.37_16 = <<>>;
save_eptr.36_17 = <<>>;
if (wt$_M_ptr_40(D) != 0B)
goto ;
else
goto ;
:
D.13202_23 = wt$_M_ptr_40(D)->_vptr.A;
D.13203_24 = D.13202_23 + 8;
D.13204_25 = *D.13203_24;
OBJ_TYPE_REF(D.13204_25;wt$_M_ptr_40(D)->1) (wt$_M_ptr_40(D));
which hasn't been deleted here. 4.2 was either able to delete these BBs
or didn't create this exception region.
--
Summary: [4.3 Regression] uninitialized variable warning in dead
exception region
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34196
[Bug fortran/34192] [4.2, 4.3 Regression] NEAREST can return wrong numbers
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-22 16:27 --- Seemingly the problem was introduced by the following patch, which fixed another NEAREST problem. http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00249.html http://gcc.gnu.org/viewcvs?view=rev&revision=117584 2006-10-09 Steven G. Kargl <[EMAIL PROTECTED]> [...] PR fortran/15441 PR fortran/29312 [...] * simplify.c (gfc_simplify_nearest): Remove explicit subnormalization. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-22 16:27:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34192
[Bug fortran/34192] [4.2, 4.3 Regression] NEAREST can return wrong numbers
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-22 16:11 --- I believe there is indeed a bug in gfortran. The standard says that the "the nearest different machine-representable number" is returned. However, gfortran returns a number which is not representable (denormal or smaller?) and rounded to zero (= same number). Result (gfortran 4.3.0): a) The program is wrongly rejected b) With -fno-range-check, the wrong number is used. For the example the dump shows: static real(kind=8) C.859 = 0.0; The expected result is some denormal number like: 5.E-324, 4.9406564584124654E-324, 2.225073858507201E-308, 4.94065645841246544E-324, 4.940656458412465E-324. (The ifort result of 2e-308 looks wrong in this regard as there is a nearer number.) gfortran 4.1.3 returns: 4.940656458412465E-324 gfortran 4.2.2 rejects it and has an ICE with -fno-range-check Besides fixing this bug, we should also consider mentioning -fno-range-check in the error message. (Though, in this case -fno-range-check would have concealed the real bug.) The Fortran 2003 standard states: "NEAREST (X, S) Description. Returns the nearest different machine-representable number in a given direction. X shall be of type real. S shall be of type real and not equal to zero. Result Characteristics. Same as X. Result Value. The result has a value equal to the machine-representable number distinct from X and nearest to it in the direction of the infinity with the same sign as S. NOTE 13.16 Unlike other floating-point manipulation functions, NEAREST operates on machine-representable numbers rather than model numbers. On many systems there are machine-representable numbers that lie between adjacent model numbers." -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org OtherBugsDependingO||32834 nThis|| GCC host triplet|Linux i686 | Keywords||rejects-valid, wrong-code Known to fail||4.2.2 4.3.0 Known to work||4.1.3 Summary|problem with NEAREST|[4.2, 4.3 Regression] |intrinsic function |NEAREST can return wrong ||numbers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34192
[Bug tree-optimization/23305] [4.0/4.1/4.2/4.3 Regression] Inlining related regression for gcc-4.x
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-22 16:41 --- On x86_64-linux -m64 with -O2 gcc doesn't hoist movabsq insns out of the loops, which can give some performance back: time ./pr23305-slow real0m4.028s user0m4.023s sys 0m0.003s time ./pr23305-slow2 real0m3.436s user0m3.434s sys 0m0.001s when I hoist it by hand in assembly: --- pr23305-slow.s 2007-11-22 17:14:09.0 +0100 +++ pr23305-slow2.s 2007-11-22 17:31:31.0 +0100 @@ -222,16 +222,16 @@ _Z13s05a_testv: .LVL2: .LBB329: .LBB330: .loc 1 28697 0 cmpq%rax, %rdx je .L13 + movabsq $4613937818241073152, %r8 .p2align 4,,10 .p2align 3 .L14: - movabsq $4613937818241073152, %r8 movq%r8, (%rax) addq$8, %rax cmpq%rax, %rdx jne .L14 .L13: .LBE330: @@ -242,17 +242,17 @@ _Z13s05a_testv: .LVL3: .LBB326: .LBB327: .loc 1 28697 0 cmpq%rax, %rdx je .L15 + movabsq $4613937818241073152, %rdi .p2align 4,,10 .p2align 3 .L16: .LBE327: - movabsq $4613937818241073152, %rdi movq%rdi, (%rax) .LBB328: addq$8, %rax cmpq%rax, %rdx jne .L16 .L15: but still the -O2 -fno-inline-small-functions version is much faster: time ./pr23305-fast real0m1.591s user0m1.588s sys 0m0.001s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23305
[Bug tree-optimization/23305] [4.0/4.1/4.2/4.3 Regression] Inlining related regression for gcc-4.x
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-22 16:11 --- On the trunk there is no difference between -O2 and -O2 -finline-functions (the latter is perhaps 1% better), both are as bad as 4.1/4.2 with -O2 -finline-functions. Compiling with -O2 -fno-inline-small-functions gives the speed back. Both x86_64-linux and i686-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23305
[Bug tree-optimization/33869] [4.3 Regression] ICE verify_ssa failed (missing definition for SSA_NAME)
--- Comment #20 from tbm at cyrius dot com 2007-11-22 16:12 --- The failure is gone. -- tbm at cyrius dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
[Bug tree-optimization/23305] [4.0/4.1/4.2/4.3 Regression] Inlining related regression for gcc-4.x
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-22 17:04 ---
The remaining difference is register allocation issue:
time ./pr23305-vanilla; time ./pr23305-fixed
real0m4.030s
user0m4.028s
sys 0m0.002s
real0m1.593s
user0m1.592s
sys 0m0.001s
with hand-edited changes:
--- pr23305-vanilla.s 2007-11-22 17:57:15.0 +0100
+++ pr23305-fixed.s 2007-11-22 17:57:56.0 +0100
@@ -95,49 +95,49 @@ _Z13s05a_testv:
subq$24, %rsp
.LCFI1:
movq_ZL3dpe(%rip), %rdx
movq_ZL3dpb(%rip), %rax
cmpq%rax, %rdx
je .L13
+ movabsq $4613937818241073152, %r8
.p2align 4,,10
.p2align 3
.L14:
- movabsq $4613937818241073152, %r8
movq%r8, (%rax)
addq$8, %rax
cmpq%rax, %rdx
jne .L14
.L13:
movq_ZL3Dpe(%rip), %rdx
movq_ZL3Dpb(%rip), %rax
cmpq%rax, %rdx
je .L15
+ movabsq $4613937818241073152, %rdi
.p2align 4,,10
.p2align 3
.L16:
- movabsq $4613937818241073152, %rdi
movq%rdi, (%rax)
addq$8, %rax
cmpq%rax, %rdx
jne .L16
.L15:
movq_ZL5rrDPe(%rip), %rdx
movq_ZL5rrDPb(%rip), %rax
movsd _ZL1D(%rip), %xmm0
cmpq%rdx, %rax
movsd %xmm0, 8(%rsp)
je .L18
+ movsd 8(%rsp), %xmm0
.p2align 4,,10
.p2align 3
.L24:
- movsd 8(%rsp), %xmm0
addsd (%rax), %xmm0
addq$8, %rax
cmpq%rax, %rdx
- movsd %xmm0, 8(%rsp)
jne .L24
+ movsd %xmm0, 8(%rsp)
.L18:
movsd 8(%rsp), %xmm0
ucomisd .LC2(%rip), %xmm0
jp .L23
jne .L23
addq$24, %rsp
In lreg dump we have:
(code_label:HI 98 35 97 7 24 "" [1 uses])
(note:HI 97 98 45 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
(insn:HI 45 97 46 7 pr23305.ii:28564 (set (reg/v:DF 64 [ result ])
(plus:DF (reg/v:DF 64 [ result ])
(mem/s:DF (reg:DI 58 [ ivtmp.254 ]) [29 .value+0 S8
A8]))) 680 {*fop_df_comm_sse} (nil))
(insn:HI 46 45 48 7 pr23305.ii:28564 (parallel [
(set (reg:DI 58 [ ivtmp.254 ])
(plus:DI (reg:DI 58 [ ivtmp.254 ])
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) 244 {*adddi_1_rex64} (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn:HI 48 46 49 7 pr23305.ii:28673 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/f:DI 60 [ last$current$current$current ])
(reg:DI 58 [ ivtmp.254 ]))) 2 {cmpdi_1_insn_rex64} (nil))
(jump_insn:HI 49 48 50 7 pr23305.ii:28673 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref:DI 98)
(pc))) 579 {*jcc_1} (expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_BR_PROB (const_int 9100 [0x238c])
(nil
and
Register 64 pref SSE_FIRST_REG, else SSE_REGS
Register 64 used 5 times across 23 insns; set 2 times; user var; crosses 3
calls; pref SSE_FIRST_REG, else SSE_REGS.
Yet global alloc puts it into 8(%rsp), which is certainly fine, except in a the
tight loop.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23305
[Bug fortran/34192] [4.2, 4.3 Regression] NEAREST can return wrong numbers
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-22 17:08 ---
Regarding the range check: We need to disable the check for denormal numbers;
as overflow etc. cannot occur, this boils down to check only for NaN.
Regarding the result, I think we have a problem with MPFR. The following
program prints:
Result (GMP_RNDN): 0
Result (GMP_RNDU): 4.94066e-324
As mpfr_nexttoward should return a representable number, there should be no
rounding needed, or should it? By the way, changing GFC_REAL_8_DIGITS did not
change the result.
See also:
http://www.mpfr.org/mpfr-2.3.0/mpfr.html#index-mpfr_005fnexttoward-224
#include
#include
#include
#define GFC_REAL_8_DIGITS 53
int main()
{
mpfr_t x;
mpfr_t y;
int base2prec;
double result;
mpfr_set_default_prec (GFC_REAL_8_DIGITS);
mpfr_init(x);
mpfr_init(y);
mpfr_set_d (x, 0.0, GMP_RNDN); /* x = 0.0 */
mpfr_set_inf (y, 1); /* y = INF */
mpfr_nexttoward (x, y);/* x = x + epsilon */
printf("Result (GMP_RNDN): %g\n", mpfr_get_d(x, GMP_RNDN));
printf("Result (GMP_RNDU): %g\n", mpfr_get_d(x, GMP_RNDU));
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34192
[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)
--- Comment #33 from stsp at users dot sourceforge dot net 2007-11-22
17:27 ---
> For -O0 expecting
> int i = 1;
> asm ("" :: "i" (i));
> to work is certainly bad assumption
Btw, even the
static const int i = 1;
asm ("" :: "i" (i));
doesn't work with both -O0 and -O1. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug fortran/34192] [4.2, 4.3 Regression] NEAREST can return wrong numbers
--- Comment #5 from burnus at gcc dot gnu dot org 2007-11-22 18:05 --- Hmm, this does not seem to be easily possible in MPFR. http://websympa.loria.fr/wwsympa/arc/mpfr/2007-11/msg00026.html Possible implementation (as of 2005) by Tobias Schlüter: http://gcc.gnu.org/ml/fortran/2005-04/msg00389.html Steve writes to my MPFR email of today: | This is a point I had not fully appreciated when I patched | gfc_simplify_nearest. Try restoring the code that I removed. | I don't remember why I removed the code, although I suspect | that range_check function should properly handle subnormal | numbers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34192
[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2007-11-22 18:45 --- Created an attachment (id=14611) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14611&action=view) assembly file generated from testsub.f on i386-redhat-linux (Fedora 8) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug c/34197] array overflow warning without line number
--- Comment #1 from marcus at jet dot franken dot de 2007-11-22 18:48 --- Created an attachment (id=14612) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14612&action=view) relay16.i testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34197
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #21 from patchapp at dberlin dot org 2007-11-22 19:00 --- Subject: Bug number PR16350 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00362.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug fortran/34079] Bind(C): Character argument/return value problems
--- Comment #10 from patchapp at dberlin dot org 2007-11-22 19:01 --- Subject: Bug number PR34079 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01109.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079
[Bug c/23722] bad error recovery with if blocks and else
--- Comment #3 from patchapp at dberlin dot org 2007-11-22 19:02 --- Subject: Bug number PR c/23722 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01159.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23722
[Bug fortran/34187] BIND(C): Public generic with private bind(c) specific does not use bind(C) name
--- Comment #2 from patchapp at dberlin dot org 2007-11-22 19:03 --- Subject: Bug number PR34187 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01165.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34187
[Bug fortran/34192] [4.2, 4.3 Regression] NEAREST can return wrong numbers
--- Comment #7 from kargl at gcc dot gnu dot org 2007-11-22 19:00 --- (In reply to comment #6) > Created an attachment (id=14609) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14609&action=view) [edit] > Patch (reverted Rev 117584) plus test case > > Initial implementation by reverting Rev. 117584 as suggested by Steve. > > Problems: > - nearest(x,-1) for negative denormal x does not give a smaller number > - returned values are not the smallest possible: > 4.9406564584124654E-324 vs. 1.11253692925360069E-308 > 1.4012985E-45 vs. 5.87747175E-39 To fix this problem, I believe that you need to set emin to emin - prec + 1 Something like + mpfr_set_emin ((mp_exp_t) (gfc_real_kinds[sgn].min_exponent - gfc_real_kinds[sgn].digit + 1)); It might be a -1. IIRC, mpfr always stores a normalized significand, so you need to play with emin to properly account for gradual underflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34192
[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2007-11-22 18:54 --- Created an attachment (id=14614) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14614&action=view) assembly file generated from testbd.f on i386-redhat-linux (Fedora 8) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-11-22 18:42 --- Created an attachment (id=14610) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14610&action=view) assembly file generated from testsub.f on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug c/34197] array overflow warning without line number
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-22 19:28 --- The expression warned about is call_5(D)->ret[5] and I suspect the mapped locations make the location information wrong. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-22 19:28:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34197
[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2007-11-22 18:55 --- Added assembly files from testbd.f for i386-redhat-linux and i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2007-11-22 18:53 --- Created an attachment (id=14613) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14613&action=view) assembly file generated from testbd.f on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug c/34197] New: array overflow warning without line number
LANG=C /home/marcus/projects/gcc/BIN/bin/gcc -c -O2 -Wall -g -o xx.o relay16.i -m32 relay16.i: In function 'f': cc1: warning: array subscript is above array bounds -m32 seems necessary -- Summary: array overflow warning without line number Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: i586-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34197
