[Bug tree-optimization/24659] Conversions are not vectorized
--- Comment #14 from ubizjak at gmail dot com 2007-05-17 07:45 --- Altivec PPC has int->float cvt insn and provides signed/unsigned vec_unpack v8hi insn. It should be trivial to implement short->float and unsigned short->float conversions by providing vec_unpacks_float_lo_v8hi, vec_unpacks_float_hi_v8hi, vec_unpacku_float_lo_v8hi and vec_unpacku_float_hi_v8hi patterns (please look into i386/sse.md file). By providing these patterns, loops in gcc.dg/vect/vect-intfloat-conversion-4a.c and gcc.dg/vect/vect-intfloat-conversion-4b.c should be vectorized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24659
[Bug tree-optimization/31966] Miscompiles valid code with -ftree-vectorize and -march=nocona
--- Comment #1 from lloyd at randombit dot net 2007-05-17 07:36 --- Created an attachment (id=13567) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13567&action=view) A short testcase for bug 31966 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
[Bug tree-optimization/31966] New: Miscompiles valid code with -ftree-vectorize and -march=nocona
$ gcc-4.2.0 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.2.0/configure --enable-languages=c,c++,objc,obj-c++ --program-suffix=-4.2.0 Thread model: posix gcc version 4.2.0 $ gcc-4.2.0 divop.c -o divop $ ./divop 3CBA83 $ gcc-4.2.0 -ftree-vectorize -O2 divop.c -o divop $ ./divop 3CBA83 $ gcc-4.2.0 -ftree-vectorize -O2 -march=opteron divop.c -o divop $ ./divop 3CBA83 $ gcc-4.2.0 -ftree-vectorize -O2 -march=nocona divop.c -o divop $ ./divop 2B672F This also affects GCC 4.1.1, I have not checked 4.1.2 or the 4.3 snapshots. In addition to -march=nocona it requires -O1/-O2/-O3 (-Os does not trigger it under 4.2.0, though it _does_ in 4.1.1). -- Summary: Miscompiles valid code with -ftree-vectorize and - march=nocona Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lloyd at randombit dot net GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
[Bug tree-optimization/24659] Conversions are not vectorized
--- Comment #13 from uros at gcc dot gnu dot org 2007-05-17 07:31 --- Subject: Bug 24659 Author: uros Date: Thu May 17 06:31:05 2007 New Revision: 124784 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124784 Log: PR tree-optimization/24659 * optabs.h (enum optab_index): Add OTI_vec_unpacks_float_hi, OTI_vec_unpacks_float_lo, OTI_vec_unpacku_float_hi, OTI_vec_unpacku_float_lo, OTI_vec_pack_sfix_trunc and OTI_vec_pack_ufix_trunc. (vec_unpacks_float_hi_optab): Define new macro. (vec_unpacks_float_lo_optab): Ditto. (vec_unpacku_float_hi_optab): Ditto. (vec_unpacku_float_lo_optab): Ditto. (vec_pack_sfix_trunc_optab): Ditto. (vec_pack_ufix_trunc_optab): Ditto. * genopinit.c (optabs): Implement vec_unpack[s|u]_[hi|lo]_optab and vec_pack_[s|u]fix_trunc_optab using vec_unpack[s|u]_[hi\lo]_* and vec_pack_[u|s]fix_trunc_* patterns * tree-vectorizer.c (supportable_widening_operation): Handle FLOAT_EXPR and CONVERT_EXPR. Update comment. (supportable_narrowing_operation): New function. * tree-vectorizer.h (supportable_narrowing_operation): Prototype. * tree-vect-transform.c (vectorizable_conversion): Handle (nunits_in == nunits_out / 2) and (nunits_out == nunits_in / 2) cases. (vect_gen_widened_results_half): Move before vectorizable_conversion. (vectorizable_type_demotion): Call supportable_narrowing_operation() to check for target support. * optabs.c (optab_for_tree_code) Return vec_unpack[s|u]_float_hi_optab for VEC_UNPACK_FLOAT_HI_EXPR, vec_unpack[s|u]_float_lo_optab for VEC_UNPACK_FLOAT_LO_EXPR and vec_pack_[u|s]fix_trunc_optab for VEC_PACK_FIX_TRUNC_EXPR. (expand_binop): Special case mode of the result for vec_pack_[u|s]fix_trunc_optab. (init_optabs): Initialize vec_unpack[s|u]_[hi|lo]_optab and vec_pack_[u|s]fix_trunc_optab. * tree.def (VEC_UNPACK_FLOAT_HI_EXPR, VEC_UNPACK_FLOAT_LO_EXPR, VEC_PACK_FIX_TRUNC_EXPR): New tree codes. * tree-pretty-print.c (dump_generic_node): Handle VEC_UNPACK_FLOAT_HI_EXPR, VEC_UNPACK_FLOAT_LO_EXPR and VEC_PACK_FIX_TRUNC_EXPR. (op_prio): Ditto. * expr.c (expand_expr_real_1): Ditto. * tree-inline.c (estimate_num_insns_1): Ditto. * tree-vect-generic.c (expand_vector_operations_1): Ditto. * config/i386/sse.md (vec_unpacks_float_hi_v8hi): New expander. (vec_unpacks_float_lo_v8hi): Ditto. (vec_unpacku_float_hi_v8hi): Ditto. (vec_unpacku_float_lo_v8hi): Ditto. (vec_unpacks_float_hi_v4si): Ditto. (vec_unpacks_float_lo_v4si): Ditto. (vec_pack_sfix_trunc_v2df): Ditto. * doc/c-tree.texi (Expression trees) [VEC_UNPACK_FLOAT_HI_EXPR]: Document. [VEC_UNPACK_FLOAT_LO_EXPR]: Ditto. [VEC_PACK_FIX_TRUNC_EXPR]: Ditto. * doc/md.texi (Standard Names) [vec_pack_sfix_trunc]: Document. [vec_pack_ufix_trunc]: Ditto. [vec_unpacks_float_hi]: Ditto. [vec_unpacks_float_lo]: Ditto. [vec_unpacku_float_hi]: Ditto. [vec_unpacku_float_lo]: Ditto. testsuite/ChangeLog: PR tree-optimization/24659 * gcc.dg/vect/vect-floatint-conversion-2.c: New test. * gcc.dg/vect/vect-intfloat-conversion-1.c: Require vect_float, not vect_int target. * gcc.dg/vect/vect-intfloat-conversion-2.c: Require vect_float, not vect_int target. Loop is vectorized for vect_intfloat_cvt targets. * gcc.dg/vect/vect-intfloat-conversion-3.c: New test. * gcc.dg/vect/vect-intfloat-conversion-4a.c: New test. * gcc.dg/vect/vect-intfloat-conversion-4b.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-floatint-conversion-2.c trunk/gcc/testsuite/gcc.dg/vect/vect-intfloat-conversion-3.c trunk/gcc/testsuite/gcc.dg/vect/vect-intfloat-conversion-4a.c trunk/gcc/testsuite/gcc.dg/vect/vect-intfloat-conversion-4b.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/doc/c-tree.texi trunk/gcc/doc/md.texi trunk/gcc/expr.c trunk/gcc/genopinit.c trunk/gcc/optabs.c trunk/gcc/optabs.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-intfloat-conversion-1.c trunk/gcc/testsuite/gcc.dg/vect/vect-intfloat-conversion-2.c trunk/gcc/tree-inline.c trunk/gcc/tree-pretty-print.c trunk/gcc/tree-vect-generic.c trunk/gcc/tree-vect-transform.c trunk/gcc/tree-vectorizer.c trunk/gcc/tree-vectorizer.h trunk/gcc/tree.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24659
[Bug c++/29927] template instantiation with function type
--- Comment #7 from s__nakayama at infoseek dot jp 2007-05-17 06:04 --- Fixed already in 4.2.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29927
[Bug tree-optimization/31953] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:305
--- Comment #3 from ian at airs dot com 2007-05-17 05:02 --- Created an attachment (id=13566) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13566&action=view) Proposed patch I'm testing this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31953
[Bug fortran/31964] ishftc fails with certain thrid argument
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-05-17 04:00 --- The patch in comment #3 is incorrect. I have the correct patch coming and will post to list for approval. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #2 from danglin at gcc dot gnu dot org 2007-05-17 03:55 --- Test case also fails to compile on hppa64-hp-hpux11.11. Compiler hangs in cse1 pass, apparently doing garbage collection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug target/30153] -fPIC failure
--- Comment #2 from price at ifa dot hawaii dot edu 2007-05-17 03:19
---
This is also a problem on my amd64 Gentoo laptop, using gcc version Gentoo
4.1.1-r3.
I searched the binutils Bugzilla, but could not find a bug filed for this
problem.
Because the problem disappears when optimisation is turned on, the following
line from the docs for gcc caught my eye: "GCC does not inline any functions
when not optimizing unless you specify the `always_inline' attribute for the
function". So I tried:
[EMAIL PROTECTED]:/home/price/test>cat static_inline.c
static void foo (void) __attribute__((always_inline));
static inline void foo (void) { }
void baz (void (*f) (void));
void bar (void) { baz (foo); }
[EMAIL PROTECTED]:/home/price/test>gcc -O0 -g -c -fPIC static_inline.c
[EMAIL PROTECTED]:/home/price/test>gcc -shared -o static_inline.so
static_inline.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
warning: creating a DT_TEXTREL in object.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
static_inline.o: relocation R_X86_64_PC32 against `foo' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status
Should I take this bug over to binutils?
--
price at ifa dot hawaii dot edu changed:
What|Removed |Added
CC||price at ifa dot hawaii dot
||edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30153
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #49 from manu at gcc dot gnu dot org 2007-05-17 02:52 --- (In reply to comment #48) > Created an attachment (id=13561) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13561&action=view) [edit] > patch for testsuite infrastructure > > This patch overrides dg-error and dg-warning if gcc_error_prefix and > gcc_warning_prefix are defined; it defines those for C. > Hi Janis, I think we could independently commit the chunk that adds dg-message. That way we could fix the testcases that need such directive. For example, gcc.dg/cpp/19940712-1.c (fix-19940712-1.diff). Also, people could start using it for messages that are neither warnings nor errors. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug target/31965] _INTEGRAL_MAX_BITS defined incorrectly
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-17 02:42 --- It was added with: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00979.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31965
[Bug target/31965] New: _INTEGRAL_MAX_BITS defined incorrectly
The macro _INTEGRAL_MAX_BITS is a defined as a builtin macro with an incorrect value on mingw32. This Microsoft C specific macro is supposed to report "the maximum size (in bits) for an integral type". In GCC's case this would be 64, the size of a long long, not 32 as it currently defines the macro. (Perhaps the real problem is that this macro is defined at all. It's specific to the Microsoft C/C++ compiler and not part of the Windows API.) -- Summary: _INTEGRAL_MAX_BITS defined incorrectly Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rridge at csclub dot uwaterloo dot ca GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31965
[Bug fortran/31964] ishftc fails with certain thrid argument
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-17 01:49 --- I think we have an off by one when setting mask. I want to do some testing and double check on all this. Here is a patch: Index: ishftc.c === *** ishftc.c(revision 124756) --- ishftc.c(working copy) *** ishftc4 (GFC_INTEGER_4 i, GFC_INTEGER_4 *** 45,51 if (shift == 0 || shift == size) return i; ! mask = (~(GFC_INTEGER_4)0) << size; bits = i & ~mask; return (i & mask) | (bits >> (size - shift)) | ((i << shift) & ~mask); } --- 45,51 if (shift == 0 || shift == size) return i; ! mask = (~(GFC_INTEGER_4)0) << (size - 1); bits = i & ~mask; return (i & mask) | (bits >> (size - shift)) | ((i << shift) & ~mask); } *** ishftc8 (GFC_INTEGER_8 i, GFC_INTEGER_4 *** 65,71 if (shift == 0 || shift == size) return i; ! mask = (~(GFC_INTEGER_8)0) << size; bits = i & ~mask; return (i & mask) | (bits >> (size - shift)) | ((i << shift) & ~mask); } --- 65,71 if (shift == 0 || shift == size) return i; ! mask = (~(GFC_INTEGER_8)0) << (size - 1); bits = i & ~mask; return (i & mask) | (bits >> (size - shift)) | ((i << shift) & ~mask); } *** ishftc16 (GFC_INTEGER_16 i, GFC_INTEGER_ *** 86,92 if (shift == 0 || shift == size) return i; ! mask = (~(GFC_INTEGER_16)0) << size; bits = i & ~mask; return (i & mask) | (bits >> (size - shift)) | ((i << shift) & ~mask); } --- 86,92 if (shift == 0 || shift == size) return i; ! mask = (~(GFC_INTEGER_16)0) << (size - 1); bits = i & ~mask; return (i & mask) | (bits >> (size - shift)) | ((i << shift) & ~mask); } -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-17 01:30:46 |2007-05-17 01:49:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
[Bug fortran/31964] ishftc fails with certain thrid argument
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-17 01:30 --- $ gfc shifter.f90 $ ./a.out 32 2 1 1 $ ifort shifter.f90 $ ./a.out 32 2 2 2 $ -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-17 01:30:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
[Bug fortran/31833] FAIL: gfortran.dg/integer_exponentiation_3.F90 at -O0 and above
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-17 01:30 --- Subject: Re: FAIL: gfortran.dg/integer_exponentiation_3.F90 at -O0 and above > All I have access to is hppa2.0w-hp-hpux11.23, do you think it would be > triggered there also? Probably, since HP has pretty much frozen library support on hppa. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31833
[Bug fortran/31964] ishftc fails with certain thrid argument
--- Comment #1 from kargl at gcc dot gnu dot org 2007-05-17 00:51 --- What output were you expecting? write(*,*) ishftc(aint,1) write(*,*) ishftc(aint,1,32) write(*,*) ishftc(aint,1,BIT_SIZE(aint)) All three of these statements are shifting the 32-bit representation of of 1 to left and wrapping the 1 shifted bit around. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #77 from mark at codesourcery dot com 2007-05-17 00:41 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should ian at airs dot com wrote: > I don't believe that the C++ standards writers really meant to eliminate > TBAA. > And that is the inevitable consequence of the dynamic memory type approach if > you are allowed to change the dynamic type in a function. I agree with Ian. I think there is good evidence that the authors of the standard intended C++ to be *more* typesafe than C, and we should read the standard in that way. It's unfortunate that neither the C or C++ standards is very precise about various aspects of the memory model, but that is what it is. I think trying to read the standard to divine the answers to these questions is essentially futile; this is a situation where we should accept that the standard doesn't say, and do our best to balance performance with existing practice and expectations. I don't fully understand the point of Comment #73. I thought the whole point of this series of patches was to make the compiler understand that memory returned by placement new could alias other memory, or to otherwise introduce a barrier that would prevent the compiler from reordering accesses across the call to operator new. If that's the case, why does the post-patch compiler still think that the writes to "f" and "l" don't alias? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/31745] [4.3 regression] ICE on invalid use of namespace
--- Comment #1 from patchapp at dberlin dot org 2007-05-17 00:05 --- Subject: Bug number PR c++/31745 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01091.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31745
[Bug c++/31948] SH- Mathematical Error handling is no working for valid code
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:49 --- sqrt is part of glibc so report it there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31948
[Bug c/31955] gcc-4.2.0.tar.bz2 is missing INSTALL html files
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:45 --- *** Bug 31958 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31955
[Bug c/31958] gcc-4.2.0.tar.bz2 is missing INSTALL html files
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:45 --- *** This bug has been marked as a duplicate of 31955 *** -- 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=31958
[Bug fortran/31964] New: ishftc fails with certain thrid argument
If the third argument of ishftc equals BIT_SIZE of the first argument, the result shall be the same as if the last argument was omitted. program main implicit none integer aint aint=1 write(*,*) BIT_SIZE(aint) write(*,*) ishftc(aint,1) write(*,*) ishftc(aint,1,32) write(*,*) ishftc(aint,1,BIT_SIZE(aint)) end program main Produces the following wrong output: 32 2 2 2 /tmp/forttest3 $ gfortran -v Using built-in specs. Target: i386-pc-linux-gnu Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure --prefix=/home/fxcoudert/gfortran_nightbuild/irun-20070426 --enable-languages=c,fortran --disable-decimal-float --build=i386-pc-linux-gnu --enable-checking=release --with-gmp=/home/fxcoudert/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20070426 (experimental) -- Summary: ishftc fails with certain thrid argument Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trumsko at yahoo dot com GCC build triplet: i686-redhat-linux-gnu GCC host triplet: i686-redhat-linux-gnu GCC target triplet: i686-redhat-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
[Bug c++/31951] local structure problem
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:16 --- This is not a bug, local classes cannot be template arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31951
[Bug middle-end/31490] Compile error section type conflict
--- Comment #9 from dtemirbulatov at gmail dot com 2007-05-16 22:47 ---
This patch fixes both testcases
--- gcc/varasm.c.orig 2007-05-16 21:32:11.0 +0400
+++ gcc/varasm.c2007-05-16 21:36:14.0 +0400
@@ -5762,12 +5762,14 @@ categorize_decl_for_section (tree decl,
be read-only or not, but whether the dynamic link will have to
do something. If so, we wish to segregate the data in order to
minimize cache misses inside the dynamic linker. */
- if (reloc & targetm.asm_out.reloc_rw_mask ())
+ if (reloc & targetm.asm_out.reloc_rw_mask ()
+ && !lookup_attribute ("section", DECL_ATTRIBUTES (decl)))
ret = reloc == 1 ? SECCAT_DATA_REL_LOCAL : SECCAT_DATA_REL;
else
ret = SECCAT_DATA;
}
- else if (reloc & targetm.asm_out.reloc_rw_mask ())
+ else if (reloc & targetm.asm_out.reloc_rw_mask ()
+ && !lookup_attribute ("section", DECL_ATTRIBUTES (decl)))
ret = reloc == 1 ? SECCAT_DATA_REL_RO_LOCAL : SECCAT_DATA_REL_RO;
else if (reloc || flag_merge_constants < 2)
/* C and C++ don't allow different variables to share the same
, bootstraped and tested on i686-pc-linux-gnu with no new regressions, tested
4.2 version with gdb-sim on following architectures arm-elf, arm-none-eabi,
mips-elf, mipsisa64-elf, powerpc-eabisim, sh-elf, powerpc-unknown-eabispe with
no new regressions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #15 from dannysmith at users dot sourceforge dot net 2007-05-16 21:34 --- (In reply to comment #13) > Subject: Re: Compile errors with multiple inheritance where > the stdcall attribute is applied to virtual functions. > > rridge at csclub dot uwaterloo dot ca wrote: > > --- Comment #11 from rridge at csclub dot uwaterloo dot ca 2007-05-08 > > 12:25 --- > > MSC includes the calling convention as part of its C++ name mangling. Would > > this bug be easier to solve if the calling convention was also included as > > part > > of the C++ name mangling in GCC, instead of done afterwards? If so, it > > might > > be worth this small ABI breaking change in some future release of MinGW. > > I think that would be fine, from a C++ perspective. > Patch to this effect (without ABI breakage) at: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01046.html and a demangled version (ie, as an attachment) of above at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01047.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug c++/31961] Premature hiding of symbols makes a copy constructor shooting at its own foot
--- Comment #2 from waldemar dot rachwal at googlemail dot com 2007-05-16 21:13 --- Subject: Re: Premature hiding of symbols makes a copy constructor shooting at its own foot Hey, Maybe I don't catch your "process", but #31961 and #31960 both refer to the same (identical) text of mine. I'm pretty sure I commited only *once*. WR. On 16 May 2007 18:47:57 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:47 > --- > > > *** This bug has been marked as a duplicate of 31960 *** > > > -- > > 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=31961 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31961
[Bug java/30591] Cross build fails because native gcj needed to build ecjx
--- Comment #6 from daney at gcc dot gnu dot org 2007-05-16 21:10 --- Marking as FIXED as it now works for me *if* I use a current native GCC to build the cross compiler. I am prepering a documentation patch that explains my interpretation of the requirements. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30591
[Bug c++/31954] template function cannot create object of forward declared class
--- Comment #2 from fang at csl dot cornell dot edu 2007-05-16 20:56
---
I concur. If you want to forcibly delay the dependence on the complete type
until instantiation time, you could use a nested typedef in the class template,
like:
class NonDependent;
template
struct foo {
typedef NonDependent Bar;
};
class NonDependent { ... };
and then in members of foo, refer to "typename foo::Bar".
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
CC||fang at csl dot cornell dot
||edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31954
[Bug fortran/31879] ICE with function having array of character variables argument
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 20:55 ---
This fixes it and much more besides. It needs commenting and tidying up.
Paul
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (révision 124762)
--- gcc/fortran/trans-array.c (copie de travail)
*** gfc_trans_dummy_array_bias (gfc_symbol *
*** 4243,4248
--- 4243,4315
}
+ static void
+ gfc_fixup_missing_charlen (gfc_se *se, gfc_expr *expr)
+ {
+ tree tmp;
+ gfc_ref *char_ref = expr->ref;
+
+ expr->ts.cl = gfc_get_charlen ();
+ expr->ts.cl->next = gfc_current_ns->cl_list;
+ gfc_current_ns->cl_list = expr->ts.cl;
+ expr->ts.cl->backend_decl
+ = gfc_create_var (gfc_charlen_type_node, "cl");
+
+ for (; char_ref; char_ref = char_ref->next)
+ if (char_ref->type == REF_SUBSTRING)
+ {
+ mpz_t char_len;
+
+ mpz_init_set_ui (char_len, 1);
+ mpz_add (char_len, char_len,
+ char_ref->u.ss.end->value.integer);
+ mpz_sub (char_len, char_len,
+ char_ref->u.ss.start->value.integer);
+ tmp = gfc_conv_mpz_to_tree (char_len,
+ gfc_default_character_kind);
+ /* Cast is necessary for *-charlen refs. */
+ tmp = convert (gfc_charlen_type_node, tmp);
+
+ gfc_add_modify_expr (&se->pre, expr->ts.cl->backend_decl, tmp);
+ mpz_clear (char_len);
+ break;
+ }
+
+ if (char_ref == NULL)
+ {
+ mpz_t length;
+ tmp = NULL_TREE;
+
+ if (expr->expr_type == EXPR_CONSTANT)
+ mpz_init_set_si (length, expr->value.character.length);
+ else if (expr->expr_type == EXPR_ARRAY)
+ mpz_init_set_si (length,
+ expr->value.constructor->expr->value.character.length);
+ else if (expr->expr_type == EXPR_OP)
+ {
+ if (!expr->value.op.op1->ts.cl)
+ gfc_fixup_missing_charlen (se, expr->value.op.op1);
+ if (!expr->value.op.op2->ts.cl)
+ gfc_fixup_missing_charlen (se, expr->value.op.op2);
+ tmp = fold_build2 (PLUS_EXPR, gfc_charlen_type_node,
+expr->value.op.op1->ts.cl->backend_decl,
+expr->value.op.op2->ts.cl->backend_decl);
+ }
+ else
+ mpz_init_set_ui (length, 0);
+
+ if (!tmp)
+ {
+ tmp = gfc_conv_mpz_to_tree (length,
+ gfc_default_character_kind);
+ tmp = convert (gfc_charlen_type_node, tmp);
+ }
+
+ gfc_add_modify_expr (&se->pre, expr->ts.cl->backend_decl, tmp);
+ }
+ }
+
+
/* Convert an array for passing as an actual argument. Expressions and
vector subscripts are evaluated and stored in a temporary, which is then
passed. For whole arrays the descriptor is passed. For array sections
*** gfc_conv_expr_descriptor (gfc_se * se, g
*** 4430,4463
{
if (expr->ts.cl == NULL)
{
! /* This had better be a substring reference! */
! gfc_ref *char_ref = expr->ref;
! for (; char_ref; char_ref = char_ref->next)
! if (char_ref->type == REF_SUBSTRING)
! {
! mpz_t char_len;
! expr->ts.cl = gfc_get_charlen ();
! expr->ts.cl->next = char_ref->u.ss.length->next;
! char_ref->u.ss.length->next = expr->ts.cl;
!
! mpz_init_set_ui (char_len, 1);
! mpz_add (char_len, char_len,
!char_ref->u.ss.end->value.integer);
! mpz_sub (char_len, char_len,
!char_ref->u.ss.start->value.integer);
! expr->ts.cl->backend_decl
! = gfc_conv_mpz_to_tree (char_len,
! gfc_default_character_kind);
! /* Cast is necessary for *-charlen refs. */
! expr->ts.cl->backend_decl
! = convert (gfc_charlen_type_node,
! expr->ts.cl->backend_decl);
! mpz_clear (char_len);
! break;
! }
! gcc_assert (char_ref != NULL);
loop.temp_ss->data.temp.type
! = gfc_typenode_for_spec (&expr->ts);
loop.temp_ss->string_length = expr->ts.cl->backend_decl;
}
else if (expr->ts.cl->length
--- 4497,4505
{
if (expr->ts.cl == NULL)
{
! gfc_fixup_missing_charlen (se, expr);
loop.temp_ss->data.temp.type
! = gfc_typenode_for_spec (&expr->ts);
loop.temp_ss->string_length = expr->ts.cl->backend_decl;
}
else if (expr->ts.cl->length
--
pault at gcc dot gnu dot org changed:
What|Removed
[Bug c++/31952] parameters may be redeclared in a function try-block
--- Comment #1 from fang at csl dot cornell dot edu 2007-05-16 20:46 --- Poor man's workaround: -Wshadow -Werror -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31952
[Bug middle-end/31738] Fortran dot product vectorization is restricted
--- Comment #3 from dorit at il dot ibm dot com 2007-05-16 20:45 --- (In reply to comment #2) > Here is what happens in the three loops that don't get vectorized: > (1) the loop in testvectdp2: ... > so the vectorizer is ok, except that in this case D.1437_32 doesn't seem to > > be used anywhere in the function, so this stmt looks dead to me, but for > some reason it is not cleaned away before the vectorizer... Still need to > investigate why. So looks like the stmt D.1437_32 = prephitmp.192_37 became dead by pass pr31738a.f90.089t.copyprop3. So the question is what's the most appropriate fix: (1) fix copyprop3 to also clean away any dead code it creates? (2) add a dce pass after copyprop3? (3) work around it in the vectorizer. I think it should be easy - just move the check of the uses of the reduction in the loop until after the vectorizer analysis pass that marks relevant stmts. If (3) sounds like the way to go - I can prepare a patch for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31738
[Bug middle-end/31950] [4.3 Regression] ICE in tree-ssa-alias-warnings.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-16 20:07 --- *** Bug 31962 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=31950
[Bug c/31962] ice for legal code with -Wall -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-16 20:07 --- *** This bug has been marked as a duplicate of 31950 *** -- 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=31962
[Bug target/30486] segfault in aggregate_value_p while bootstrapping fortran
--- Comment #2 from pbrook at gcc dot gnu dot org 2007-05-16 20:05 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01010.html -- pbrook at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30486
[Bug c++/31961] Premature hiding of symbols makes a copy constructor shooting at its own foot
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:47 --- *** This bug has been marked as a duplicate of 31960 *** -- 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=31961
[Bug c++/31960] Premature hiding of symbols makes a copy constructor shooting at its own foot
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:47 --- *** Bug 31961 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31960
[Bug bootstrap/31963] The configure option "--enable-stage1-checking" is undocumented (and incorrectly named)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:43 --- > When I compile with "--enable-checking=?" the "checking" is performed on > stages 2,3 and the libraries - it is NOT performed on stage 1. I filed a bug about this while back and it was fixed, see PR 29544. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31963
[Bug driver/31963] New: The configure option "--enable-stage1-checking" is undocumented (and incorrectly named)
This bug report is listed for the HTB i686-pc-linux-gnu but actually affects ALL platforms. The reason I chose to put this under the "Component" choice "driver" is because there is no choice for "documentation" and it does involve renaming one of the compiler command line options. --- When I compile with "--enable-checking=?" the "checking" is performed on stages 2,3 and the libraries - it is NOT performed on stage 1. When I compile with "--enable-stage1-checking" the "checking" is performed on stage TWO only, and NOT on any other stages (or the libraries). To _actually_ check stage 1 you would need the Operating System's GCC to have been compiled using the checking options - otherwise stage 1 is never checked. Correct ? BUG 1): The configure option "--enable-stage1-checking" is named incorrectly. We need to change the configure script and make it a depreciated or obsoleted option and add an option that is instead called "--enable-stage2-checking" (does the same thing, just correct the name). BUG 2): The configure option "--enable-stage1-checking" (or "--enable-stage2-checking") is not documented. Using grep I find the word in these files: # grep -r stage1-checking gcc-4_2-branch/* gcc-4_2-branch/ChangeLog gcc-4_2-branch/autom4te.cache/output.0 gcc-4_2-branch/configure gcc-4_2-branch/configure.in The file "gccinstall.info" (and any .html DOCs) and the files that create them are the correct location to document this feature - directly under the notes for "--enable-checking". Suggestion 1): Use "--enable-stage2-checking" to enable a few more checks by default. The gccinstall.info file says this for the `--enable-checking' option: The full set of flags available are: "assert", "fold", "gc", "gcac" "misc", "rtl", "rtlflag", "runtime", "tree", and "valgrind". The "rtl", "gcac" and "valgrind" checks are very expensive. (NOTE: See below! "fold" is expensive - DOCs are wrong?) When building from SVN or snapshots we use "assert", "gc", "misc", "rtlflag", "runtime" and "tree". The release versions use only "assert" and "runtime". Thus, according to the DOCs (which do need updating), when we build the SVN we are not using: "fold", "gcac" "rtl", and "valgrind". I suggest that when building the SVN version we could use, (on all stages), the flags "--enable-checking=assert,misc,rtlflag,runtime,tree", and the additional flag (now called) "--enable-stage2-checking=fold,gc,rtl" for better, faster checking. Would we want to add "misc" and "rtlflag" to the release version checks ? The gcac (GC_ALWAYS_COLLECT) flag could probably be left off the list. The file, "gcc-4_2-branch\gcc\config.in" documents checking a little differently (and each type more thoroughly) than the file "gccinstall.info" does. ENABLE_ASSERT_CHECKING - "assert" /* Define if you want assertions enabled. This is a cheap check. */ ENABLE_CHECKING - "misc" /* Define if you want more run-time sanity checks. This one gets a grab bag of miscellaneous but relatively cheap checks. */ ENABLE_FOLD_CHECKING- "fold" /* Define if you want fold checked that it never destructs its argument. This is quite expensive. */ ENABLE_GC_ALWAYS_COLLECT- "gcac" /* Define if you want the garbage collector to operate in maximally paranoid mode, validating the entire heap and collecting garbage at every opportunity. This is extremely expensive. */ ENABLE_GC_CHECKING - "gc" /* Define if you want the garbage collector to do object poisoning and other memory allocation checks. This is quite expensive. */ ENABLE_RTL_CHECKING - "rtl" /* Define if you want all operations on RTL (the basic data structure of the optimizer and back end) to be checked for dynamic type safety at runtime. This is quite expensive. */ ENABLE_RTL_FLAG_CHECKING- "rtlflag" /* Define if you want RTL flag accesses to be checked against the RTL codes that are supported for each access macro. This is relatively cheap. */ ENABLE_RUNTIME_CHECKING - "runtime" /* Define if you want runtime assertions enabled. This is a cheap check. */ ENABLE_TREE_CHECKING- "tree" /* Define if you want all operations on trees (the basic data structure of the front ends) to be checked for dynamic type safety at runtime. This is moderately expensive. The tree browser debugging routines will also be enabled by this option. */ ENABLE_VALGRIND_CHECKING- "valgrind" /* Define if you want to run subprograms and generated programs through valgrind (a memory checker). This is extremely expensive. */ -- Summary: The configure option "--enable-stage1-checking" is undocumented (and incorrectly named) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: driver A
[Bug c/31962] ice for legal code with -Wall -O2
--- Comment #1 from dcb314 at hotmail dot com 2007-05-16 19:34 --- Created an attachment (id=13565) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13565&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31962
[Bug c/31962] New: ice for legal code with -Wall -O2
I just tried to compile Suse Linux package icecream-0.7.14a-5 with the GNU C compiler version 4.3 snapshot 20070511 The compiler said minilzo.c: In function '_lzo_config_check': minilzo.c:2162: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'struct_field_tag' in ffan_walker, at tree-ssa-alias-warnings.c:638 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Pre-processed source code attached. Flags -Wall -O2 required. -- Summary: ice for legal code with -Wall -O2 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: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31962
[Bug c++/31961] New: Premature hiding of symbols makes a copy constructor shooting at its own foot
When I create an object using copy constructor syntax, giving it other object
of that type and (crucial) the same name as the object just being
constructed... the compiler treats that "other" object as the object being
constructed(!) Similar effects I get with the builtin data types.
Below is the short program demonstrating this (IMO) weird behavior with
associated embedded Makefile and two sample outputs (#if 0--commented).
I couldn't find anything about this issue in the standard (draft), but thinking
about it deeper since yesterday I couldn't discover any reasonable
*application* of such a semantic assuming it was valid. Similar effects with
builtin data types may be a dangerous trap for programmers. At least it's very
unsafe.
Even if g++ gives at last warnings, they appear only when I've added (sic!)
-O1, -O2... options which should have had nothing with the problem encountered
(note that in all my tests I tend to use -Wall -Wextra -pedantic -ansi as a
basis).
On the other hand, in oppose to semantics/behavior I observe with g++, I have
the strong rationale for semantics I expect (in case the standard says nothing
or leave it up to compiler implementators).
I get the problem with 4.1.1 on Solaris, with 3.4.4 on Cygwin as well, so I
think it might be quite general problem (if not solved yet).
Regards,
WR.
code snippet:
// premature-hiding.cpp
// SUBJECT:
// Premature hiding of symbols makes copy constructor shooting at its own
foot.
// SYNOPSIS:
// void fun (Seq& seq) // <- (o)uter symbol
// {
// Seq seq(seq);// symbols legend: (i)nner, (o)uter
// // ^i ^o // **EXPECTED**
// // ^i ^i // *G++ACTUAL** :(
// ...
// }
#include
using namespace std;
class X {
public:
X ();
// In my original application I intentionally use non-const argument,
// but here I put const variant, because:
// 1) both give the same result, and
// 2) const one looks more severe, as usually assiociated with "copying".
explicit X (const X& rhs);
~X ();
private:
int dummy;
};
inline X::X ()
{
cout << "this ==> " << this << endl;
}
inline X::X (const X& rhs)
{
cout << "&rhs ++> " << &rhs << endl;
cout << "this oo> " << this << endl;
}
X::~X ()
{
cout << "~obj ~~> " << this << endl;
}
int main ()
{
// Weird behavior is observed already
// when dealing with simple builtin types.
cout << endl << "// int n = n + 1;" << endl;
int n = n + 1;
cout << "n ==> " << n << endl;
cout << endl << "// double r = r + 1000.0;" << endl;
double r = r + 1000.0;
cout << "r ==> " << r << endl;
//
// auto object(s)
//
cout << endl << "// X obj;" << endl;
{
// Object 'obj' defined. It should be visible by code that follows.
X obj;
cout << "// X obj(obj);" << endl;
{
// Object of the same name defined in nested scope
// is expected to be properly "chained" with the parent object
// of the outer scope.
// Unfortunately it doesn't happen :( and GCC
// allows an object being constructed to "copy" over itself.
// It looks the symbol is introduced to symbol table
// on '(' paren, but should be on ')'.
// The latter (IMO proper) approach should only compile
// if there is a symbol of that name already defined
// somewhere earlier (not necessarily in nested {} as in my
example)
// and lexically visible.
X obj(obj); // <* UNEXPECTED BEHAVIOR
cout << "// X obj(obj);" << endl;
{
// Trying the same on the next (3rd in turn) level...
X obj(obj); // <* UNEXPECTED BEHAVIOR (as above)
}
}
}
//
// heap object(s)
//
cout << endl << "// X *ptr = new X(*ptr);" << endl;
X *ptr = new X(*ptr);
delete ptr;
return 0;
}
#if 0 // # Makefile ##
CXX = g++
CXXFLAGS = -g -Wall -Wextra -pedantic -ansi $(EXTFLAGS)
program := premature-hiding
$(program): $(program).cpp Makefile
$(CXX) -o $@ $(CXXFLAGS) $<
run: $(program)
@./$(program)
clean:
-rm $(program) $(program).exe *.o *.s *.ii
#endif
#if 0 // # examining flags ###
make -B CXXFLAGS= # clean compile, initial surprise
make -B # clean too(!!), big surprise
make -B EXTFLAGS='-O1' # warnings, but compiles (why it has anything with -O1
?!)
#endif
#if 0 // # g++ (GCC) 4.1.1 [sun4u] ###
// int n = n + 1;
n ==> 67481
// double r = r + 1000.0;
r ==> 1.96794e+307
// X obj;
this ==> 0xffbfefc8
// X obj(obj);
&rhs ++> 0xffbfefc4 <** UNEXPECTED
this oo> 0xffbfefc4
// X obj(obj);
&rhs ++> 0xffbfefc0 <** UNEXPECTED
this oo> 0xffbfefc0
~obj ~~> 0xffbfefc0
~obj ~~> 0xffbfe
[Bug c++/31954] template function cannot create object of forward declared class
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 18:23 --- I don't think this is a bug. C0 is not dependent so it has to be complete when the new is parsed in the template. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31954
[Bug c++/31960] New: Premature hiding of symbols makes a copy constructor shooting at its own foot
When I create an object using copy constructor syntax, giving it other object
of that type and (crucial) the same name as the object just being
constructed... the compiler treats that "other" object as the object being
constructed(!) Similar effects I get with the builtin data types.
Below is the short program demonstrating this (IMO) weird behavior with
associated embedded Makefile and two sample outputs (#if 0--commented).
I couldn't find anything about this issue in the standard (draft), but thinking
about it deeper since yesterday I couldn't discover any reasonable
*application* of such a semantic assuming it was valid. Similar effects with
builtin data types may be a dangerous trap for programmers. At least it's very
unsafe.
Even if g++ gives at last warnings, they appear only when I've added (sic!)
-O1, -O2... options which should have had nothing with the problem encountered
(note that in all my tests I tend to use -Wall -Wextra -pedantic -ansi as a
basis).
On the other hand, in oppose to semantics/behavior I observe with g++, I have
the strong rationale for semantics I expect (in case the standard says nothing
or leave it up to compiler implementators).
I get the problem with 4.1.1 on Solaris, with 3.4.4 on Cygwin as well, so I
think it might be quite general problem (if not solved yet).
Regards,
WR.
code snippet:
// premature-hiding.cpp
// SUBJECT:
// Premature hiding of symbols makes copy constructor shooting at its own
foot.
// SYNOPSIS:
// void fun (Seq& seq) // <- (o)uter symbol
// {
// Seq seq(seq);// symbols legend: (i)nner, (o)uter
// // ^i ^o // **EXPECTED**
// // ^i ^i // *G++ACTUAL** :(
// ...
// }
#include
using namespace std;
class X {
public:
X ();
// In my original application I intentionally use non-const argument,
// but here I put const variant, because:
// 1) both give the same result, and
// 2) const one looks more severe, as usually assiociated with "copying".
explicit X (const X& rhs);
~X ();
private:
int dummy;
};
inline X::X ()
{
cout << "this ==> " << this << endl;
}
inline X::X (const X& rhs)
{
cout << "&rhs ++> " << &rhs << endl;
cout << "this oo> " << this << endl;
}
X::~X ()
{
cout << "~obj ~~> " << this << endl;
}
int main ()
{
// Weird behavior is observed already
// when dealing with simple builtin types.
cout << endl << "// int n = n + 1;" << endl;
int n = n + 1;
cout << "n ==> " << n << endl;
cout << endl << "// double r = r + 1000.0;" << endl;
double r = r + 1000.0;
cout << "r ==> " << r << endl;
//
// auto object(s)
//
cout << endl << "// X obj;" << endl;
{
// Object 'obj' defined. It should be visible by code that follows.
X obj;
cout << "// X obj(obj);" << endl;
{
// Object of the same name defined in nested scope
// is expected to be properly "chained" with the parent object
// of the outer scope.
// Unfortunately it doesn't happen :( and GCC
// allows an object being constructed to "copy" over itself.
// It looks the symbol is introduced to symbol table
// on '(' paren, but should be on ')'.
// The latter (IMO proper) approach should only compile
// if there is a symbol of that name already defined
// somewhere earlier (not necessarily in nested {} as in my
example)
// and lexically visible.
X obj(obj); // <* UNEXPECTED BEHAVIOR
cout << "// X obj(obj);" << endl;
{
// Trying the same on the next (3rd in turn) level...
X obj(obj); // <* UNEXPECTED BEHAVIOR (as above)
}
}
}
//
// heap object(s)
//
cout << endl << "// X *ptr = new X(*ptr);" << endl;
X *ptr = new X(*ptr);
delete ptr;
return 0;
}
#if 0 // # Makefile ##
CXX = g++
CXXFLAGS = -g -Wall -Wextra -pedantic -ansi $(EXTFLAGS)
program := premature-hiding
$(program): $(program).cpp Makefile
$(CXX) -o $@ $(CXXFLAGS) $<
run: $(program)
@./$(program)
clean:
-rm $(program) $(program).exe *.o *.s *.ii
#endif
#if 0 // # examining flags ###
make -B CXXFLAGS= # clean compile, initial surprise
make -B # clean too(!!), big surprise
make -B EXTFLAGS='-O1' # warnings, but compiles (why it has anything with -O1
?!)
#endif
#if 0 // # g++ (GCC) 4.1.1 [sun4u] ###
// int n = n + 1;
n ==> 67481
// double r = r + 1000.0;
r ==> 1.96794e+307
// X obj;
this ==> 0xffbfefc8
// X obj(obj);
&rhs ++> 0xffbfefc4 <** UNEXPECTED
this oo> 0xffbfefc4
// X obj(obj);
&rhs ++> 0xffbfefc0 <** UNEXPECTED
this oo> 0xffbfefc0
~obj ~~> 0xffbfefc0
~obj ~~> 0xffbfe
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #76 from ian at airs dot com 2007-05-16 18:01 --- I don't believe that the C++ standards writers really meant to eliminate TBAA. And that is the inevitable consequence of the dynamic memory type approach if you are allowed to change the dynamic type in a function. If we really want to adopt that approach, then the simple fix is for the C++ frontend to set flag_strict_aliasing to 0. But I don't think we want to do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #75 from rguenth at gcc dot gnu dot org 2007-05-16 17:08 --- In the chance of endlessly repeating myself here (;)) - what comment #73 boils down to is that we may not prune alias sets of stores based on TBAA results. In fact, we need to realize that C++ object lifetime rules need to be modeled somehow - it's those rules that count after all, not some magic side-effects of placement new. Of course I realize that without TBAA pruning we have no alias information left on the RTL side for stores (so stores effectively have alias set zero). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug middle-end/31959] [4.3 Regression] ICE in expand_builtin_expect, at builtins.c:5112
--- Comment #1 from tbm at cyrius dot com 2007-05-16 16:58 ---
struct btree_priv *area;
typedef struct bt_node_t
{
int next;
int used;
}
bt_leaf_t;
typedef union bt_page_t
{
bt_leaf_t leaf;
}
bt_page_t;
static inline bt_page_t *
vbt_deref (struct btree_priv *bt)
{
}
static inline bt_page_t *
bt_deref (const struct btree_priv *bt)
{
return vbt_deref ((struct btree_priv *) bt);
}
btree_fetch (struct btree_priv *area)
{
int pos;
const bt_leaf_t *leaf;
if (__builtin_expect ((pos + 1 >= leaf->used), 0))
{
leaf = &bt_deref (area)->leaf;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31959
[Bug middle-end/31959] New: [4.3 Regression] ICE in expand_builtin_expect, at builtins.c:5112
4.3 ICEs during error recovery. This doesn't happen with 4.2. (sid)24008:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 -Werror btree.c cc1: warnings being treated as errors btree.c: In function 'bt_deref': btree.c:20: error: passing argument 1 of 'vbt_deref' discards qualifiers from pointer target type btree.c: In function 'btree_fetch': btree.c:26: internal compiler error: in expand_builtin_expect, at builtins.c:5112 -- Summary: [4.3 Regression] ICE in expand_builtin_expect, at builtins.c:5112 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31959
[Bug middle-end/31950] [4.3 Regression] ICE in tree-ssa-alias-warnings.c
--- Comment #4 from tbm at cyrius dot com 2007-05-16 16:39 --- CCing Richi in case he didn't see the comment saying that his patch works. -- tbm at cyrius dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug c/31958] New: gcc-4.2.0.tar.bz2 is missing INSTALL html files
I hesitate to report this because it seems so obvious I must be wrong: gcc-4.2.0/INSTALL only contains the README file (which says to look in index.html). In previous tarballs, INSTALL contained the config/build/etc. instructions as HTML files. I haven't seen anything that would suggest that it is not intended to be the case anymore: gcc-4.2.0/README and gcc-4.2.0/INSTALL/README haven't changed in years... -- Summary: gcc-4.2.0.tar.bz2 is missing INSTALL html files Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon dot marshall at misys dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31958
[Bug bootstrap/31957] New: Build of compiler fails with 'error: #endif without #if'
$ configure --enable-languages=c,c++ --with-ld=/bin/ld --with-as=/bin/as $ make leads to: In file included from .../obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/cctype:50, from .../gcc-4.2.0/libstdc++-v3/include/precompiled/stdc++.h:38: .../obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/powerpc-ibm-aix5.2.0.0/bits/c++config.h:1087:2: error: #endif without #if While doing: make[4]: Entering directory `/pdv/.ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include' sed: 0602-429 No editing script was provided. Usage: sed [-n] Script [File ...] sed [-n] [-e Script] ... [-f Script_file] ... [File ...] if [ ! -d "./powerpc-ibm-aix5.2.0.0/bits/stdc++.h.gch" ]; then \ mkdir -p ./powerpc-ibm-aix5.2.0.0/bits/stdc++.h.gch; \ fi; \ /ws/jrichter/gcc420/obj/./gcc/xgcc -shared-libgcc -B/ws/jrichter/gcc420/obj/./gcc -nostdinc++ -L/ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/src -L/ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/src/.libs -B/usr/local/powerpc-ibm-aix5.2.0.0/bin/ -B/usr/local/powerpc-ibm-aix5.2.0.0/lib/ -isystem /usr/local/powerpc-ibm-aix5.2.0.0/include -isystem /usr/local/powerpc-ibm-aix5.2.0.0/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -I/ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/powerpc-ibm-aix5.2.0.0 -I/ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include -I/ws/jrichter/gcc420/gcc-4.2.0/libstdc++-v3/libsupc++ -O0 -g /ws/jrichter/gcc420/gcc-4.2.0/libstdc++-v3/include/precompiled/stdc++.h -o powerpc-ibm-aix5.2.0.0/bits/stdc++.h.gch/O0g.gch the file .../powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/powerpc-ibm-aix5.2.0.0/bits/c++config.h has as the last line: #endif // _CXXCONFIG_ but no corresponding #ifndef/#define lines of his header guard -- Summary: Build of compiler fails with 'error: #endif without #if' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joerg dot richter at pdv-fs dot de GCC build triplet: powerpc-ibm-aix5.2.0.0 GCC host triplet: powerpc-ibm-aix5.2.0.0 GCC target triplet: powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug middle-end/31950] [4.3 Regression] ICE in tree-ssa-alias-warnings.c
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2007-05-16 16:07 --- Your patch seems to fix the failure for both reduced test cases as well as the original code. Thanks for the prompt response! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug tree-optimization/31191] [4.3 Regression] 1000% Runtime regression for FreeFEM navier-stokes example
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-16 16:03 --- Magically fixed itself. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31191
[Bug c++/31956] New: names declared in a condition may be redeclared
The C++ standard, clauses 3.3.2 paragraph 4, and 6.4 paragraph 3, states that
names declared in the condition of `while', `if', `for' and `switch'
statements, may not be redeclared in any of the outermost controlled blocks.
This does work for `while' statements, however it does not work with `if', or
`switch' statements.
E.g. The following are compiled, but should not:
if (int foo = 0)
{
int foo = 1; // invalid
}
switch (int foo = 0)
{
default:
int foo = 1; // invalid
}
A similar example with a for statement is reported in Bug #2288
--
Summary: names declared in a condition may be redeclared
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31956
[Bug fortran/31833] FAIL: gfortran.dg/integer_exponentiation_3.F90 at -O0 and above
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-16 15:46 --- All I have access to is hppa2.0w-hp-hpux11.23, do you think it would be triggered there also? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31833
[Bug c/31955] New: gcc-4.2.0.tar.bz2 is missing INSTALL html files
I hesitate to report this because it seems so obvious I must be wrong: gcc-4.2.0/INSTALL only contains the README file (which says to look in index.html). In previous tarballs, INSTALL contained the config/build/etc. instructions as HTML files. I haven't seen anything that would suggest that it is not intended to be the case anymore: gcc-4.2.0/README and gcc-4.2.0/INSTALL/README haven't changed in years... -- Summary: gcc-4.2.0.tar.bz2 is missing INSTALL html files Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon dot marshall at misys dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31955
[Bug tree-optimization/31953] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:305
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-16 15:43 --- Confirmed. -- 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-05-16 15:43:17 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31953
[Bug middle-end/31950] [4.3 Regression] ICE in tree-ssa-alias-warnings.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-16 15:41 ---
Confirmed.
Index: tree-ssa-alias-warnings.c
===
--- tree-ssa-alias-warnings.c (revision 124763)
+++ tree-ssa-alias-warnings.c (working copy)
@@ -635,7 +635,7 @@ ffan_walker (tree *t,
int *go_below ATTRIBUTE_UNUSED,
void *data ATTRIBUTE_UNUSED)
{
- if (DECL_P (*t) && DECL_ARTIFICIAL (*t))
+ if (DECL_P (*t) && !MTAG_P (*t) && DECL_ARTIFICIAL (*t))
return *t;
else
return NULL_TREE;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rus at google dot com
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-05-16 15:41:36
date||
Summary|ICE in tree-ssa-alias- |[4.3 Regression] ICE in
|warnings.c |tree-ssa-alias-warnings.c
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #74 from rguenth at gcc dot gnu dot org 2007-05-16 15:36 --- Note that another solution to this whole problem is to record conflicts for all stored-to types that we cannot disambiguate by points-to analysis. This also solves the reading of the standard that allows int i = 1; (float *)&i = 0.0; at RTL expansion time we need to do the same apart from that we don't have points-to information available. The above supports the notion of "re-using memory changes its dynamic type". Which of course gets a little interesting for aggregates that are initialized piece-wise (not that this problem isn't present now). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/30820] -Wno-error not necessary in Make-lang.in any more?
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-16 15:34 --- On mainline, we currently require GMP >= 4.1, for which this transformation is safe (the mpz_get_ui inline function in gmp.h was corrected to avoid this warning). Thus, simply removing these lines should work fine: Index: Make-lang.in === --- Make-lang.in(revision 124460) +++ Make-lang.in(working copy) @@ -48,13 +48,6 @@ GFORTRAN_TARGET_INSTALL_NAME := $(target # Use strict warnings for this front end. fortran-warn = $(STRICT_WARN) -# These files get warnings from an inline function in GMP saying: -# "control may reach end of non-void function '__gmpz_get_ui' being inlined" -fortran/expr.o-warn = -Wno-error -fortran/resolve.o-warn = -Wno-error -fortran/simplify.o-warn = -Wno-error -fortran/trans-common.o-warn = -Wno-error - # These are the groups of object files we have. The F95_PARSER_OBJS are # all the front end files, the F95_OBJS are the files for the translation # from the parse tree to GENERIC -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2007-02-16 11:08:24 |2007-05-16 15:34:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30820
[Bug c/31949] SH- Aliasing problem for incompatible pointers in c code
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-16 15:24 --- You are accessing memory of type structC via a pointer of type structB * which violates C aliasing rules. -- 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=31949
[Bug c++/31954] New: template function cannot create object of forward declared class
The following code works on gcc-4.1.2, but is rejected with gcc-4.2.0:
class ABC0
{
public:
virtual ~ABC0() = 0;
virtual int something() = 0;
};
inline ABC0::~ABC0()
{ }
struct C0;
struct ABC1 : public ABC0
{
explicit ABC1()
: ABC0()
{ }
virtual ABC0 *sometwhat() = 0;
};
template
struct C1 : public ABC1
{
ABC0 *somewhat();
};
template
ABC0 *C1::somewhat()
{
return new C0;
}
struct C0 : public ABC0
{
C0(int c)
: ABC0()
, _c(c)
{ }
int something()
{ return 0; }
private:
int _c;
};
$ g++ -V4.2.0 -c bug.cc
bug.cc: In member function 'ABC0* C1::somewhat()':
bug.cc:34: error: invalid use of incomplete type 'struct C0'
bug.cc:12: error: forward declaration of 'struct C0'
--
Summary: template function cannot create object of forward
declared class
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thomas at maier-komor dot de
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31954
[Bug fortran/31483] [4.1/4.2 only] ICE on fortran Code
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||ice-on-valid-code, patch Known to fail||4.2.1 4.1.3 Known to work||4.3.0 Summary|ICE on fortran Code |[4.1/4.2 only] ICE on ||fortran Code Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483
[Bug tree-optimization/31953] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:305
--- Comment #1 from tbm at cyrius dot com 2007-05-16 15:04 ---
Reduced testcase:
struct WView
{
int hexedit_mode:1;
};
toggle_hexedit_mode (struct WView *view)
{
if (view->hexedit_mode)
{
}
else
{
view->hexedit_mode = !view->hexedit_mode;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31953
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #73 from rguenth at gcc dot gnu dot org 2007-05-16 15:02
---
For the following testcase, loop store motion re-orders the writes to *l and *f
at -O2. (Note as is, the testcase is only valid for n == 1)
inline void* operator new(unsigned long, void* __p) throw() { return __p; }
extern void bar();
long foo(double *p, int n)
{
long *f;
for (int i=0; i:
if (n > 0)
goto ;
else
goto ;
:
f = (long int *) p;
<<>>
# SMT.4_27 = VDEF
*f = -1;
# SMT.5_35 = VDEF
*(int *) p = 0;
:
# SMT.4_23 = VDEF
# SMT.5_24 = VDEF
bar ();
return *f;
which is wrong. Runtime testcase that aborts:
inline void* operator new(unsigned long, void* __p) throw() { return __p; }
void __attribute__((noinline)) bar() {};
long __attribute__((noinline)) foo(double *p, int n)
{
long *f;
for (int i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31725] [4.1 only] substring bound evaluated multiple times: wrong code for string(function():) = 'X'
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-05-16 15:01 --- Fixed on mainline and 4.2.1 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.3.0 |4.3.0 4.2.1 Resolution||FIXED Summary|[4.1/4.2 only] substring|[4.1 only] substring bound |bound evaluated multiple|evaluated multiple times: |times: wrong code for |wrong code for |string(function():) = 'X' |string(function():) = 'X' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31725
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #72 from rguenth at gcc dot gnu dot org 2007-05-16 14:49
---
inline void* operator new(unsigned long, void* __p) throw() { return __p; }
extern void bar();
float foo(double *p)
{
long *l = (long *)p;
*l = 1;
float *f = new (p) float;
*f = 0.0;
bar ();
return *f;
}
with -O2 I see
:
l_2 = (long int *) p_1(D);
# SMT.4_12 = VDEF
*l_2 = 1;
<<>>
__p_8 = p_1(D);
f_5 = (float *) __p_8;
# SMT.5_14 = VDEF
*f_5 = 0.0;
# SMT.4_15 = VDEF
# SMT.5_16 = VDEF
bar ();
# VUSE
D.2462_6 = *f_5;
return D.2462_6;
which looks wrong - the store to f_5 needs to alias *l_2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug tree-optimization/31953] New: [4.3 Regression] ICE in set_value_range, at tree-vrp.c:305
This worked with 4.3.0 20070422 but fails now with 20070515: (sid)23934:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 mc-view.i view.c: In function 'toggle_hexedit_mode': view.c:2045: internal compiler error: in set_value_range, at tree-vrp.c:305 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3 Regression] ICE in set_value_range, at tree- vrp.c:305 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31953
[Bug fortran/31725] [4.1/4.2 only] substring bound evaluated multiple times: wrong code for string(function():) = 'X'
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-05-16 14:36 --- Subject: Bug 31725 Author: fxcoudert Date: Wed May 16 13:36:03 2007 New Revision: 124769 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124769 Log: PR fortran/31725 * trans-expr.c (gfc_conv_substring): Evaluate substring bounds only once. * gfortran.dg/substr_4.f: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/substr_4.f - copied unchanged from r124720, trunk/gcc/testsuite/gfortran.dg/substr_4.f Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31725
[Bug libffi/31937] libffi doesn't support ppc without FPU
--- Comment #1 from patrick dot olinet at gmail dot com 2007-05-16 14:23 --- Notice that this bug prevents loading and running java bytecode from a native code binary compiled with gcj. I guess it relies on libffi to call the methods of the bytecode. This java problem is what I've encountered first before investigating and finding out that it all comes from libfii. -- patrick dot olinet at gmail dot com changed: What|Removed |Added CC||patrick dot olinet at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31937
[Bug c++/31952] New: parameters may be redeclared in a function try-block
According to the C++ standard, clause 3.3.2, paragraph 2, sentence 3, the
following program should be invalid:
int
foo (int bar)
try
{
return 0;
}
catch (...)
{
int bar = 0; // invalid
return 1;
}
Specifically, `bar' may not be redeclared in the outermost block of a handler
in a function try-block.
GCC 4.1.1 gives no errors or warnings (other than unused parameters and
variables).
--
Summary: parameters may be redeclared in a function try-block
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31952
[Bug c++/986] g++ misses warning for & on temporary
--- Comment #23 from manu at gcc dot gnu dot org 2007-05-16 14:03 --- Hi Naimu, I am not speaking in the name of the GCC community but I would like to prevent your frustration. You exposed your point clearly. People that have a deep knowledge of C++ and g++ don't agree with you. Repeating your point again is not doing any good. You may go to [EMAIL PROTECTED] and expose your point to a broader audience. I think this is going to be unsuccessful for a fundamental and a practical reason. The fundamental reason is that the standard doesn't call this an error. And GCC implements that C++ standard. It is the same case as with uninitialized variables. The practical reason is that converting a warning into an error is trivial (or viceversa) but implementing the warning/error in the first place is not. So people are going to say "Come back when it is implemented and we will discuss then whether it should be a warning or an error". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug target/31679] Incorrect result of multiplication long long by 0xFFFFFFFFLL constant.
--- Comment #5 from ian dot rogers at manchester dot ac dot uk 2007-05-16
14:01 ---
For the following code given in [1] GCC produces identical multiplication by
constant code [2]. I think as 0x0 is one of the parameters in this bug
the fact we generate identical multiplication code for 0x1 means this
is another example of this error.
Thanks,
Ian Rogers
[1]
test.c:
extern long long x;
long long foo() {
return x * long long)0) << 32) + -1);
}
long long foo2() {
return x * long long)1) << 32) + -1);
}
[2]
test.s:
.file "test.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
movlx, %eax
movlx+4, %edx
pushl %ebp
movl%esp, %ebp
negl%eax
popl%ebp
adcl$0, %edx
negl%edx
ret
.size foo, .-foo
.p2align 4,,15
.globl foo2
.type foo2, @function
foo2:
movlx, %eax
movlx+4, %edx
pushl %ebp
movl%esp, %ebp
negl%eax
popl%ebp
adcl$0, %edx
negl%edx
ret
.size foo2, .-foo2
.ident "GCC: (GNU) 4.1.2 20061115 (prerelease) (SUSE Linux)"
.section.note.GNU-stack,"",@progbits
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31679
[Bug c++/31951] New: local structure problem
2nd call to partial_sort gives 'no match...' error, but 1st is OK.
Doesn't seem right.
#include
#include
template
struct Sort_Func2 {
vector_t const& mag;
Sort_Func2 (vector_t const& _mag) : mag (_mag) {}
bool operator() (int a, int b) const { return mag [a] < mag [b]; }
};
template
void F (vector_t const& v) {
struct Sort_Func {
vector_t const& mag;
Sort_Func (vector_t const& _mag) : mag (_mag) {}
bool operator() (int a, int b) const { return mag [a] < mag [b]; }
};
std::vector indexes (v.size());
std::partial_sort (indexes.begin(), indexes.begin()+2, indexes.end(),
Sort_Func2 (v));
std::partial_sort (indexes.begin(), indexes.begin()+2, indexes.end(),
Sort_Func (v));
}
int main() {
std::vector v;
F (v);
}
--
Summary: local structure problem
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ndbecker2 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31951
[Bug c++/31950] ICE in tree-ssa-alias-warnings.c
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2007-05-16 13:35
---
Reduced test case. Both tests also fail with current mainline (revision
124767M).
struct B {
~B();
};
struct A {
B* b;
virtual ~A() { delete[] b; }
};
A Op(void);
int main()
{
A a(Op());
return 0;
}
--
Ralf dot Wildenhues at gmx dot de changed:
What|Removed |Added
CC||Ralf dot Wildenhues at gmx
||dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug c++/31950] New: ICE in tree-ssa-alias-warnings.c
With mainline as of a couple of days ago:
| gcc version 4.3.0 20070514 (experimental)
g++ -O2 -Wstrict-aliasing=3 -c t.cc
gives me this error:
| t.cc: In function int main():
| t.cc:11: internal compiler error: tree check: expected tree that contains
decl common structure, have struct_field_tag in ffan_walker, at
tree-ssa-alias-warnings.c:638
on the following code. I haven't tried eliminating yet,
but may try to do so, given time. Will try updated mainline next.
Cheers,
Ralf
#include
using std::valarray;
struct A {
valarray* v;
virtual ~A() { delete[] v; }
};
A Op(void);
int main()
{
A a(Op());
return 0;
}
--
Summary: ICE in tree-ssa-alias-warnings.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ralf dot Wildenhues at gmx dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #71 from rguenth at gcc dot gnu dot org 2007-05-16 13:05
---
But it doesn't fix the POOMA miscompilations if I change its Pool allocator to
use placement new instead of this
// Release a block to the pool.
inline void free(void *b)
{
// Record a free.
outstandingAllocs_m -= 1;
// Cast the pointer to the right type.
Link *p = (Link*)b;
// Make it point to the current head of the free list.
p->next_m = head_m;
// Make the next one the new head of the list.
// We can't do head_m = p->next_m since p will soon be treated
// as something other than a Link. By doing this assignment
// with memcpy, we ensure that p->next_m will be read before
// it is clobbered.
memcpy(&p->next_m, &head_m, sizeof(head_m));
// Make it the head of the free list.
head_m = p;
}
memcpy hack. I'll try to investigate...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug bootstrap/26998] [4.1 Regression] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-05-16 13:02 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Known to fail||4.1.0 4.1.2 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug bootstrap/26998] [4.1 Regression] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-05-16 12:57 --- Subject: Bug 26998 Author: rguenth Date: Wed May 16 11:57:09 2007 New Revision: 124767 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124767 Log: 2007-05-16 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2006-06-09 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/26998 * tree-vrp.c (extract_range_from_unary_expr): For NEGATE_EXPR of signed types, only TYPE_MIN_VALUE is special, but for both, minimum and maximum value. Likewise VR_ANTI_RANGE is special in this case, as is -fwrapv. * gcc.dg/torture/pr26998.c: New testcase. * gcc.dg/tree-ssa/vrp29.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr26998.c - copied unchanged from r114507, trunk/gcc/testsuite/gcc.dg/torture/pr26998.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/vrp29.c - copied unchanged from r114507, trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp29.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug c/31949] New: SH- Aliasing problem for incompatible pointers in c code
Hello all,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problem while executing the following C program.
--
#include
struct structB { int x; int y; };
struct structC { int x; int y; };
main()
{
struct structC varCs, *varCp=&varCs, **varCpp=&varCp;
struct structB *varBp;
varCs.x = 10;
varCs.y = 20;
varBp = *((struct structB **)varCpp);
varBp->x = varBp->y;
printf("%d",varCs.x);
}
--
The above program compiles successfully with the sh4-linux toolchain.
While executing on target platform it is generating wrong result.
Observations:
1. When the above program is compiled with '-O0' optimization the value of
varCs.x is printed as 20, which is the expected output.
Command: sh4-linux-gcc
2. When the above program is compiled with '-O2' optimization the program is
giving following errors:
a) "Bus error" when executed on SH7780 Highlander board.
b) "Killing process due to unaligned access in user space" when executed on
SH7751 R2D board.
Command: sh4-linux-gcc -O2
3. When the above program is compiled with '-O2' and '-fno-strict-aliasing'
option the value of varCs.x is printed as 20.
Command: sh4-linux-gcc -O2 -fno-strict-aliasing
Is the above problem related to strict aliasing ? As with 'fno-strict-aliasing'
option the above code works fine.
Any help on this will be appreciated.
Regards,
Ashay Jaiswal
KPIT Cummins Infosystems Ltd,
Pune (INDIA)
~~
Free download of GNU based SH-Linux toolchains for Renesas' SH Series.
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 April 5, 2007.
~
--
Summary: SH- Aliasing problem for incompatible pointers in c code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ashay dot Jaiswal at kpitcummins dot com
GCC build triplet: i686-pc-gnu
GCC host triplet: sh4-unknown-linux
GCC target triplet: sh4-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31949
[Bug c++/31948] New: SH- Mathematical Error handling is no working for valid code
Hello all,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problem while executing the following C++ program.
--
#include
#include
#include
double value;
int main( void )
{
value = sqrt(-1.2);
if (errno != EDOM) {
printf("sqrt: GOT %f\n", value);
}
}
--
The above program compiles successfully with the sh4-linux toolchain.
While executing on target platform "sqrt" function is returning "nan" but
"errno" variable is not set to "EDOM".
Command: sh4-linux-gcc {here default target is m4}
Observations:
1. When the above program is compiled with "-m4-nofpu" target option or with
any other FPU less target option program executes successfully and the
"errno" variable is set to "EDOM".
Command: sh4-linux-gcc -m4-nofpu
Is there any relation with the target processor (i.e. floating point unit
processor or non - floating point unit processor)? Because the only difference
between success and failure condition in our case is the target switch we are
specifying (m4-nofpu or m4 respectively ).
Any help on this will be appreciated.
Regards,
Ashay Jaiswal
KPIT Cummins Infosystems Ltd,
Pune (INDIA)
~~
Free download of GNU based SH-Linux toolchains for Renesas' SH Series.
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 April 5, 2007.
~
--
Summary: SH- Mathematical Error handling is no working for valid
code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
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=31948
[Bug middle-end/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
-- tbm at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end Keywords||ice-on-valid-code Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug tree-optimization/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
--- Comment #2 from tbm at cyrius dot com 2007-05-16 11:29 --- Note that the testcases from PR30509 work fine with 4.2, so this appears to be a different bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug tree-optimization/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
--- Comment #1 from tbm at cyrius dot com 2007-05-16 11:26 --- Created an attachment (id=13564) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13564&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug tree-optimization/31947] New: [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
I'm getting the following ICE with gcc 4.2.0 RC3. It compiles fine with gcc 4.1 and 4.3 20070515. (sid)23889:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2 freehdl-vital_timing.cc freehdl-vital_timing.cc: In function 'array_type delay(const array_type&)': freehdl-vital_timing.cc:38: internal compiler error: in calc_dfs_tree, at dominance.c:374 Please submit a full bug report, with preprocessed source if appropriate. (sid)23890:[EMAIL PROTECTED]: ~] g++-4.1 -c -O2 freehdl-vital_timing.cc (sid)23891:[EMAIL PROTECTED]: ~] -- Summary: [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #1 from aurelien at aurel32 dot net 2007-05-16 11:08 --- The problem is also present in gcc HEAD (SVN from today) built as a cross-compiler on x86_64-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #70 from rguenth at gcc dot gnu dot org 2007-05-16 10:57 --- The last patch looks good sofar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/31941] [4.1/4.2/4.3 Regression] "confused by earlier errors" message without earlier error message
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-16 10:23 --- /home/tbm/src/digikam-0.9.1/./digikam/libs/widgets/metadata/iptcwidget.cpp:159: error: request for member 'c_str' in ' ? so there seems to be an error. Of course we probably ICE during error reporting which may confuse this matter ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||error-recovery, ice-on- ||invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
[Bug bootstrap/26998] [4.1 Regression] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-05-16 10:20
---
Reopen, because this happens on the 4.1 branch as well with -O2 -ftrapv
void f1(int);
void f2(int x)
{
if (x != -2147483647 - 1)
f1(-x);
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
Summary|bootstrap failure building |[4.1 Regression] bootstrap
|libdecnumber, ICE in|failure building
|compare_values, tree- |libdecnumber, ICE in
|vrp.c:432 |compare_values, tree-
||vrp.c:432
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug tree-optimization/31940] [4.1 Regression] ICE with -O -ftrapv -ftree-vrp on negation after comparison to INT_MIN
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-16 10:18 ---
Confirmed. A regression with -O2 -ftrapv.
Program received signal SIGSEGV, Segmentation fault.
0x00830f6e in compare_values (val1=0x0, val2=0x2ac511f0e9f0)
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-vrp.c:435
435 gcc_assert (POINTER_TYPE_P (TREE_TYPE (val1))
we extract from unary
-xD.1609_3
with a value range
~[-INF, -2147483648] EQUIVALENCES: { x_1 } (1 elements)
but of course,
if (code == NEGATE_EXPR
&& !TYPE_UNSIGNED (TREE_TYPE (expr)))
{
/* NEGATE_EXPR flips the range around. */
min = (vr0.max == TYPE_MAX_VALUE (TREE_TYPE (expr)) && !flag_wrapv)
? TYPE_MIN_VALUE (TREE_TYPE (expr))
: fold_unary_to_constant (code, TREE_TYPE (expr), vr0.max);
max = (vr0.min == TYPE_MIN_VALUE (TREE_TYPE (expr)) && !flag_wrapv)
? TYPE_MAX_VALUE (TREE_TYPE (expr))
: fold_unary_to_constant (code, TREE_TYPE (expr), vr0.min);
}
is bogus. And this is a dup of PR26998.
*** This bug has been marked as a duplicate of 26998 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Keywords||ice-on-valid-code
Known to fail||4.1.0 4.1.2
Known to work||4.2.0
Resolution||DUPLICATE
Summary|ICE with -O -ftrapv -ftree- |[4.1 Regression] ICE with -O
|vrp on negation after |-ftrapv -ftree-vrp on
|comparison to INT_MIN |negation after comparison to
||INT_MIN
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31940
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-05-16 10:18 --- *** Bug 31940 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||truedfx at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug fortran/31930] bes[jy]n intrinsics do not follow definition of elemental functions
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 09:50 --- Over to you, Daniel - I was smiling when I mentioned using the time for something else; there was no need to apologise. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pault at gcc dot gnu dot org|dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31930
[Bug tree-optimization/31946] New: missed vectorization due to too strict peeling-for-alignment policy
The vectorizer is too restricted in the way it decides by how many iterations
to peel a loop in order to align a certain memory reference in a loop. It
considers only the first (potentially) misaligned store it encounters in the
loop. For this reason the testcases vect-multitypes-1.c, vect-multitypes-4.c
and vect-iv-4.c don't get vectorized. For example (using Vector Size of 16
bytes), in vect-multitypes-1.c we have:
short sa[N], sb[N];
int ia[N], ib[N];
for (i = 0; i < n; i++) {
ia[i+3] = ib[i];
sa[i+3] = sb[i];
}
The current peeling-for-alignment scheme will consider the 'ia[i+3]' access for
peeling, and therefore will examine the option of using a peeling factor =
(4-3)%4 = 1. This will not align the access 'sa[i+3]', for which we need to
peel 5 iterations. As a result the loop doesn't get vectorized (cause we
currently can't handle misaligned stores unless we align them by peeling).
However, if we had considered the 'sa[i+3]' access as well for peeling, we
would have examined the option of using a peeling factor = (8-3)%8 = 5, which
would align both accesses, and would allow us to vectorize the loop. So the
vectorizer needs to be extended to consider more peeling factors, and not just
one.
--
Summary: missed vectorization due to too strict peeling-for-
alignment policy
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31946
[Bug tree-optimization/31945] New: missing type vector conversions patterns on spu
Since the following patch: 2007-04-22 Uros Bizjak <[EMAIL PROTECTED]> PR tree-optimization/24659 GCC supports vectorization of float<-->double conversions. These can also be modelled for the spu target by implementing the following patterns: vec_pack_trunc_v2df vec_unpacks_lo_v4sf vec_unpacks_hi_v4sf (also see PR24659) -- Summary: missing type vector conversions patterns on spu Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com GCC build triplet: spu GCC host triplet: spu GCC target triplet: spu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31945
[Bug fortran/31427] TRANSFER with mold kind /= lval kind: ICE on ia64, i686; no warning
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-16 09:15 --- Fixed on trunk Paul and Brooks -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug fortran/31216] TRANSFER in CASE leads to ICE
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 09:14 --- Fixed on trunk Paul and Brooks -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31216
[Bug fortran/31194] NaN transfer - internal compiler error: in gfc_conv_constant
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-16 09:13 --- Fixed on trunk Paul and Brooks -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31194
[Bug fortran/30881] Select case of case(transfer(...)) wrongly rejected
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-16 09:11 --- Fixed on trunk Paul and Brooks -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30881
[Bug fortran/18769] ICE in gfc_conv_array_initializer with array initialization with transfer
--- Comment #18 from pault at gcc dot gnu dot org 2007-05-16 09:10 --- Fixed on trunk Paul and Brooks -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
[Bug c++/986] g++ misses warning for & on temporary
--- Comment #22 from raf2 at msux dot cjb dot net 2007-05-16 08:50 --- Mmm... maybe I haven't explained correctly. If you contract someone to build stairs and later he says: "As long as you don't touch this step, everything's ok" you tell him some nasty things. The users of our g++ programs, our boss, will tell us the same nasty things if they know of equivalent features in our programs. That's the point of having the compiler stopping compilations when (for example) it detects a reference to an object that has been destroyed. Unless someone has a useful employ ofhaving references to objects that have been destroyed, that is why a sample is asked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
