[Bug tree-optimization/39675] [4.4 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-transform.c:1999
--- Comment #2 from irar at gcc dot gnu dot org 2009-04-20 07:09 --- Subject: Bug 39675 Author: irar Date: Mon Apr 20 07:09:01 2009 New Revision: 146365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146365 Log: PR tree-optimization/39675 * tree-vect-transform.c (vect_transform_loop): Remove currently redundant check of the return code of vect_schedule_slp. Check that stmt_vec_info still exists for the statement, before checking its vectorization type. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/O3-pr39675-1.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39675
[Bug c++/39820] errors while compiling libc and the kernel
--- Comment #1 from ubizjak at gmail dot com 2009-04-20 07:14 --- Please split this PR into two separate reports. Also, please attach standalone preprocessed source that triggers the bug, see http://gcc.gnu.org/bugs.html. A backtrace of the crash would also help a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39820
[Bug c/39820] errors while compiling libc and the kernel
-- ubizjak at gmail dot com changed: What|Removed |Added Severity|critical|normal Component|c++ |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39820
Re: vector issue in g++?
On Sun, Apr 19, 2009 at 7:19 PM, James Dennett james.denn...@gmail.com wrote: On Sun, Apr 19, 2009 at 4:15 PM, Paolo Piacentini paolopi...@hotmail.com wrote: I don't think this is a bug but certainly it is a problem. Would you please consider it and let me know? I hope so. Thanks. The following simple volcalc.cpp code compiles with no errors (and works) in Windows Visual C++. It simply sizes the alldata array later in the code. If Visual C++ does not diagnose the error in the code in its best standards-conforming mode, that is a bug in Visual C++. Allowing it as an extension is an entirely reasonable thing to do though. With g++ v.4.3.2 instead I get the error reported hereby. For some reason it does not like the fact that struct is declared local. That is what C++ requires; template parameters must have external linkage, and in C++98 local types do not have external linkage. If you declare struct as global it will be working but I cannot change the code so drastically. I would thankfully appreciate any help (including tough critics to the code). The drastic change would be needed to make your code valid C++, and if you do that then g++ will compile it. There has been discussion of changing this rule for the next C++ standard, see e.g., http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2402.pdf though I don't see signs of it having been merged into the current committee draft. N2402 does mention the change in MSVC++ as being a relatively recent extension. A quick search hasn't turned up the current status of N2402, though there was some discussion of weakening it by removing support for using unnamed types as template parameters, and it seemed to have reasonably strong support in that form. Asking around a little more, and I've been pointed to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm which has been incorporated into the current committee draft for C++0x, and allows use of local types as template parameters. It looks like your code will become legal in the next C++ standard, and g++ might well start supporting this before then (if someone is inspired to implement it, that is). -- James
[Bug tree-optimization/39799] [4.3/4.4/4.5 Regression] missing 'may be used uninitialized' warning
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-20 07:39 --- See PR31081 for details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39799
[Bug c/39820] errors while compiling libc and the kernel
--- Comment #2 from justinmattock at gmail dot com 2009-04-20 08:06 --- Subject: Re: errors while compiling libc and the kernel On Mon, 2009-04-20 at 07:15 +, ubizjak at gmail dot com wrote: Alright, (I'll have to read read up on the backtrace part), from what I'm seeing so far, not good, i.g. evolution compiled perfectly(with the latest snapshot of gcc), but as I'm running the mail client I'm getting skips in the music(streaming from the intranet), when I minimize and maximize the window. for some reason I'm thinking it might have something to do with libpthread(not sure though, maybe the headers got messed up) Anyways I'll try and supply as much info as possible. regards, Justin P. Mattock -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39820
[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-20 08:09 --- AFAIK this has been backported to branches/gcc-4_3-branch as well by Janis. You haven't said on which tool this triggers (gcc, or libstdc++, or something else), e.g. on gcc there are around 164 different Running lines, so your number of opened files limit would be extremely low. In any case, I'll try to play with close in some spots of guts.awk, but will need testing on the targets with unusable awk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4/4.5 Regression]|[4.3/4.4/4.5 Regression] |Reporting of testsuite |Reporting of testsuite |failures are messed up when |failures are messed up when |using -j|using -j http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807
[Bug middle-end/39812] [4.5 regression] Revision 146314 failed 8 gnat.dg tests
--- Comment #9 from laurent at guerby dot net 2009-04-20 08:33 --- Confirmed, Jan Hubicka second patch fixed the issue: 146344: FAIL 146349: OK My apologies to Richard :) -- laurent at guerby dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives
--- Comment #5 from aph at redhat dot com 2009-04-20 08:48 --- Subject: Re: [arm] libjava build failure due to missing thread synchronization primitives ramana at gcc dot gnu dot org wrote: --- Comment #4 from ramana at gcc dot gnu dot org 2009-04-20 05:58 --- The build is broken currently for arm-none-eabi targets on trunk. Attempting a simple fix of supporting arm-eabi* got me past the error reported in the original bug report. but I still get a failure with the following error message. I'm not quite sure what you're trying to do. What did you change to support arm-eabi* ? Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340
[Bug tree-optimization/39799] [4.3/4.4/4.5 Regression] missing 'may be used uninitialized' warning
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-20 09:32 --- Honza, if overlapping lifetimes are the problem instead of zero-initializing uninitialized params we could instead create a new uninitialized variable for them? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39799
[Bug c/39820] errors while compiling libc and the kernel
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-20 09:14 --- Please attach preprocessed source and the output of -v appended to the commandline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39820
[Bug tree-optimization/39821] 120% slowdown with vectorizer
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-20 09:26 ---
The vectorizer creates
vect_var_.128_46 = M*vect_p.123_44{misalignment: 0};
vect_var_.129_47 = [vec_unpack_lo_expr] vect_var_.128_46;
vect_var_.129_48 = [vec_unpack_hi_expr] vect_var_.128_46;
vect_var_.135_53 = M*vect_p.130_51{misalignment: 0};
vect_var_.136_54 = [vec_unpack_lo_expr] vect_var_.135_53;
vect_var_.136_55 = [vec_unpack_hi_expr] vect_var_.135_53;
vect_var_.137_56 = vect_var_.136_54 * vect_var_.129_47;
vect_var_.137_57 = vect_var_.136_55 * vect_var_.129_48;
vect_var_.138_59 = vect_var_.137_56 + vect_var_.138_58;
vect_var_.138_60 = vect_var_.137_57 + vect_var_.138_59;
v1_14 = v1_26 + 4;
but the widening unpacking results in absymal code generated. Where are
all the shifts coming from?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||uros at gcc dot gnu dot org,
||irar at il dot ibm dot com
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2009-04-20 09:26:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39821
[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-20 09:37 --- Created an attachment (id=17655) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17655action=view) gcc45-pr39807.patch Please try this patch. So far I've just tested that it generates the same results as before the patch for dg-extract-results.sh testsuite/gcc*/*.sum.sep dg-extract-results.sh -L testsuite/gcc*/*.log.sep dg-extract-results.sh testsuite/ada/*/*.sum.sep dg-extract-results.sh -L testsuite/ada/*/*.log.sep and am doing a full bootstrap/regtest on x86_64-linux and i686-linux. But given that I can't reproduce the original problem, this is just a guess what might be a problem, so testing on darwin and/or solaris is needed. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807
[Bug c/39820] errors while compiling libc and the kernel
--- Comment #4 from ubizjak at gmail dot com 2009-04-20 09:56 --- (In reply to comment #2) (I'll have to read read up on the backtrace part), The backtrace is important for targets that are not so widely used (so developers sometimes won't have to build a crosscompiler to confirm the bug). On i386, it will earn you extra bonus points ;) It is the preprocessed source (standalone, and reduced as much as possible) that matters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39820
[Bug fortran/35423] Implement OpenMP workshare
--- Comment #6 from jakub at gcc dot gnu dot org 2009-04-20 11:00 --- Subject: Bug 35423 Author: jakub Date: Mon Apr 20 10:59:59 2009 New Revision: 146397 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146397 Log: PR fortran/35423 * trans.h (OMPWS_WORKSHARE_FLAG, OMPWS_CURR_SINGLEUNIT, OMPWS_SCALARIZER_WS, OMPWS_NOWAIT): Define. (ompws_flags): New extern decl. * trans-array.c (gfc_trans_scalarized_loop_end): Build OMP_FOR for the outer dimension if ompws_flags allow it. * trans.c (gfc_generate_code): Clear ompws_flags. * trans-expr.c (gfc_trans_assignment_1): Allow worksharing array assignments inside of !$omp workshare. * trans-stmt.c (gfc_trans_where_3): Similarly for where statements and constructs. * trans-openmp.c (ompws_flags): New variable. (gfc_trans_omp_workshare): Rewritten. * testsuite/libgomp.fortran/workshare2.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/workshare2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35423
[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-20 11:02 --- It bootstrapped/regtested on x86_64-linux and i686-linux just fine (both with -j48), results were merged correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807
[Bug tree-optimization/39675] [4.4 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-transform.c:1999
--- Comment #3 from irar at gcc dot gnu dot org 2009-04-20 11:26 --- Subject: Bug 39675 Author: irar Date: Mon Apr 20 11:26:18 2009 New Revision: 146399 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146399 Log: PR tree-optimization/39675 * tree-vect-loop.c (vect_transform_loop): Remove currently redundant check of the return code of vect_schedule_slp. Check that stmt_vec_info still exists for the statement, before checking its vectorization type. Added: trunk/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39675
[Bug tree-optimization/39675] [4.4 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-transform.c:1999
--- Comment #4 from irar at il dot ibm dot com 2009-04-20 11:30 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39675
[Bug tree-optimization/39675] [4.4 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-transform.c:1999
--- Comment #5 from rguenther at suse dot de 2009-04-20 11:32 --- Subject: Re: [4.4 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-transform.c:1999 On Mon, 20 Apr 2009, irar at il dot ibm dot com wrote: --- Comment #4 from irar at il dot ibm dot com 2009-04-20 11:30 --- Fixed. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39675
[Bug fortran/24886] different character length in actual and formal argument not detected
--- Comment #11 from pault at gcc dot gnu dot org 2009-04-20 11:57 --- (In reply to comment #10) Paul, can we close this one? Absolutely! It's done. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug c/39820] errors while compiling libc and the kernel
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-20 14:00 --- Please report on which target and which gcc revision you have this problem. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39820
[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives
--- Comment #6 from ramana at gcc dot gnu dot org 2009-04-20 14:30 --- Hi Andrew, I'm not quite sure what you're trying to do. What did you change to support arm-eabi* ? I changed libjava/configure.host to also support arm-eabi (arm*-elf|arm*-eabi)but that probably wasn't enough. Given that arm-elf appears to be supported for this as per the last comment in the bug report, I thought it would make sense to have it working for arm-eabi. I decided to go back and try an arm-elf build as well just now. I get a failure with jni-libjvm.cc with an error about ParkHelper not naming a type. Hence this appears to be broken on trunk as revision 146222 for arm-elf as well as arm-eabi. Ramana Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340
[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion
--- Comment #16 from singler at gcc dot gnu dot org 2009-04-20 14:44 --- I'm currently regression testing find_cstring_constify_equal_to.patch. Shall I do a new test case for this PR with a non-copyable object (generalization)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
[Bug c++/39798] would like flag to disable constructors for built-in types
--- Comment #1 from falk at debian dot org 2009-04-20 15:28 --- Removing the default constructor is a bad idea, since it would break about any available library including the standard lib in subtle ways, and would make g++ pretty much unusable. But apparently this isn't actually what you really want anyway, but actually you want to be able to create STL containers with uninitialized memory. This seems to me a pretty unusual requirement, and it could be achieved by creating a wrapper class for int with empty constructor, so I don't think this justifies language or library changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39798
[Bug target/38203] attribute `noreturn' isn't effective when -mthumb param is active
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-20 15:38 --- Confirmed with gcc version 4.5.0 20090416 (experimental) [trunk revision 146149] (GCC) -- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-20 15:38:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38203
[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives
--- Comment #7 from aph at redhat dot com 2009-04-20 15:44 --- Subject: Re: [arm] libjava build failure due to missing thread synchronization primitives I'm not quite sure what you're trying to do. What did you change to support arm-eabi* ? I changed libjava/configure.host to also support arm-eabi (arm*-elf|arm*-eabi)but that probably wasn't enough. Given that arm-elf appears to be supported for this as per the last comment in the bug report, I thought it would make sense to have it working for arm-eabi. I decided to go back and try an arm-elf build as well just now. I get a failure with jni-libjvm.cc with an error about ParkHelper not naming a type. Hence this appears to be broken on trunk as revision 146222 for arm-elf as well as arm-eabi. Probably. The java.lang.concurrent library requires thread support, so the only way you're going to get it to run with no threads is to create dummy definitions for ParkHelper. That should be easy, since null definitions for park() and unpark() will be fine. Just add these to libjava/no-threads.cc and libjava/include/no-threads.h. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340
[Bug bootstrap/12022] arm-coff build is broken: dies on crtstuff.c with #error
--- Comment #6 from ramana at gcc dot gnu dot org 2009-04-20 15:44 --- arm-coff is obsolete with trunk. Can this now be closed out? -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12022
[Bug middle-end/39794] [4.4/4.5 Regression] Miscompile with -O2 -funroll-loops
--- Comment #4 from bonzini at gnu dot org 2009-04-20 15:48 --- Maybe a stupid question, but shouldn't this canon_true_dependence call receive canonicalized MEMs from 'base' and 'store_info-cse_base'? I think so. The only way that DSE can see that something changed, is by having cselib_expand_value_rtx return a different expanded expression. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
[Bug c++/39798] would like flag to disable constructors for built-in types
--- Comment #2 from kraftche at cae dot wisc dot edu 2009-04-20 15:52 --- Subject: Re: would like flag to disable constructors for built-in types falk at debian dot org wrote: --- Comment #1 from falk at debian dot org 2009-04-20 15:28 --- Removing the default constructor is a bad idea, since it would break about any available library including the standard lib in subtle ways, and would make g++ pretty much unusable. But apparently this isn't actually what you really want anyway, but actually you want to be able to create STL containers with uninitialized memory. This seems to me a pretty unusual requirement, and it could be achieved by creating a wrapper class for int with empty constructor, so I don't think this justifies language or library changes. I was asking for a flag to change the behavior of the default/builtin constructors for intrinsic types. That isn't quite as extreme as removing default constructors entirely. Yes, I had requested that behavior with the intention of creating STL containers with uninitialized memory. I have used other work-arounds (wrapper classes and such) in a few instances where that was necessary for performance reasons. But there are other cases where a flag to change the constructor behavior for intrinsic types would be more appropriate. For example, it is often the case that the zero value assigned to all container entries is logically just as unitialized as any other arbitrary value. When debugging such code it would be nice if the zero-ing behavior could be removed because it masks such errors from tools like valgrind. Using a work-around would unnecessarily complicate the code because it is not necessary for correctness or performance. Anyway, this was purely a request for a wish-list type convenience feature. If it is infeasible or likely to introduce other subtle errors in the functioning of the standard library, then please close this bug with my thanks for taking the time to read it any my apologies for any nuisance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39798
[Bug c++/39798] would like flag to disable constructors for built-in types
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-20 15:59 --- For the record, I essentially agree with Falk, we are talking about a basic core language behaviour, in general we don't have switches to create different minor dialects of C++ at will... By the way, let's not encourage the use of STL, an acronym obsolete since the first C++ Standard, in 1998. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39798
[Bug c/39820] errors while compiling libc and the kernel
--- Comment #6 from justinmattock at gmail dot com 2009-04-20 16:03 ---
(In reply to comment #5)
Please report on which target and which gcc revision you have this problem.
operating system= LFS(used ubuntu for the starting of the creation,
then moved the new system over as soon as ready)
arch(tough to say) when compiling every lib/app I used CCFLAGS(example)
CFLAGS=-march=core2 -mtune=core2 -O2 -pipe -fomit-frame-pointer
CXXFLAGS=${CFLAGS}
MAKEOPTS={-j3}
I'm guessing it's setting the system at x86_32(but could be setting it at
x86_64)
As for gcc: the latest snapshot(I'll have to give you the number later, seems I
can't connect to the
snapshot server to supply the release number).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39820
[Bug c++/29388] [4.3 regression] ICE with invalid nested name specifier
--- Comment #15 from sje at cup dot hp dot com 2009-04-20 16:12 --- This bug is fixed for 4.4.0 and later releases but it was decided not to fix it for the 4.3 branch. See http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01275.html -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.0.4 |4.0.4 4.1.0 4.1.1 4.1.2 ||4.2.0 4.2.1 4.2.2 4.2.3 ||4.2.4 4.3.0 4.3.1 Priority|P2 |P4 Resolution||FIXED Target Milestone|4.3.4 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
[Bug middle-end/21718] real.c rounding not perfect
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-04-20 17:01 --- How about chucking real.c and using mpfr_t as the internal representation for real numbers inside GCC? I guess we still need something to encode/decode numbers to the target format, but IMHO we'll keep finding these corner cases until we convert everything over to MPFR underneath the hood. At that point, what's the use of having the extra layer of real.c? Maybe we use mpft_t at the tree level and convert to REAL_VALUE_TYPE when converting over to rtl. Another option would be to put an mpfr_t inside struct real_value instead of all those bitfields. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
[Bug c++/39822] New: ICE: Segmentation fault -- with function template default template arguments in c++0x mode
The following testcase produces a segmentation fault in --std=c++0x mode (in
4.3, 4.4, 4.5):
- 8 -
template typename
struct A ;
template typename X, template typename class = A
void test ( X )
{
A int T ;
test ( T ) ;
}
- 8 -
= 4.3.4 -std=c++0x =
$ x86_64-linux-gnu-g++-4.3.x -v -std=c++0x -c segfault.min.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_3-branch/configure
--prefix=/opt/software/gcc-x86_64/gcc-4.3.x --program-suffix=-4.3.x
--enable-languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.3.4 20090413 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-c' '-shared-libgcc' '-mtune=generic'
/opt/software/gcc-x86_64/gcc-4.3.x/libexec/gcc/x86_64-unknown-linux-gnu/4.3.4/cc1plus
-fpreprocessed segfault.min.ii -quiet -dumpbase segfault.min.ii -mtune=generic
-auxbase segfault.min -std=c++0x -version -o /tmp/cccslkh4.s
GNU C++ (GCC) version 4.3.4 20090413 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.4 20090413 (prerelease), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 922fef518d0100daafe6c2059a02f6bf
segfault.min.ii: In function 'void test(X)':
segfault.min.ii:2: internal compiler error: Segmentation fault
= =
= 4.3.4 =
$ x86_64-linux-gnu-g++-4.3.x -c segfault.min.ii
segfault.min.ii:4: error: default template arguments may not be used in
function templates
segfault.min.ii: In function 'void test(X)':
segfault.min.ii:7: error: no matching function for call to 'test(Aint)'
==
--
Summary: ICE: Segmentation fault -- with function template
default template arguments in c++0x mode
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at abeckmann dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39822
[Bug middle-end/21718] real.c rounding not perfect
--- Comment #8 from joseph at codesourcery dot com 2009-04-20 17:30 --- Subject: Re: real.c rounding not perfect On Mon, 20 Apr 2009, ghazi at gcc dot gnu dot org wrote: How about chucking real.c and using mpfr_t as the internal representation for real numbers inside GCC? I guess we still need something to encode/decode numbers to the target format, but IMHO we'll keep finding these corner cases until we convert everything over to MPFR underneath the hood. At that point, what's the use of having the extra layer of real.c? I sort of imagine that real.c should provide a wrapper layer that checks whether the real number is decimal (in which case it calls the dfp.c code which uses libdecnumber) or binary (in which case it uses MPFR, taking care to use the correct precision, range, subnormal handling etc. for the type in question) or split-binary (IBM long double) in which case it should use more complicated GCC-local code that ultimately uses MPFR underneath (bug 19779, bug 26374) - certainly the implementation should avoid causing problems for future split-binary folding implementation. (A base class from which implementations for decimal, binary and split-binary derive, if you wish.) I don't see any need for GCC to have its own implementation of the binary arithmetic - but it will need its own encoding/decoding support for all the many supported formats. I also wonder if the code for handling target formats and arithmetic on them should in principle be a library shared with GDB (which presently uses host floating-point arithmetic) but wouldn't like to try to persuade GDB to require MPFR. Another option would be to put an mpfr_t inside struct real_value instead of all those bitfields. You'd need to deal with the memory allocation/deallocation requirements, the MPFR allocation model is rather different from the fixed-size structures presently used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-20 17:36 --- (In reply to comment #3) and am doing a full bootstrap/regtest on x86_64-linux and i686-linux. But given that I can't reproduce the original problem, this is just a guess what might be a problem, so testing on darwin and/or solaris is needed. This works for powerpc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807
[Bug c++/39822] ICE: Segmentation fault -- with function template default template arguments in c++0x mode
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-20 17:41 --- Maybe Jason is willing to have a look... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39822
[Bug middle-end/39794] [4.4/4.5 Regression] Miscompile with -O2 -funroll-loops
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-20 17:45 --- Created an attachment (id=17656) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17656action=view) gcc45-pr39794.patch So shouldn't it use cselib_subst_to_values similarly to e.g. how sched-deps.c uses it? Completely untested patch (also there is one uncovered canon_true_dependence during global DSE), which fixes the testcase, but I haven't tried to find out whether this pessimizes code that DSE should actually optimize. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
[Bug c++/39822] ICE: Segmentation fault -- with function template default template arguments in c++0x mode
--- Comment #2 from gcc at abeckmann dot de 2009-04-20 17:50 --- probably a duplicate of bug #35828 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39822
[Bug c++/35828] [C++0x] ICE on default template template parameter in template function
--- Comment #6 from gcc at abeckmann dot de 2009-04-20 17:51 ---
I stumbled across this ICE on a very similar testcase (on 4.3.4, 4.4.0, 4.5.0):
-- 8 --
template typename struct A ;
template template typename class = A
void test ()
{
test ();
}
-- 8 --
=== 4.4.0 ==
$ x86_64-linux-gnu-g++-4.4.x -v -std=c++0x -c
ice-in-tsubst_decl-cp_pt_c_8101.min.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_4-branch/configure
--prefix=/opt/software/gcc-x86_64/gcc-4.4.x --program-suffix=-4.4.x
--enable-languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.4.0 20090413 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-c' '-shared-libgcc' '-mtune=generic'
/opt/software/gcc-x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus
-fpreprocessed ice-in-tsubst_decl-cp_pt_c_8101.min.ii -quiet -dumpbase
ice-in-tsubst_decl-cp_pt_c_8101.min.ii -mtune=generic -auxbase
ice-in-tsubst_decl-cp_pt_c_8101.min -std=c++0x -version -o /tmp/ccAHdc5J.s
GNU C++ (GCC) version 4.4.0 20090413 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20090413 (prerelease), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 4c95a5cf24794a394976148039ecc611
ice-in-tsubst_decl-cp_pt_c_8101.min.ii: In function void test():
ice-in-tsubst_decl-cp_pt_c_8101.min.ii:1: internal compiler error: in
tsubst_decl, at cp/pt.c:8101
===
I also got the segmentation fault on this similar testcase, reported as bug
#39822 before seeing this report:
-- 8 --
template typename
struct A ;
template typename X, template typename class = A
void test ( X )
{
A int T ;
test ( T ) ;
}
-- 8 --
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35828
[Bug c++/39823] New: GCC 4.4.0 produces bad code for libstdc++
GCC 4.4.0 20090414 i686-pc-linux-gnu Configure options: --prefix=/usr/local --enable-languages=c,c++ --enable-version-specific-runtime-libs --with-host-libstdcxx='-lstdc++ -lm' --disable-bootstrap --disable-shared --disable-nls Libraries: GMP 4.3, MPFR 2.4.1-p5, PPL 0.10.2, CLooG-PPL 0.15. In std::string::begin() (_ZNSs5beginEv): movl12(%ebp), %ebx movl(%ebx), %eax or: mov0xc(%ebp),%ebx ... mov(%ebx),%edx // crash here -- Summary: GCC 4.4.0 produces bad code for libstdc++ Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39823
[Bug c++/39823] GCC 4.4.0 produces bad code for libstdc++
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-04-20 19:26 --- Created an attachment (id=17657) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17657action=view) Preprocessed source g++ -S -std=gnu++0x -O1 string-inst.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39823
[Bug tree-optimization/36054] bad code generation with -ftree-vectorize
--- Comment #22 from d dot g dot gorbachev at gmail dot com 2009-04-20 19:31 --- (In reply to comment #21) Sorry, it seems it's because of malloc(), not a GCC bug... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
[Bug c/39824] New: ice in fold-const.c
I just tried to compile the Suse Linux package libxml2-2.7.3-1.1 with the GNU gcc version 4.5 snapshot 20090416. The compiler said xpath.c:6468: internal compiler error: in fold_convert_const_int_from_real, at f old-const.c:2214 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required. -- Summary: ice in fold-const.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39824
[Bug c/39824] ice in fold-const.c
--- Comment #1 from dcb314 at hotmail dot com 2009-04-20 20:19 --- Created an attachment (id=17658) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17658action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39824
[Bug middle-end/39823] GCC 4.4.0 produces bad code for libstdc++
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-20 20:23 --- Do you have an example where this happens? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39823
[Bug c/39825] New: sigsegv compiling ffmpeg svn
Trying to compile the last svn ffmpeg version in a powerpc machine with Ubuntu 8.10: $ uname -a Linux aliena 2.6.25-2-powerpc #1 Tue Sep 30 14:49:00 UTC 2008 ppc GNU/Linux $ gcc -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-softfloat --enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu Thread model: posix gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) The error is: gcc -DHAVE_AV_CONFIG_H -I. -I/home/sergio/ffmpeg -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -std=c99 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fomit-frame-pointer -maltivec -mabi=altivec -pthread -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -O3 -fno-math-errno -fno-signed-zeros -c -o libavcodec/bmp.o libavcodec/bmp.c libavcodec/bmp.c: In function bmp_decode_frame: libavcodec/bmp.c:51: warning: rgb[1] may be used uninitialized in this function libavcodec/bmp.c:51: warning: rgb[2] may be used uninitialized in this function libavcodec/bmp.c:307: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. make: *** [libavcodec/bmp.o] Error 1 Using the same gcc version in a 386 Ubuntu 8.10 machine there is no error. -- Summary: sigsegv compiling ffmpeg svn Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergio dot roa at dfki dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825
[Bug middle-end/39825] sigsegv compiling ffmpeg svn
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825
[Bug target/39826] New: Bootstrap failure in stage2
/home/dave/gnu/gcc/objdir/./prev-gcc/xgcc -B/home/dave/gnu/gcc/objdir/./prev-gcc / -B/home/dave/opt/gnu/gcc/gcc-4.5.0/arm-none-linux-gnueabi/bin/ -c -g -O2 -DIN _GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast- qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -W no-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common - DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../incl ude -I../../gcc/gcc/../libcpp/include -I/home/dave/opt/gnu/include -I../../gcc/ gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/h ome/dave/opt/gnu/include insn-attrtab.c -o insn-attrtab.o cc1: warnings being treated as errors ../../gcc/gcc/config/arm/arm-tune.md: In function 'bypass_p': ../../gcc/gcc/config/arm/arm-tune.md:5: error: comparison between 'enum processor_type' and 'enum attr_tune' ... -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: arm-none-linux-gnueabi Configured with: ../gcc/configure --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi --build=arm-none-linux-gnueabi --disable-stage1-checking --enable-languages=c,c++,fortran --enable-shared --enable-threads --disable-multilib --disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit --disable-libstdcxx-pch --prefix=/home/dave/opt/gnu/gcc/gcc-4.5.0 --with-gmp=/home/dave/opt/gnu Thread model: posix gcc version 4.5.0 20090420 (experimental) [trunk revision 146427] (GCC) -- Summary: Bootstrap failure in stage2 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: arm-none-linux-gnueabi GCC host triplet: arm-none-linux-gnueabi GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39826
[Bug target/39826] Bootstrap failure in stage2
--- Comment #1 from danglin at gcc dot gnu dot org 2009-04-20 20:46 --- Last successful bootstrap was revision 146003. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39826
[Bug target/39826] Bootstrap failure in stage2
--- Comment #2 from ian at airs dot com 2009-04-20 20:47 --- This has already been fixed in revision 146451, which I committed an hour or two ago. -- ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39826
[Bug tree-optimization/39821] 120% slowdown with vectorizer
--- Comment #2 from ubizjak at gmail dot com 2009-04-20 20:52 --- (In reply to comment #1) but the widening unpacking results in absymal code generated. Where are all the shifts coming from? Not from unpacking, but from mulv2di pattern from sse.md Can you please attach full source to create executable testcase? IIRC, execution times depend on target processor, and perhaps vect cost should be updated for this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39821
[Bug middle-end/39827] New: [4.5 Regression] ICE (segfault) when compiling gcc/varasm.c (in notice_global_symbol)
When bootstrapping (rev. 146452), I get the ICE in stage2: /home/tob/projects/gcc/gcc/varasm.c: In Function notice_global_symbol: /home/tob/projects/gcc/gcc/varasm.c:1595: internal compiler error: segmentation fault That's on x86-64-linux with the MALLOC_CHECK_=2 MALLOC_PERTURB_=D environment variables set. Valgrind shows: ==19870== Invalid read of size 8 ==19870==at 0x1648E68: propagate_with_phi (tree-ssa-phiprop.c:242) ==19870==by 0x164954C: tree_ssa_phiprop (tree-ssa-phiprop.c:349) ==19870==by 0xD27E20: execute_one_pass (passes.c:1290) ==19870==by 0xD27FB7: execute_pass_list (passes.c:1339) ==19870==by 0xD27FD5: execute_pass_list (passes.c:1340) ==19870==by 0x12174DF: tree_rest_of_compilation (tree-optimize.c:437) ==19870==by 0x1ABC634: cgraph_expand_function (cgraphunit.c:1051) ==19870==by 0x1ABC7E4: cgraph_expand_all_functions (cgraphunit.c:1110) ==19870==by 0x1ABCDA3: cgraph_optimize (cgraphunit.c:1324) ==19870==by 0x4E5076: c_write_global_declarations (c-decl.c:8184) ==19870==by 0xFBE33F: compile_file (toplev.c:988) ==19870==by 0xFC02D6: do_compile (toplev.c:2248) ==19870== Address 0x8292c30 is 0 bytes after a block of size 1,472 alloc'd ==19870==at 0x4C23784: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==19870==by 0x22808F0: xcalloc (xmalloc.c:162) ==19870==by 0x1649483: tree_ssa_phiprop (tree-ssa-phiprop.c:342) ==19870==by 0xD27E20: execute_one_pass (passes.c:1290) ==19870==by 0xD27FB7: execute_pass_list (passes.c:1339) ==19870==by 0xD27FD5: execute_pass_list (passes.c:1340) ==19870==by 0x12174DF: tree_rest_of_compilation (tree-optimize.c:437) ==19870==by 0x1ABC634: cgraph_expand_function (cgraphunit.c:1051) ==19870==by 0x1ABC7E4: cgraph_expand_all_functions (cgraphunit.c:1110) ==19870==by 0x1ABCDA3: cgraph_optimize (cgraphunit.c:1324) ==19870==by 0x4E5076: c_write_global_declarations (c-decl.c:8184) ==19870==by 0xFBE33F: compile_file (toplev.c:988) ==19870== ==19870== Invalid read of size 8 ==19870==at 0x1648FAB: propagate_with_phi (tree-ssa-phiprop.c:252) ==19870==by 0x164954C: tree_ssa_phiprop (tree-ssa-phiprop.c:349) ==19870==by 0xD27E20: execute_one_pass (passes.c:1290) ==19870==by 0xD27FB7: execute_pass_list (passes.c:1339) ==19870==by 0xD27FD5: execute_pass_list (passes.c:1340) ==19870==by 0x12174DF: tree_rest_of_compilation (tree-optimize.c:437) ==19870==by 0x1ABC634: cgraph_expand_function (cgraphunit.c:1051) [...] ==19870== Invalid read of size 8 ==19870==at 0x1648562: phivn_valid_p (tree-ssa-phiprop.c:107) ==19870==by 0x1648FCC: propagate_with_phi (tree-ssa-phiprop.c:252) ==19870==by 0x164954C: tree_ssa_phiprop (tree-ssa-phiprop.c:349) ==19870== Address 0x8292c38 is 8 bytes after a block of size 1,472 alloc'd ==19870==at 0x4C23784: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==19870==by 0x22808F0: xcalloc (xmalloc.c:162) ==19870==by 0x1649483: tree_ssa_phiprop (tree-ssa-phiprop.c:342) ==19870==by 0xD27E20: execute_one_pass (passes.c:1290) ==19870==by 0xD27FB7: execute_pass_list (passes.c:1339) [...] ==19870== Invalid read of size 1 ==19870==at 0x163B786: gimple_code (gimple.h:1030) ==19870==by 0x163BAA5: gimple_has_mem_ops (gimple.h:1240) ==19870==by 0x163BC99: gimple_vuse (gimple.h:1322) ==19870==by 0x1648572: phivn_valid_p (tree-ssa-phiprop.c:112) ... and then the ICE. -- Summary: [4.5 Regression] ICE (segfault) when compiling gcc/varasm.c (in notice_global_symbol) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: critical Priority: P3 Component: middle-end 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=39827
[Bug c++/39803] Bogus 'unused value' warning on declarations of non-POD arrays
--- Comment #2 from lcwu at gcc dot gnu dot org 2009-04-20 21:13 --- Subject: Bug 39803 Author: lcwu Date: Mon Apr 20 21:13:08 2009 New Revision: 146454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146454 Log: PR c++/39803 * gcc/cp/init.c (build_vec_init): Set TREE_NO_WARNING on the compiler-generated INDIRECT_REF expression. * gcc/testsuite/g++.dg/warn/Wunused-14.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39803
[Bug fortran/39800] Rejects PRIVATE TYPE as compont of local type declaration
--- Comment #4 from pault at gcc dot gnu dot org 2009-04-20 21:15 --- Created an attachment (id=17659) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17659action=view) patch for both aspects of the PR Bootstraps and regtests on FC9/x86_64 2009-04-20 Paul Thomas pa...@gcc.gnu.org PR fortran/39800 * resolve.c (is_sym_host_assoc): New function. (resolve_fl_derived): Call it when checking PRIVATE components of PUBLIC derived types. Change gfc_error to a gfc_notify_std with std=f2003. (resolve_fl_namelist): Call it twice to check for host association. 2009-04-20 Paul Thomas pa...@gcc.gnu.org PR fortran/39800 * gfortran.dg/private_type_13.f90: New test. * gfortran.dg/private_type_2.f90: Add option -std=f95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39800
[Bug middle-end/39827] [4.5 Regression] ICE (segfault) when compiling gcc/varasm.c (in notice_global_symbol)
--- Comment #1 from burnus at gcc dot gnu dot org 2009-04-20 21:15 --- Post script: If I unset MALLOC_CHECK_ then it compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39827
[Bug c++/39823] GCC 4.4.0 produces bad code for libstdc++
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-04-20 21:24 --- For example, a ppl-0.10.2 test numberinput1 crashed because of this. std::string::begin() is called at src/checked.cc:171 for (i = num.mantissa.begin(); ... -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Component|middle-end |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39823
[Bug c++/39803] Bogus 'unused value' warning on declarations of non-POD arrays
--- Comment #3 from lcwu at gcc dot gnu dot org 2009-04-20 21:45 --- The fix for this bug was committed to mainline at revision 146454. -- lcwu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39803
[Bug fortran/39811] Bogus warning for valid continuation lines
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-20 21:48:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39811
[Bug fortran/39800] Rejects PRIVATE TYPE as compont of local type declaration
--- Comment #5 from pault at gcc dot gnu dot org 2009-04-20 21:55 --- Subject: Bug 39800 Author: pault Date: Mon Apr 20 21:55:26 2009 New Revision: 146457 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146457 Log: 2009-04-20 Paul Thomas pa...@gcc.gnu.org PR fortran/39800 * resolve.c (is_sym_host_assoc): New function. (resolve_fl_derived): Call it when checking PRIVATE components of PUBLIC derived types. Change gfc_error to a gfc_notify_std with std=f2003. (resolve_fl_namelist): Call it twice to check for host association. 2009-04-20 Paul Thomas pa...@gcc.gnu.org PR fortran/39800 * gfortran.dg/private_type_13.f90: New test. * gfortran.dg/private_type_2.f90: Add option -std=f95. Added: trunk/gcc/testsuite/gfortran.dg/private_type_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/private_type_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39800
[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-20 22:01 --- And it works correctly on i386-darwin too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807
[Bug c++/39823] GCC 4.4.0 produces bad code for libstdc++
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-20 22:09 --- What makes you think there is a problem on the _ZNSs5beginEv side? 0(%ebp) is saved %ebp, 4(%ebp) is caller IP, 8(%ebp) is address of return value (returned by invisible reference), 12(%ebp) is this pointer. If there is a crash on dereferencing the this pointer, it is a problem in the caller. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39823
[Bug c++/13358] long long and C++ do not mix well
--- Comment #22 from manu at gcc dot gnu dot org 2009-04-20 22:13 --- Subject: Bug 13358 Author: manu Date: Mon Apr 20 22:12:52 2009 New Revision: 146459 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146459 Log: 2009-04-21 Manuel Lopez-Ibanez m...@gcc.gnu.org PR c++/13358 * doc/invoke.texi (-Wlong-long): Update description. * c-lex (interpret_integer): Only warn if there was no previous overflow and -Wlong-long is enabled. * c-decl.c (declspecs_add_type): Drop redundant flags. * c.opt (Wlong-long): Init to -1. * c-opts.c (sanitize_cpp_opts): Synchronize cpp's warn_long_long and front-end warn_long_long. Wlong-long only depends on other flags if it is uninitialized. * c-parser.c (disable_extension_diagnostics): warn_long_long is the same for CPP and FE. (restore_extension_diagnostics): Likewise. libcpp/ * init.c (cpp_create_reader): Wlong_long is disabled by default. * expr.c (cpp_classify_number): Give different messages for C and C++ front-ends. cp/ * parser.c (cp_parser_check_decl_spec): Drop redundant flags. * error.c (pedwarn_cxx98): New. * cp-tree.h (pedwarn_cxx98): Declare. testsuite/ * gcc.dg/wtr-int-type-1.c: Use two dg-warning to match two messages. Test for long long in system headers. * gcc.dg/c99-longlong-2.c: New. * g++.dg/warn/pr13358.C: New. * g++.dg/warn/pr13358-2.C: New. * g++.dg/warn/pr13358-3.C: New. * g++.dg/warn/pr13358-4.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/pr13358-2.C trunk/gcc/testsuite/g++.dg/warn/pr13358-3.C trunk/gcc/testsuite/g++.dg/warn/pr13358-4.C trunk/gcc/testsuite/g++.dg/warn/pr13358.C trunk/gcc/testsuite/gcc.dg/c99-longlong-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-lex.c trunk/gcc/c-opts.c trunk/gcc/c-parser.c trunk/gcc/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/error.c trunk/gcc/cp/parser.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/c90-longlong-1.c trunk/gcc/testsuite/gcc.dg/wtr-int-type-1.c trunk/libcpp/ChangeLog trunk/libcpp/expr.c trunk/libcpp/init.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358
[Bug c++/13358] long long and C++ do not mix well
--- Comment #23 from manu at gcc dot gnu dot org 2009-04-20 22:18 ---
FIXED in GCC 4.5.
+Warn if @samp{long long} type is used. This is enabled by either
+...@option{-pedantic} or @option{-Wtraditional} in ISO C90 and C++98
+modes. To inhibit the warning messages, use @option{-Wno-long-long}
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358
[Bug fortran/39811] Bogus warning for valid continuation lines
--- Comment #2 from burnus at gcc dot gnu dot org 2009-04-20 22:19 --- Subject: Bug 39811 Author: burnus Date: Mon Apr 20 22:19:25 2009 New Revision: 146460 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146460 Log: 2009-04-20 Tobias Burnus bur...@net-b.de PR fortran/39811 * scanner.c (load_line): Fix bogus compile-time diagnostic. 2009-04-20 Tobias Burnus bur...@net-b.de PR fortran/39811 * gfortran.dg/continuation_11.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/continuation_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39811
[Bug fortran/39811] Bogus warning for valid continuation lines
--- Comment #3 from burnus at gcc dot gnu dot org 2009-04-20 22:21 --- FIXED on the trunk (4.5). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39811
[Bug regression/39828] New: [4.4 regression] missing symbols in 64bit libgcc
sorry for noticing the issue that late. Matthias this is 4.4 configured with --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-objc-gc --disable-softfloat --enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu the 64bit libgcc is missing the following symbols (output from dpkg-gensymbols): @@ -1,7 +1,7 @@ libgcc_s.so.1 lib64gcc1 #MINVER# gcc_...@gcc_3.0 1:4.1.1 gcc_3@gcc_3.3.1 1:4.1.1 - gcc_3@gcc_3.3.4 1:4.2.1 +#MISSING: 1:4.4-20090418-1# gcc_3@gcc_3.3.4 1:4.2.1 gcc_...@gcc_3.3 1:4.1.1 gcc_3@gcc_3.4.2 1:4.1.1 gcc_3@gcc_3.4.4 1:4.1.1 @@ -31,8 +31,8 @@ __absv...@gcc_3.0 1:4.1.1 __absv...@gcc_3.0 1:4.1.1 __absv...@gcc_3.4.4 1:4.1.1 - __add...@gcc_3.0 1:4.2.1 - __add...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __add...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __add...@gcc_3.0 1:4.2.1 __addv...@gcc_3.0 1:4.1.1 __addv...@gcc_3.0 1:4.1.1 __addv...@gcc_3.4.4 1:4.1.1 @@ -50,24 +50,24 @@ __deregister_frame_i...@glibc_2.0 1:4.1.1 __deregister_frame_info_ba...@gcc_3.0 1:4.1.1 __div...@gcc_4.0.0 1:4.1.1 - __div...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __div...@gcc_3.0 1:4.2.1 __div...@gcc_4.0.0 1:4.1.1 - __div...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __div...@gcc_3.0 1:4.2.1 __div...@gcc_4.0.0 1:4.1.1 __div...@gcc_3.0 1:4.1.1 __emutls_get_addr...@gcc_4.3.0 1:4.3 __emutls_register_com...@gcc_4.3.0 1:4.3 __enable_execute_st...@gcc_3.4.2 1:4.1.1 - __eq...@gcc_3.0 1:4.2.1 - __eq...@gcc_3.0 1:4.2.1 - __extendsf...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __eq...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __eq...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __extendsf...@gcc_3.0 1:4.2.1 __ffs...@gcc_3.0 1:4.1.1 __ffs...@gcc_3.0 1:4.1.1 __fixd...@gcc_3.0 1:4.1.1 - __fixd...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __fixd...@gcc_3.0 1:4.2.1 __fixd...@gcc_3.0 1:4.1.1 __fixs...@gcc_3.0 1:4.1.1 - __fixs...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __fixs...@gcc_3.0 1:4.2.1 __fixs...@gcc_3.0 1:4.1.1 __fixt...@gcc_3.0 1:4.1.1 __fixt...@gcc_3.0 1:4.1.1 @@ -82,16 +82,16 @@ __floatd...@gcc_3.0 1:4.1.1 __floatd...@gcc_3.0 1:4.1.1 __floatd...@gcc_3.0 1:4.1.1 - __floats...@gcc_3.0 1:4.2.1 - __floats...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __floats...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __floats...@gcc_3.0 1:4.2.1 __floatt...@gcc_3.0 1:4.1.1 __floatt...@gcc_3.0 1:4.1.1 __floatt...@gcc_3.0 1:4.1.1 __floatund...@gcc_4.2.0 1:4.2.1 __floatund...@gcc_4.2.0 1:4.2.1 __floatund...@gcc_4.2.0 1:4.2.1 - __floatuns...@gcc_4.2.0 1:4.2.1 - __floatuns...@gcc_4.2.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __floatuns...@gcc_4.2.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __floatuns...@gcc_4.2.0 1:4.2.1 __floatunt...@gcc_4.2.0 1:4.2.1 __floatunt...@gcc_4.2.0 1:4.2.1 __floatunt...@gcc_4.2.0 1:4.2.1 @@ -101,33 +101,33 @@ __gcc_q...@gcc_3.4.4 1:4.1.1 __gcc_q...@gcc_3.4.4 1:4.1.1 __gcc_q...@gcc_3.4.4 1:4.1.1 - __ge...@gcc_3.0 1:4.2.1 - __ge...@gcc_3.0 1:4.2.1 - __gt...@gcc_3.0 1:4.2.1 - __gt...@gcc_3.0 1:4.2.1 - __le...@gcc_3.0 1:4.2.1 - __le...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __ge...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __ge...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __gt...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __gt...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __le...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __le...@gcc_3.0 1:4.2.1 __lshr...@gcc_3.0 1:4.1.1 - __lt...@gcc_3.0 1:4.2.1 - __lt...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __lt...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __lt...@gcc_3.0 1:4.2.1 __mod...@gcc_3.0 1:4.1.1 __mul...@gcc_4.0.0 1:4.1.1 - __mul...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __mul...@gcc_3.0 1:4.2.1 __mul...@gcc_4.0.0 1:4.1.1 - __mul...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __mul...@gcc_3.0 1:4.2.1 __mul...@gcc_4.0.0 1:4.1.1 __mul...@gcc_3.0 1:4.1.1 __mulv...@gcc_3.0 1:4.1.1 __mulv...@gcc_3.0 1:4.1.1 __mulv...@gcc_3.4.4 1:4.1.1 - __ne...@gcc_3.0 1:4.2.1 - __neg...@gcc_3.0 1:4.2.1 - __neg...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __ne...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __neg...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __neg...@gcc_3.0 1:4.2.1 __neg...@gcc_3.0 1:4.1.1 __negv...@gcc_3.0 1:4.1.1 __negv...@gcc_3.0 1:4.1.1 __negv...@gcc_3.4.4 1:4.1.1 - __ne...@gcc_3.0 1:4.2.1 +#MISSING: 1:4.4-20090418-1# __ne...@gcc_3.0 1:4.2.1 __parity...@gcc_3.4 1:4.1.1 __parity...@gcc_3.4 1:4.1.1 __popcount...@gcc_3.4 1:4.1.1 @@ -141,18 +141,18
[Bug regression/39828] [4.4 regression] missing symbols in 64bit libgcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-20 22:48 --- Actually I think this was on purpose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39828
[Bug target/39634] powerpc64 libgcc contains useless softfp functions
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-20 22:50 --- *** Bug 39828 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634
[Bug regression/39828] [4.4 regression] missing symbols in 64bit libgcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-20 22:50 --- Yes it is, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634. These functions are never called because they are soft-fp functions so there is no reason for them to be in existant in libgcc as they are not used. *** This bug has been marked as a duplicate of 39634 *** -- 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=39828
[Bug middle-end/39757] inconsistency in array bounds checking with -O3
--- Comment #2 from manu at gcc dot gnu dot org 2009-04-20 22:56 --- (In reply to comment #1) -O3 has extra inlining. ~/trunk/146344/build/gcc/cc1 -DNO_LCMS -Wall -Werror -O3 dcraw.i -fno-inline-functions -fno-inline Still the same warnings. So, it seems to be some other reason. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39757
[Bug regression/39828] [4.4 regression] missing symbols in 64bit libgcc
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-20 23:06 --- Note that powerpc64-linux configured gcc (both with --with-cpu=default32 and without it, i.e. defaulting to -m32 resp. -m64) weren't exporting these in 64-bit libgcc_s.so.1, checked 4.1 and 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39828
[Bug target/21691] ICE in reload_cse_simplify_operands, at postreload.c:391 (ARM -mthumb -Os)
--- Comment #7 from ramana at gcc dot gnu dot org 2009-04-20 23:09 --- Waiting for feedback if this can be reproduced on a more modern toolchain. I can't reproduce this with trunk today. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
[Bug tree-optimization/39829] New: [4.5 Regression] ICE with some code that produces VCE
A simple testcase:
void foo (void * DAG_temp117584)
{
char uA;
void* pA;
void* pB;
void* pC;
do {
int DAG_temp117585;
int DAG_temp117586;
void ** __indir_union1 = (void**)DAG_temp117584;
DAG_temp117585 = *__indir_union1;
DAG_temp117586 = DAG_temp117585;
if ( DAG_temp117586 != (int)268435456 )
pA = (void*)uA;
pB = (void*)pA;
pC = pB;
union __block_indir0_u { struct { int val; } __indir_struct; }
* __indir_union = (union __block_indir0_u*)pC;
f(__indir_union-__indir_struct.val);
DAG_temp117584 += 64;
} while (1);
}
CUT ---
Compile at -O1, we get the following ICE:
gcc/gcc/testsuite/gcc.c-torture/compile/20090206-2.c:19: internal compiler
error: in expand_expr_addr_expr_1, at expr.c:6817
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
If we compile with -O2, we get:
gcc/gcc/testsuite/gcc.c-torture/compile/20090206-2.c:1: internal compiler
error: in verify_expr, at tree-cfg.c:2876
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
forwprop1 produces:
D.1591_10 = VIEW_CONVERT_EXPRunion __block_indir0_u(pA).__indir_struct.val;
CCP2 produces:
D.1591_10 = VIEW_CONVERT_EXPRunion
__block_indir0_u(uA).__indir_struct.val;
And then somewhere we must lose that the address of uA is taken because with
-O2 PRE creates:
uA.18_15 = uA_11(D);
D.2674_1 = uA.18_15;
D.2676_8 = D.2674_1;
D.2675_7 = D.2676_8;
pretmp.19_13 = VIEW_CONVERT_EXPRunion
__block_indir0_u(D.2675_7).__indir_struct.val;
Which is just incorrect.
--
Summary: [4.5 Regression] ICE with some code that produces VCE
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39829
[Bug tree-optimization/39829] [4.5 Regression] ICE with some code that produces VCE
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-20 23:51 --- I thought http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01375.html would help but that patch was already applied. I have not tried 4.4.0 yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39829
[Bug target/5267] invoke.texi RS/6000 and PowerPC Options list needs cleanup
--- Comment #6 from bje at gcc dot gnu dot org 2009-04-20 23:59 --- I believe all of the concerns raised have been fixed. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5267
[Bug tree-optimization/39821] 120% slowdown with vectorizer
--- Comment #3 from ramiro86 at hotmail dot com 2009-04-21 00:08 --- Created an attachment (id=17660) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17660action=view) tarball of a simple testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39821
[Bug tree-optimization/39821] 120% slowdown with vectorizer
--- Comment #4 from ramiro86 at hotmail dot com 2009-04-21 00:10 --- I've attached a simple testcase. The system I'm running this on is a q6600 with 64-bit Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39821
[Bug testsuite/39830] New: gcc.dg/torture/pr39678.c fails if char type is unsigned
On gcc.dg/torture/pr39678.c, it assigns -3 to a char variable (x.c = -3) and
later checks if the char variable equals to -3 (if (x.c != 3)).
This check would fail if the char type is unsigned.
Suggest to change -3 to 3. This change does not affect the purpose of the test
case.
I have tried this tiny test.
#include stdio.h
int main() {
char ch = -3;
if (ch != -3) {
printf (ch != -3\n);
return 1;
}
return 0;
}
$~/local/gcc_i686/bin/gcc -funsigned-char testx.c -o testx-2
$./testx-2
ch != -3
$~/local/gcc_i686/bin/gcc -fsigned-char testx.c -o testx-1
$ ./testx-1
pass
$ ~/local/gcc_i686/bin/gcc -vUsing built-in specs.
Target: i686-linux
Configured with: --target=i686-linux --build=i686-linux --host=i686-linux
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20090413 (prerelease) (GCC)
Thanks!
--
Summary: gcc.dg/torture/pr39678.c fails if char type is unsigned
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39830
[Bug testsuite/39830] gcc.dg/torture/pr39678.c fails if char type is unsigned
--- Comment #2 from jingyu at google dot com 2009-04-21 00:54 --- Subject: Re: gcc.dg/torture/pr39678.c fails if char type is unsigned Thanks H.J. for your quick response! Do you want me to prepare a patch? I don't have write permission though. Thanks, Jing On Mon, Apr 20, 2009 at 5:49 PM, hjl dot tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from hjl dot tools at gmail dot com 2009-04-21 00:49 --- (In reply to comment #0) On gcc.dg/torture/pr39678.c, it assigns -3 to a char variable (x.c = -3) and later checks if the char variable equals to -3 (if (x.c != 3)). This check would fail if the char type is unsigned. Suggest to change -3 to 3. This change does not affect the purpose of the test case. That is fine with me. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39830 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39830
[Bug testsuite/39830] gcc.dg/torture/pr39678.c fails if char type is unsigned
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-21 00:55 --- (In reply to comment #2) Subject: Re: gcc.dg/torture/pr39678.c fails if char type is unsigned Thanks H.J. for your quick response! Do you want me to prepare a patch? Please do. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39830
[Bug testsuite/39831] New: gcc.target/i386/excess-precision-*.c assume the default -mfp-math does not include SSE
i386-darwin defaults to having -mfpmath=sse,387 by default so
gcc.target/i386/excess-precision-{1,2,3}.c fail because those testcases depend
on excessive precision to happen.
--
Summary: gcc.target/i386/excess-precision-*.c assume the default
-mfp-math does not include SSE
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39831
[Bug testsuite/39830] gcc.dg/torture/pr39678.c fails if char type is unsigned
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-21 02:39 ---
(In reply to comment #4)
Created an attachment (id=17661)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17661action=view) [edit]
Patch to fix the issue
2009-04-20 Jing Yu jin...@google.com
PR testsuite/39830
* gcc.dg/torture/pr39678.c: Change the assignment to the char variable
from a negative number to a positive number.
Attach the patch. Both GCC trunk and GCC-4.4 needs update.
Thanks!
Patch should be sent to gcc-patches mailing list. BTW, you can also use
struct X {
signed char c;
__complex__ float val;
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39830
[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-04-21 02:46 ---
I consider this undefined behaviour, so enhancement is the correct severity.
People wanting to mess with non-standard init order should probably be taking
steps to insure that libstdc++ is initialized first anyway. Not doing so is
arguably a bug. especially as it's not hard to do:
ie:
#include iostream
void f1() __attribute__ ((constructor (101)));
void f1()
{
std::ios_base::Init i;
std::cout f1 std::endl;
}
int main() { }
But anyway
libstdc++ is currently not using the first 100 slots reserved for the GNU
implementation as per:
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
No efforts or audit have ever been made as to enshrine a specified init order
for libstd++. Locales, mutexes, and __mt_allocator would all have to be scoped
and modified as code is/was changed. I consider this doable, but probably as
much work in the long run as the efforts for symbol versioning. There may be an
advantage to doing this for size reasons, as then iostream's
// For construction of filebuffers for cout, cin, cerr, clog et. al.
static ios_base::Init __ioinit;
could be killed.
If there was some kind of real advantage, I would be more into this whole idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-04-21 03:04 --- I believe the problem is the symbol was exported when it shouldn't have been. How? The signbit macro is provided by math.h. But it's not in the baseline files showing that it is exported. This question was originally asked here: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00197.html -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug middle-end/39825] sigsegv compiling ffmpeg svn
--- Comment #1 from bje at gcc dot gnu dot org 2009-04-21 05:03 --- Thanks for the report. Could you possibly attach the preprocessed source file that triggers the internal compiler error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825
[Bug middle-end/35260] ICE in ipa-type-escape.c with -fipa-struct-reorg -fipa-type-escape
--- Comment #1 from bje at gcc dot gnu dot org 2009-04-21 05:02 --- Confirmed in mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35260
[Bug libstdc++/39832] New: program built by x86_64-pc-mingw32-gcc run crash, maybe for _Unwind_SjLj_Unregister,
I built a x86_64-pc-mingw32 toolchain from scratch with the newest code from
SVN ( 20090421 ).
and the build an application using wxWidgets library, it runs crashed.
(gdb) r
Starting program: E:\code\DMediaInfo/DMediaInfo.exe
[New Thread 2656.0xbd8]
warning: Can not parse XML library list; XML support was disabled at
compile tim
e
[New Thread 2656.0x964]
Program received signal SIGSEGV, Segmentation fault.
0x006e289b in wxObject (this=0x1)
at f:/devel/devel64/include/wx/object.h:412
412 wxObject() { m_refData = NULL; }
Current language: auto; currently c++
(gdb) p this
$1 = (class wxObject * const) 0x1
the wxObject was create by new operator, it return 0x1 which is wrong.
--
44 _GLIBCXX_WEAK_DEFINITION void *
45 operator new (std::size_t sz) throw (std::bad_alloc)
46 {
47 void *p;
48
49 /* malloc (0) is unpredictable; avoid it. */
50 if (sz == 0)
51 sz = 1;
52 p = (void *) malloc (sz);
53 while (p == 0)
54 {
55 new_handler handler = __new_handler;
56 if (! handler)
57 #ifdef __EXCEPTIONS
58 throw bad_alloc();
59 #else
60 std::abort();
61 #endif
62 handler ();
63 p = (void *) malloc (sz);
64 }
65
66 return p;
67 }
malloc() return the correct value, but after _Unwind_SjLj_Unregister(),
$rax changed to 0x1.
--
Dump of assembler code for function _Znwy:
0x00702d50 _Znwy+0: push %rbp
0x00702d51 _Znwy+1: lea 0x11e8(%rip),%rax # 0x703f40
__gx
x_personality_sj0
0x00702d58 _Znwy+8: lea 0x7ea9(%rip),%rdx # 0x70ac08
__DT
OR_LIST__+24584
0x00702d5f _Znwy+15: sub $0x90,%rsp
0x00702d66 _Znwy+22: mov %rcx,0xa0(%rsp)
0x00702d6e _Znwy+30: mov %rax,0x50(%rsp)
0x00702d73 _Znwy+35: lea 0x20(%rsp),%rcx
0x00702d78 _Znwy+40: lea 0x90(%rsp),%rax
0x00702d80 _Znwy+48: mov %rdx,0x58(%rsp)
0x00702d85 _Znwy+53: lea 0xb1(%rip),%rdx # 0x702e3d
_Znwy+
237
0x00702d8c _Znwy+60: mov %rsp,0x70(%rsp)
0x00702d91 _Znwy+65: mov %rax,0x60(%rsp)
0x00702d96 _Znwy+70: mov %rdx,0x68(%rsp)
0x00702d9b _Znwy+75: callq 0x68df08 _Unwind_SjLj_Register
0x00702da0 _Znwy+80: cmpq $0x0,0xa0(%rsp)
0x00702da9 _Znwy+89: mov $0x1,%eax
0x00702dae _Znwy+94: cmovne 0xa0(%rsp),%rax
0x00702db7 _Znwy+103: mov %rax,%rcx
0x00702dba _Znwy+106: mov %rax,0xa0(%rsp)
0x00702dc2 _Znwy+114: callq 0x68f708 malloc
0x00702dc7 _Znwy+119: test %rax,%rax
0x00702dca _Znwy+122: jne 0x702df8 _Znwy+168
0x00702dcc _Znwy+124: nopl 0x0(%rax)
0x00702dd0 _Znwy+128: mov 0x49861(%rip),%rax # 0x74c638
__n
ew_handler
0x00702dd7 _Znwy+135: test %rax,%rax
0x00702dda _Znwy+138: je 0x702e0b _Znwy+187
0x00702ddc _Znwy+140: movl $0x1,0x28(%rsp)
0x00702de4 _Znwy+148: callq *%rax
0x00702de6 _Znwy+150: mov 0xa0(%rsp),%rcx
0x00702dee _Znwy+158: callq 0x68f708 malloc
0x00702df3 _Znwy+163: test %rax,%rax
0x00702df6 _Znwy+166: je 0x702dd0 _Znwy+128
0x00702df8 _Znwy+168: lea 0x20(%rsp),%rcx
0x00702dfd _Znwy+173: callq 0x68df10 _Unwind_SjLj_Unregister
0x00702e02 _Znwy+178: add $0x90,%rsp
0x00702e09 _Znwy+185: pop %rbp
0x00702e0a _Znwy+186: retq
0x00702e0b _Znwy+187: mov $0x8,%ecx
0x00702e10 _Znwy+192: callq 0x703090 __cxa_allocate_exception
0x00702e15 _Znwy+197: lea 0x49754(%rip),%rdx # 0x74c570
_ZT
VSt9bad_alloc+16
0x00702e1c _Znwy+204: lea -0x1dd3(%rip),%r8 # 0x701050
~bad
_alloc
0x00702e23 _Znwy+211: mov %rax,%rcx
0x00702e26 _Znwy+214: mov %rdx,(%rax)
0x00702e29 _Znwy+217: lea 0x186f0(%rip),%rdx # 0x71b520
_ZT
ISt9bad_alloc
0x00702e30 _Znwy+224: movl $0x1,0x28(%rsp)
0x00702e38 _Znwy+232: callq 0x703ee0 __cxa_throw
0x00702e3d _Znwy+237: mov 0x38(%rsp),%rax
0x00702e42 _Znwy+242: mov 0x30(%rsp),%rcx
0x00702e47 _Znwy+247: cmp $0x,%rax
0x00702e4b _Znwy+251: je 0x702e5a _Znwy+266
0x00702e4d _Znwy+253: movl $0x,0x28(%rsp)
0x00702e55 _Znwy+261: callq 0x68df00 _Unwind_SjLj_Resume
0x00702e5a _Znwy+266: mov %eax,0x28(%rsp)
0x00702e5e _Znwy+270: callq 0x7034c0 __cxa_call_unexpected
End of assembler dump.
(gdb)
Breakpoint 2, 0x00702dfd in operator new (sz=64)
at ../../../../gcc/libstdc++-v3/libsupc++/new_op.cc:53
53 ../../../../gcc/libstdc++-v3/libsupc++/new_op.cc: No such file or
direct
ory.
in ../../../../gcc/libstdc++-v3/libsupc++/new_op.cc
(gdb) echo $pc
$pc(gdb) p $pc
$28 = (void (*)(void)) 0x702dfd operator new(unsigned long long)+173
(gdb) p $rax
$29 = 63978736
(gdb) p $rcx
$30 = 2292480
(gdb) x/i $pc
0x702dfd _Znwy+173: callq 0x68df10 _Unwind_SjLj_Unregister
(gdb) ni
67 in ../../../../gcc/libstdc++-v3/libsupc++/new_op.cc
(gdb) p $pc
$31 = (void (*)(void)) 0x702e02 operator new(unsigned long long)+178
(gdb) p $rax
$32 = 1
(gdb)
---
E:\code\DMediaInfogcc -v
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple definitions
--- Comment #14 from drangon dot mail at gmail dot com 2009-04-21 05:35 --- how to fix this multiple definition issue ? adjust the linker to allow this ? or remove the ordinary C library function in lib64_libmingwex_a-wininterlocked.o and just keep the inline function ? or remove the inline function, replace by a function declaration which use the implementation from lib64_libmingwex_a-wininterlocked.o ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
