[Bug bootstrap/31776] Bootstrap fails with "error: conflicting types for strsignal"
--- Comment #7 from brooks at gcc dot gnu dot org 2007-05-03 07:22 --- The above commit should fix this problem. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug bootstrap/31776] Bootstrap fails with "error: conflicting types for strsignal"
--- Comment #6 from brooks at gcc dot gnu dot org 2007-05-03 07:15 --- Subject: Bug 31776 Author: brooks Date: Thu May 3 06:14:52 2007 New Revision: 124373 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124373 Log: PR bootstrap/31776 * system.h: Remove inclusion of double-int.h * tree.h: Include double-int.h * gengtype.c: Likewise * cfgloop.h: Likewise * Makefile.in: Adjust dependencies on double-int.h Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/cfgloop.h trunk/gcc/gengtype.c trunk/gcc/system.h trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug middle-end/31793] [4.3 Regression] internal compiler error in build_int_cst_wide tree.c:902
--- Comment #3 from jojelino at gmail dot com 2007-05-03 05:59 ---
(In reply to comment #1)
confirmed. it works now. thanks
> Created an attachment (id=13499)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13499&action=view) [edit]
> demux_vqf.i
>
(In reply to comment #2)
> I think this was fixed by:
> 2007-05-01 Ian Lance Taylor <[EMAIL PROTECTED]>
>
> PR tree-optimization/31739
> * tree-vrp.c (vrp_val_is_max): New static function.
> (vrp_val_is_min): New static function.
> (set_value_range_to_value): Use TYPE_{MAX,MIN}_VALUE rather than
> copying the node.
> (set_value_range): Use vrp_val_is_{max,min}.
> (extract_range_from_assert): Likewise.
> (extract_range_from_binary_expr): Likewise.
> (extract_range_from_unary_expr): Likewise.
> (dump_value_range, vrp_meet): Likewise.
> (vrp_visit_phi_node): Likewise.
> * tree.c (build_distinct_type_copy): Revert change of 2007-04-27.
>
> Can you try again?
>
--
jojelino at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31793
[Bug middle-end/31796] New: Evaluate remquo/remainder/drem at compile-time
GCC should use MPFR to evaluate builtins remquo, remainder (and the common extension function drem) at compile-time when they are provided with constant arguments. The forthcoming mpfr-2.3.0 has suitable functionality to do this. -- Summary: Evaluate remquo/remainder/drem at compile-time Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: ghazi at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org BugsThisDependsOn: 29335 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31796
[Bug middle-end/30251] Evaluate bessel functions at compile-time
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-05-03 03:43 --- Bessel patches posted here: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01624.html http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01663.html Awaiting review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30251
[Bug middle-end/31795] New: -Wunused should warn about variables set but never read
Patches like this: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00059.html expose a problem with GCC's -Wunused machinery. Namely, that it fails to detect cases where a variable is set but never read. I'd like GCC to detect these cases automatically. I think it probably requires auditing everywhere the TREE_USED flag is set, and splitting it into a TREE_READ vs. a TREE_ASSIGNED flag. Or something like that. Then we could distinguish these two cases and issue the appropriate warning for cases like in the above URL. Seems like there's about 150 "TREE_USED.*=" across the whole source base. That's a lot, but not insurmountable. IIRC, the SGI compiler had this ability many years ago. It would be nice IMHO if we caught up in this regard. -- Summary: -Wunused should warn about variables set but never read Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31795
[Bug bootstrap/31776] Bootstrap fails with "error: conflicting types for strsignal"
--- Comment #5 from brooks at gcc dot gnu dot org 2007-05-03 03:24 --- If this analysis of the problem is correct, the patch attached here should fix it: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00135.html -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-03 02:50:22 |2007-05-03 03:24:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt ("IRQ")))
--- Comment #7 from david+gcc at porkrind dot org 2007-05-03 03:14 --- This still fails in gcc 4.1.2 under certain conditions. I can provide a test case if necessary. -- david+gcc at porkrind dot org changed: What|Removed |Added CC||david+gcc at porkrind dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
[Bug bootstrap/31776] Bootstrap fails with "error: conflicting types for strsignal"
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-05-03 02:50 --- I see a similar failure on sparc-sun-solaris2.10 (where I have gmp installed in some place not available to system.h without -I flags.) Without clear access to gmp.h, configure botches the test for rlim_t and defines a bogus fallback that conflicts with the real one in sys/resource.h. This is definitely the problem noted by Andrew above. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-03 02:50:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug c++/31663] [4.3 Regression] Segfault in constrain_class_visibility with anonymous namespace
--- Comment #3 from spark at gcc dot gnu dot org 2007-05-03 00:11 --- Subject: Bug 31663 Author: spark Date: Wed May 2 23:11:13 2007 New Revision: 124363 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124363 Log: gcc/ChangeLog: 2007-05-02 Seongbae Park <[EMAIL PROTECTED]> PR c++/31663 * c-common.c (strip_pointer_or_array_types): New function. * c-common.h (strip_pointer_or_array_types): New function declaration. gcc/cp/ChangeLog: 2007-05-02 Seongbae Park <[EMAIL PROTECTED]> PR c++/31663 * decl2.c (constrain_class_visibility): Use strip_pointer_or_array_types instead of strip_array_types. gcc/testsuite/ChangeLog: 2007-05-02 Seongbae Park <[EMAIL PROTECTED]> PR C++/31663 * g++.dg/warn/anonymous-namespace-2.C: New. * g++.dg/warn/anonymous-namespace-2.h: New. Added: trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-2.C trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-2.h Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31663
[Bug rtl-optimization/31771] [4.3 Regression] g++.dg/gomp/pr26913.C ICEs
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-05-02 23:34 --- Subject: Bug 31771 Author: rakdver Date: Wed May 2 22:34:38 2007 New Revision: 124362 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124362 Log: PR tree-optimization/31771 * tree-cfg.c (move_block_to_fn): Assign bb to the correct index. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31771
[Bug ada/31174] [4.2 regression] ACATS C380004 fails
--- Comment #3 from anhvofrcaus at gmail dot com 2007-05-02 23:28 --- It still remains in prerelease-4.2.0-20070501. In addition, C46051a fails also. It will be reported separately if it has not been filed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-05-02 23:07 --- That patch certainly didn't fix anything, so the problem is probably latent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31733
[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)
--- Comment #5 from tbm at cyrius dot com 2007-05-02 23:03 --- I just checked and you get the ICE with r124216 but not anymore with r124217. I'm not sure r124217 fixed this problem or just made it latent; maybe Richi can comment. Anyway, I'll try to find out when the ICE first appeared tomorrow if that'd be helpful. r124217 | rguenth | 2007-04-27 13:43:42 + (Fri, 27 Apr 2007) | 24 lines -- 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=31733
[Bug middle-end/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-02 23:01 --- gfortran.fortran-torture/execute/st_function.f90 at -O1 and above fail the same way (it is the same bug, I looked into the failure, though it does not use bcopy so that work around will not work). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker GCC target triplet|ia64-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug c++/986] g++ misses warning for & on temporary
--- Comment #10 from bangerth at dealii dot org 2007-05-02 22:56 --- *** Bug 31788 has been marked as a duplicate of this bug. *** -- bangerth at dealii dot org changed: What|Removed |Added CC||dkruger at stevens dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug c++/31788] no warnings for passing temps by reference into obviously longer lifetime pointer
--- Comment #1 from bangerth at dealii dot org 2007-05-02 22:56 --- *** This bug has been marked as a duplicate of 986 *** -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31788
[Bug tree-optimization/30565] ICE with -O1 -ftree-pre -ftree-loop-linear
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-30 10:17:47 |2007-05-02 22:14:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30565
[Bug ada/31174] [4.2 regression] ACATS C380004 fails
--- Comment #2 from anhvofrcaus at gmail dot com 2007-05-02 22:06 --- It still remains in prerelease-4.2.0-20070501. In addition, C46051a fails also. It will be reported separately if it has not been filed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #19 from mmitchel at gcc dot gnu dot org 2007-05-02 21:59 --- If this is a valid program, as we seem to think it is, then this is a serious bug. However, if it's the front-end bug that Richard suspects, there's not much we can do about it in the near term. The ball is firmly in Jason's court. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug c/31537] duplicate weakref emitted with IMA
--- Comment #3 from aldot at gcc dot gnu dot org 2007-05-02 21:43 --- Richi suggested it was a FE bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31537
[Bug target/30052] [4.2 Regression] possible quadratic behaviour.
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #32 from mark at codesourcery dot com 2007-05-02 21: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: > Here is one approach which fixes the test case. This introduces a new tree > code, ALIASING_CONVERT_EXPR. It is conveyed into RTL via a flag on REGS: > REG_ALIAS_ALL. I didn't try to really union the alias sets, I just said that > the result of placement new can alias anything. This patch is essentially > untested. I think this is a reasonable approach I agree that it will require care to make sure this is threaded through the compiler in all places (for example, we may need variants of STRIP_NOPs that do/don't strip it), but anything else is going to be too pessimistic. I think that creating a separate type, with TYPE_REF_CAN_ALIAS_ALL set, is worse: it's not the type of the expression that matters, but the action of the expression itself. It's the act of placement-newing that destroys type information; after that, the type that you have is what you expect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug preprocessor/27777] Bad diagnostic emission when #error contains a trigraph
--- Comment #5 from aldot at gcc dot gnu dot org 2007-05-02 21:40 --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14634#c12 has a similar case, from the looks, and is a regression WRT 4.1.2 where this did work fine for me (the diagnostic was not garbled). -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug c/31537] duplicate weakref emitted with IMA
--- Comment #2 from geoffk at gcc dot gnu dot org 2007-05-02 21:23 --- Since these are both 'static', shouldn't they be named things like __gthrw_pthread_once.247 in the assembler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31537
[Bug c++/31759] [4.3 regression] ICE with OpenMP and exceptions
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-05-02 20:39 --- *** This bug has been marked as a duplicate of 31771 *** -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31759
[Bug rtl-optimization/31771] [4.3 Regression] g++.dg/gomp/pr26913.C ICEs
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-05-02 20:39 --- *** Bug 31759 has been marked as a duplicate of this bug. *** -- rakdver at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31771
[Bug middle-end/31699] [4.3 Regression] -march=opteron -ftree-vectorize generates wrong code
--- Comment #6 from dorit at il dot ibm dot com 2007-05-02 20:38 --- patch: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00111.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31699
[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'
--- Comment #1 from eweddington at cso dot atmel dot com 2007-05-02 20:34 --- This must be specific to RTEMS/newlib, as 4.2.0-20070430 (RC2) builds without error with: CFLAGS=-D__USE_MINGW_ACCESS \ ../gcc-$version/configure \ --prefix=$installdir \ --target=avr \ --enable-languages=c,c++ \ --with-dwarf2 \ --enable-win32-registry=WinAVR-$release \ --disable-nls \ --with-gmp=/usr/local \ --with-mpfr=/usr/local \ --enable-doc \ --disable-libssp \ 2>&1 | tee $package-configure.log for host=mingw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##
--- Comment #13 from tromey at gcc dot gnu dot org 2007-05-02 20:34 --- I checked in the follow-up patch to the trunk. So this fully works on 4.3. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.0 |4.2.0 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##
--- Comment #12 from tromey at gcc dot gnu dot org 2007-05-02 20:33 --- Subject: Bug 28709 Author: tromey Date: Wed May 2 19:33:44 2007 New Revision: 124356 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124356 Log: libcpp PR preprocessor/28709: * macro.c (paste_tokens): Remove PASTE_LEFT from the old lhs. gcc/testsuite PR preprocessor/28709: * gcc.dg/cpp/pr28709.c: New file. Added: trunk/gcc/testsuite/gcc.dg/cpp/pr28709.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
[Bug other/31790] [4.2 regression] 4.2.0 RC2 build failure host=mingw target=avr
--- Comment #2 from eweddington at cso dot atmel dot com 2007-05-02 20:28 --- Woops! Thanks for catching that! I forgot I had --disable-fixincludes still in there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31790
[Bug target/31794] Problem while compiling gcc for m32c-elf
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-05-02 20:26 --- Created an attachment (id=13500) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13500&action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31794
[Bug target/31794] New: Problem while compiling gcc for m32c-elf
Hello, there seems to be a gcc problem with the target 'm32c-elf': /home/mstein/sim/m32c-elf/build/./gcc/xgcc -B/home/mstein/sim/m32c-elf/build/./gcc/ -B/n/07/mstein/cross-local/m32c-elf/m32c-elf/bin/ -B/n/07/mstein/cross-local/m32c-elf/m32c-elf/lib/ -isystem /n/07/mstein/cross-local/m32c-elf/m32c-elf/include -isystem /n/07/mstein/cross-local/m32c-elf/m32c-elf/sys-include -O2 -g -O2 -mcpu=m32cm -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/n/07/mstein/svn/trunk/libgcc -I/n/07/mstein/svn/trunk/libgcc/. -I/n/07/mstein/svn/trunk/libgcc/../gcc -I/n/07/mstein/svn/trunk/libgcc/../include -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /n/07/mstein/svn/trunk/libgcc/../gcc/unwind-dw2.c /n/07/mstein/combined-trunk/libgcc/../gcc/unwind-dw2.c: In function 'execute_cfa_program': /n/07/mstein/combined-trunk/libgcc/../gcc/unwind-dw2.c:1100: error: unrecognizable insn: (insn 83 82 84 3 /n/07/mstein/combined-trunk/libgcc/../gcc/unwind-dw2.c:874 (parallel [ (set (reg:PSI 133) (lshiftrt:PSI (reg:PSI 134) (neg:QI (const_int -31 [0xffe1] (clobber (scratch:HI)) ]) -1 (nil) (nil)) /n/07/mstein/combined-trunk/libgcc/../gcc/unwind-dw2.c:1100: internal compiler error: in extract_insn, at recog.c:2119 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [unwind-dw2.o] Error 1 The SVN revision was 124341. -- Summary: Problem while compiling gcc for m32c-elf Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m32c-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31794
[Bug c++/27177] [4.0/4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #13 from mark at codesourcery dot com 2007-05-02 20:02 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] ICE in build_simple_base_path,
at cp/class.c:474
crowl at google dot com wrote:
> I think (B*)(D*)0 is a conversion under 4.10.
>
>> Has anyone asked about this case on the core reflector?
>
> Would you like me to?
Yes, please!
If this is considered valid, it's important to understand why: is it
your NULL pointer argument, or that this is a static_cast, even though D
isn't complete yet? That will affect the validity of:
struct B {};
struct D;
D* p;
struct D: public B {
static const int i = sizeof ((B*)p);
};
which is similar, but does not involve the NULL pointer.
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug middle-end/31793] [4.3 Regression] internal compiler error in build_int_cst_wide tree.c:902
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-02 19:56 ---
I think this was fixed by:
2007-05-01 Ian Lance Taylor <[EMAIL PROTECTED]>
PR tree-optimization/31739
* tree-vrp.c (vrp_val_is_max): New static function.
(vrp_val_is_min): New static function.
(set_value_range_to_value): Use TYPE_{MAX,MIN}_VALUE rather than
copying the node.
(set_value_range): Use vrp_val_is_{max,min}.
(extract_range_from_assert): Likewise.
(extract_range_from_binary_expr): Likewise.
(extract_range_from_unary_expr): Likewise.
(dump_value_range, vrp_meet): Likewise.
(vrp_visit_phi_node): Likewise.
* tree.c (build_distinct_type_copy): Revert change of 2007-04-27.
Can you try again?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31793
[Bug c/31793] [4.3 Regression] internal compiler error in build_int_cst_wide tree.c:902
--- Comment #1 from jojelino at gmail dot com 2007-05-02 19:54 --- Created an attachment (id=13499) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13499&action=view) demux_vqf.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31793
[Bug c/31793] New: [4.3 Regression] internal compiler error in build_int_cst_wide tree.c:902
configure flag --- Using built-in specs. Target: i686-pc-cygwin Configured with: ./configure --prefix=/usr --disable-win32-registry --enable-thr eads=posix --enable-languages=all --with-win32-nlsapi=unicode --enable-tls --dis able-bootstrap : (reconfigured) ./configure --prefix=/usr --disable-win32-regist ry --enable-threads=posix --enable-languages=all --with-win32-nlsapi=unicode --e nable-tls --disable-bootstrap : (reconfigured) ./configure --prefix=/usr --disab le-win32-registry --enable-threads=posix --enable-languages=all --with-win32-nls api=unicode --enable-tls --disable-bootstrap : (reconfigured) ./configure --pref ix=/usr --disable-win32-registry --enable-threads=posix --enable-languages=all - -with-win32-nlsapi=unicode --enable-tls --disable-bootstrap : (reconfigured) ./c onfigure --prefix=/usr --disable-win32-registry --enable-threads=posix --enable- languages=all --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap : (re configured) ./configure --prefix=/usr --disable-win32-registry --enable-threads= posix --enable-languages=all --with-win32-nlsapi=unicode --enable-tls --disable- bootstrap : (reconfigured) ./configure --prefix=/usr --disable-win32-registry -- enable-threads=posix --enable-languages=all --with-win32-nlsapi=unicode --enable -tls --disable-bootstrap Thread model: posix gcc version 4.3.0 20070430 (experimental) --- svn revision #124297 --- demux_vqf.s --- .file "demux_vqf.c" .text .p2align 4,,15 .def_demux_seek_vqf;.scl3; .type 32; .endef _demux_seek_vqf: rep ; ret .p2align 4,,15 .def_demux_close_vqf; .scl3; .type 32; .endef _demux_close_vqf: rep ; ret .section .rdata,"dr" .align 4 LC2: .ascii "stream_read: WARNING! s->buf_pos>s->buf_len\12\0" .text .p2align 4,,15 .def_demux_vqf_fill_buffer; .scl3; .type 32; .endef _demux_vqf_fill_buffer: pushl %ebp pushl %edi pushl %esi pushl %ebx subl$44, %esp movl64(%esp), %edx movl68(%edx), %eax movl64(%esp), %edx movl100(%eax), %eax movl%eax, 28(%esp) movl156(%eax), %eax movl8(%eax), %eax movl%eax, 24(%esp) movl32(%edx), %eax movl40(%eax), %edx movl72(%eax), %ecx movl48(%eax), %edi movl52(%eax), %ebp movl%edx, 36(%esp) xorl%edx, %edx movl36(%eax), %ebx testl %ecx, %ecx je L43 addl$44, %esp movl%edx, %eax popl%ebx popl%esi popl%edi popl%ebp ret L43: movl24(%esp), %eax movl$64, (%esp) movl%eax, 32(%esp) call_malloc movl32(%esp), %edx movl%edx, (%eax) movl_correct_pts, %edx movl%eax, 20(%esp) movl$0, 56(%eax) testl %edx, %edx jne L9 fldz L11: movl36(%esp), %eax xorl%esi, %esi addl%edi, %ebx adcl%ebp, %esi xorl%edx, %edx subl%eax, %ebx movl20(%esp), %eax sbbl%edx, %esi fstpl 8(%eax) fldsLC1 fstl16(%eax) movl$0, 32(%eax) fstpl 24(%eax) movl$0, 36(%eax) movl$0, 44(%eax) movl$1, 48(%eax) movl$0, 52(%eax) movl$0, 40(%eax) movl24(%esp), %eax testl %eax, %eax jg L44 movl20(%esp), %eax movl$0, (%eax) pushl %esi pushl %ebx fildq (%esp) addl$8, %esp movl28(%esp), %edx movl156(%edx), %eax movl8(%eax), %edx pushl %edx fildl (%esp) addl$4, %esp testl %edx, %edx jns L21 fstp%st(0) movl%edx, %eax andl$1, %edx shrl%eax orl %edx, %eax pushl %eax fildl (%esp) addl$4, %esp fadd%st(0), %st L21: fdivrp %st, %st(1) movl68(%esp), %eax movl20(%esp), %edx movl%ebx, 32(%eax) movl%esi, 36(%eax) fstpl 16(%eax) movl40(%edx), %eax jmp L22 .p2align 4,,7 L9: fldsLC1 jmp L11 L44: movl24(%esp), %eax addl$8, %eax movl%eax, (%esp) call_malloc movl20(%esp), %edx testl %eax, %eax movl%eax, 40(%edx) je L14 addl24(%esp), %eax movl$0, (%eax) movl$0, 4(%eax) pushl %esi pushl %ebx fildq (%esp) addl$8, %esp movl28(%esp), %ed
[Bug libstdc++/31777] GLIBCXX_FORCE_NEW doesn't always work in pool_allocator
--- Comment #2 from paolo at gcc dot gnu dot org 2007-05-02 19:37 --- Subject: Bug 31777 Author: paolo Date: Wed May 2 18:37:00 2007 New Revision: 124355 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124355 Log: 2007-05-02 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/31777 * include/ext/pool_allocator.h (__pool_alloc<>::allocate, __pool_alloc<>::deallocate): Fix _S_force_new check. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/pool_allocator.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31777
[Bug c/31792] ivopts generates slightly worse code for tight loop from zlib
--- Comment #1 from vlad at petric dot cc 2007-05-02 19:36 --- Created an attachment (id=13498) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13498&action=view) Isolated code which illustrates the ivopts issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31792
[Bug c/31792] New: ivopts generates slightly worse code for tight loop from zlib
The loop in question is isolated from zlib 1.2.3's longest_match() function (it
s longest_match()'s inner-most loop). Given two char * pointers, scan and
match, it figures out their longest common prefix. After every 8 character
comparisons, it also tests whether scan has reached the end.
int inner_longest_match(char *scan, char *match, char *strend)
{
char *start_scan = scan;
do {
} while (*++scan == *++match && *++scan == *++match &&
*++scan == *++match && *++scan == *++match &&
*++scan == *++match && *++scan == *++match &&
*++scan == *++match && *++scan == *++match &&
scan < strend);
return scan - start_scan;
}
Verison: gcc version 4.3.0 20070425 (experimental)
Compilation: /usr/local/mygcc/bin/gcc -g -O2 -c lmatch.c -o lmatch.o . This has
ivopts turned on by default. The generated code is:
11: 0f b6 42 01 movzbl 0x1(%edx),%eax
15: 8d 5a 01lea0x1(%edx),%ebx
18: 3a 41 01cmp0x1(%ecx),%al
1b: 75 64 jne81
1d: 0f b6 42 02 movzbl 0x2(%edx),%eax
21: 8d 5a 02lea0x2(%edx),%ebx
24: 3a 41 02cmp0x2(%ecx),%al
27: 75 58 jne81
29: 0f b6 42 03 movzbl 0x3(%edx),%eax
2d: 8d 5a 03lea0x3(%edx),%ebx
30: 3a 41 03cmp0x3(%ecx),%al
33: 75 4c jne81
35: 0f b6 42 04 movzbl 0x4(%edx),%eax
39: 8d 5a 04lea0x4(%edx),%ebx
3c: 3a 41 04cmp0x4(%ecx),%al
3f: 75 40 jne81
41: 0f b6 42 05 movzbl 0x5(%edx),%eax
45: 8d 5a 05lea0x5(%edx),%ebx
48: 3a 41 05cmp0x5(%ecx),%al
4b: 75 34 jne81
4d: 0f b6 42 06 movzbl 0x6(%edx),%eax
51: 8d 5a 06lea0x6(%edx),%ebx
54: 3a 41 06cmp0x6(%ecx),%al
57: 75 28 jne81
59: 0f b6 42 07 movzbl 0x7(%edx),%eax
5d: 8d 5a 07lea0x7(%edx),%ebx
60: 3a 41 07cmp0x7(%ecx),%al
63: 75 1c jne81
65: 83 c2 08add$0x8,%edx
68: 8d 41 08lea0x8(%ecx),%eax
6b: 89 c1 mov%eax,%ecx
6d: 0f b6 02movzbl (%edx),%eax
70: 3a 01 cmp(%ecx),%al
72: 75 04 jne78
74: 39 d6 cmp%edx,%esi
76: 77 99 ja 11
Let's take a look at one "element" of the comparison - i.e., the sixth *++scan
== *++match
41: 0f b6 42 05 movzbl 0x5(%edx),%eax
45: 8d 5a 05lea0x5(%edx),%ebx
48: 3a 41 05cmp0x5(%ecx),%al
4b: 75 34 jne81
It's doing the following:
- load the character at scan_start_loop + 5 into eax
- put scan_start_loop + 5 into ebx (if this is the element that breaks the
comparison, we need the last scan value)
- compare the lowest byte in eax to the byte at match_start_loop + 5
Ok, what's the problem? The problem is that scan actually outlives the loop -
it's needed for the return value. So for each of the eight elements, gcc
(actually ivopts) copies scan_start_loop + n into a temporary. An extra
register is needed.
Without ivopts (i.e., -fno-ivopts), the generated code is:
10: 83 c2 01add$0x1,%edx
13: 0f b6 02movzbl (%edx),%eax
16: 3a 41 01cmp0x1(%ecx),%al
19: 75 53 jne6e
1b: 83 c2 01add$0x1,%edx
1e: 0f b6 02movzbl (%edx),%eax
21: 3a 41 02cmp0x2(%ecx),%al
24: 75 48 jne6e
26: 83 c2 01add$0x1,%edx
29: 0f b6 02movzbl (%edx),%eax
2c: 3a 41 03cmp0x3(%ecx),%al
2f: 75 3d jne6e
31: 83 c2 01add$0x1,%edx
34: 0f b6 02movzbl (%edx),%eax
37: 3a 41 04cmp0x4(%ecx),%al
3a: 75 32 jne6e
3c: 83 c2 01add$0x1,%edx
3f: 0f b6 02movzbl (%edx),%eax
42: 3a 41 05cmp0x5(%ecx),%al
45: 75 27 jne6e
47: 83 c2 01add$0x1,%edx
4a: 0f b6 02movzbl (%edx),%eax
4d: 3a 41 06cmp0x6(%ecx),%al
50: 75 1c jne6e
52: 83 c2 01add$0x1,%edx
55: 0f b6 02movzbl (%edx),%eax
58: 3a 41 07cmp0x7(%ecx),%al
5b: 75 11 jne6e
5d: 83 c2 01add$0x1,%edx
60: 83 c1 08
[Bug middle-end/29715] fold produces &a - 4
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-02 18:49 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29715
[Bug middle-end/29715] fold produces &a - 4
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-02 18:48 --- Subject: Bug 29715 Author: pinskia Date: Wed May 2 17:47:50 2007 New Revision: 124354 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124354 Log: Forgot to add the PR number to the last changelog entry: 2007-05-02 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/29715 * fold-const.c (fold_comparision): Remove the "foo++ == CONST" transformation. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29715
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #31 from pinskia at gcc dot gnu dot org 2007-05-02 17:14 --- Also should we fold the case where ALIASING_CONVERT_EXPR and the argument type are the same. Also I think this right now causes a regression on the tunk interacting with the patch which fixed PR 31146. -- 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 #30 from pinskia at gcc dot gnu dot org 2007-05-02 17:10 --- Only one suggestion for the patch, instead of: - if (is_gimple_cast (t) || TREE_CODE (t) == VIEW_CONVERT_EXPR) + if (is_gimple_cast (t) || TREE_CODE (t) == VIEW_CONVERT_EXPR + || TREE_CODE (t) == ALIASING_CONVERT_EXPR) Shouldn't ALIASING_CONVERT_EXPR be considered a gimple cast? Yes you might need to change some places which use is_gimple_cast but it seems like a better idea to treat it as a cast rather than anything else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31787] bfin: Dreg expected for CLI. Input text was P0.
--- Comment #1 from ralf_corsepius at rtems dot org 2007-05-02 17:05 --- I've been trying to attach the *.i of this breakdown, but creating attachments seems to be broken right now. I am always receiving this: undef error - Undefined subroutine Fh::slice at data/template/template/en/default/global/hidden-fields.html.tmpl line 58 -- ralf_corsepius at rtems dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #29 from ian at airs dot com 2007-05-02 16:57 --- Created an attachment (id=13497) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13497&action=view) Patch Here is one approach which fixes the test case. This introduces a new tree code, ALIASING_CONVERT_EXPR. It is conveyed into RTL via a flag on REGS: REG_ALIAS_ALL. I didn't try to really union the alias sets, I just said that the result of placement new can alias anything. This patch is essentially untested. I'm not very happy with this approach because it doesn't fail safe: it's too easy to lose the special aliasing, and then the problem appears again, but only with a more complicated test case. A safer approach might be to change the type returned by placement new and mark it as TYPE_REF_CAN_ALIAS_ALL, but then I'm worried about type conversion and type comparison problems, since it isn't actually a different type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/31789] odd roundoff behavior (may be due to 80-bit vs. 64-bit behavior?
--- Comment #3 from dkruger at stevens dot edu 2007-05-02 16:56 --- small correction: I forgot that the call to the function being integreated isn't inline. That clearly is what causes the problem. Also, if you change the bogus .6 coefficient to .5, the fact that it's a nice number makes the problem go away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31789
[Bug middle-end/31490] Compile error section type conflict
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-02 16:41 --- > I can reproduce this bug any architecture with -fpic option Oh and this is why it fails without -fpic on powerpc64-linux-gnu as really it is always PIC with the toc based ABI. >workaround for the bug: Actually that looks like the correct fix from reading output.h's comment about these section categories. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-02 16:41:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug c/31791] Builtin functions too intrusive causing -Werror build to break.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-02 16:36 --- > I have tried the 3.4.6 compiler with same results. But judging the situation I > expect this to be a conceptual issue. Well there are two things, first you are using a reserved name in C99. The C standard dicttakes most of what GCC implements. exp2 is not in your namespace, really, it is in the standard C99 namespace. Try adding -ansi or -std=c89 if you want only the reserved names in C89 to be builtins. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31791
[Bug c/31791] New: Builtin functions too intrusive causing -Werror build to break.
My code contains function identifiers that are are unique within their
namespace. However, they collide with some builtin function generating a
"conflicting types for built-in function " warning. The project build
will break when using -Werror inspite the code being semantically correct.
I have tried the 3.4.6 compiler with same results. But judging the situation I
expect this to be a conceptual issue.
The switch -fno-builtin=function is not an alternative/solution as this is
conceptually something different. I *want* builtins, but *only* when they have
been marked as such, and that should be when I include appropriate header files
containing their prototypes.
Built-in functions should not exist in global namespace but should only be
activated on demand. Preferable as a part of a function prototype such as in
math.h:
extern double exp2 (double) __attribute__ ((builtin ("exp2")));
The danger of the current (global) approach is that future builds might break
if some application used identifier is included into the list of builtin
functions. Besides, "hardcoding" names is something preferably avoided and I
can imagine situations in where I will stretch programming rules and would like
to have builtins under alternative names {but that is a different topic).
The following is the test code. It does not include math.h so it should not
issue a warning.
#include
void exp1(void)
{
printf("Experiment 1\n");
}
void exp2(char* arg1)
{
printf("Experiment 2\n");
}
void exp3(char* arg1, char* arg2)
{
printf("Experiment 3\n");
}
int main (int argc, char *argv[])
{
switch (argc) {
case 1:
exp1();
break;
case 2:
exp2(argv[1]);
break;
case 3:
exp3(argv[1], argv[2]);
break;
default:
break;
}
return 0;
}
--
Summary: Builtin functions too intrusive causing -Werror build to
break.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: franz at digital-connectivity dot com
GCC build triplet: athlon-cerberus-linux
GCC host triplet: athlon-cerberus-linux
GCC target triplet: athlon-cerberus-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31791
[Bug target/31490] Compile error section type conflict
--- Comment #6 from dtemirbulatov at gmail dot com 2007-05-02 16:25 --- workaround for the bug: --- gcc/varasm.c-orig 2007-05-02 19:15:04.0 +0400 +++ gcc/varasm.c2007-05-02 19:16:17.0 +0400 @@ -5519,6 +5519,8 @@ decl_readonly_section (tree decl, int re case SECCAT_RODATA_MERGE_STR_INIT: case SECCAT_RODATA_MERGE_CONST: case SECCAT_SRODATA: +case SECCAT_DATA_REL_RO: +case SECCAT_DATA_REL_RO_LOCAL: return true; break; default: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug other/31790] [4.2 regression] 4.2.0 RC2 build failure host=mingw target=avr
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-02 16:24 --- Don't do this: --disable-fixincludes This is the same thing: it hurts when I do this The doctor told you not to do that. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31790
[Bug other/31790] New: [4.2 regression] 4.2.0 RC2 build failure host=mingw target=avr
4.2.0 RC2 fails to build on host=mingw target=avr Configured as: CFLAGS=-D__USE_MINGW_ACCESS \ ../gcc-$version/configure \ --prefix=$installdir \ --target=$target \ --enable-languages=c,c++ \ --with-dwarf2 \ --enable-win32-registry=WinAVR-$release \ --disable-nls \ --with-gmp=/usr/local \ --with-mpfr=/usr/local \ --enable-doc \ --disable-fixincludes \ --disable-libssp \ 2>&1 | tee $package-configure.log Note that the same configuration successfully builds for 4.1.2. Error: gcc -D__USE_MINGW_ACCESS -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -o cpp.exe gcc.o opts-common.o gcc-options.o cppspec.o \ intl.o prefix.o version.o ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a /c/avrdev/gcc/build/./gcc/xgcc -B/c/avrdev/gcc/build/./gcc/ -B/c/WinAVR-GCC-4.2.0/avr/bin/ -B/c/WinAVR-GCC-4.2.0/avr/lib/ -isystem /c/WinAVR-GCC-4.2.0/avr/include -isystem /c/WinAVR-GCC-4.2.0/avr/sys-include -dumpspecs > tmp-specs mv tmp-specs specs echo | /c/avrdev/gcc/build/./gcc/xgcc -B/c/avrdev/gcc/build/./gcc/ -B/c/WinAVR-GCC-4.2.0/avr/bin/ -B/c/WinAVR-GCC-4.2.0/avr/lib/ -isystem /c/WinAVR-GCC-4.2.0/avr/include -isystem /c/WinAVR-GCC-4.2.0/avr/sys-include -E -dM - | \ sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \ -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ sort -u > tmp-macro_list /bin/sh ../../gcc-4.2.0-20070430/gcc/../move-if-change tmp-macro_list macro_list echo timestamp > s-macro_list make[2]: *** No rule to make target `../build-i686-pc-mingw32/fixincludes/fixinc.sh', needed by `stmp-fixinc'. Stop. make[2]: Leaving directory `/c/avrdev/gcc/build/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/c/avrdev/gcc/build' make: *** [all] Error 2 -- Summary: [4.2 regression] 4.2.0 RC2 build failure host=mingw target=avr Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eweddington at cso dot atmel dot com GCC host triplet: mingw GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31790
[Bug c++/31789] odd roundoff behavior (may be due to 80-bit vs. 64-bit behavior?
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-02 16:15 --- This works for me on powerpc-darwin. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i686-linux | GCC target triplet||i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31789
[Bug target/31490] Compile error section type conflict
--- Comment #5 from dtemirbulatov at gmail dot com 2007-05-02 16:14 --- I can reproduce this bug any architecture with -fpic option -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug ada/15606] Legal program rejected, RM 8.2(22)
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-02 16:13 --- Error message looks right to me, the instantiation is not finished so you cannot use foo twice here without disambiguating it, e.g: procedure FOO is new Standard.foo; Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15606
[Bug c++/31789] odd roundoff behavior (may be due to 80-bit vs. 64-bit behavior?
--- Comment #1 from dkruger at stevens dot edu 2007-05-02 16:12 --- Created an attachment (id=13496) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13496&action=view) odd roundoff behavior -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31789
[Bug c++/31789] New: odd roundoff behavior (may be due to 80-bit vs. 64-bit behavior?
Adding +x to -x should result in a hardware zero. But in this small gaussian integration routine, .6^3 + -.6^3 is not zero. When the same computation is done inline, it works. This may be due to the hardware rounding properties, but given that the integration routine is inline, I wouldn't see why it would behave differently than the physically inline code. It's at the very least weird. My apologies if this isn't a bug. -- Summary: odd roundoff behavior (may be due to 80-bit vs. 64-bit behavior? Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dkruger at stevens dot edu GCC host triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31789
[Bug c++/31788] New: no warnings for passing temps by reference into obviously longer lifetime pointer
I was surprised to discover that passing a reference to a temp that is clearly
going out of scope is not tracked at all. While in general catching a pointer
to a value with shorter lifetime could be hard, if it's auto, it's fairly
obvious.In the following example, the commented out code correctly gives a
warning, but the second does not, even though the semantics are exactly the
same. This came up because I accidentally passed a value into an object by
value, but stored it by reference, which is shown second.
Example:
#if 0
int* foo(int a) {
int x = 2 + a;
return &x;
}
#endif
int* foo(int a) {
int x = 2 + a;
int* p = &x;
return p;
}
int main() {
foo(3);
}
2. class-based accidental pass by value.
class Foo {
private:
int& x;
public:
Foo(int x_) : x(x_) {} // THIS IS WRONG!
};
--
Summary: no warnings for passing temps by reference into
obviously longer lifetime pointer
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dkruger at stevens dot edu
GCC host triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31788
[Bug ada/25902] GNAT Bug Box, Assert_Failure in sem when using default box <> for invisible record component
--- Comment #3 from charlet at gcc dot gnu dot org 2007-05-02 16:03 --- Works fine on trunk: $ gcc -c rooms.adb rooms.adb:6:43: expected private type "DOOR" defined at doors.ads:3 rooms.adb:6:43: found a composite type -- charlet 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=25902
[Bug ada/24726] Gigi abort, Code=508
--- Comment #5 from charlet at gcc dot gnu dot org 2007-05-02 15:56 --- Fixed, so closing. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24726
[Bug ada/27300] gnattools/configure.ac selects incorrect body for indepsw on GNU/Linux
--- Comment #3 from charlet at gcc dot gnu dot org 2007-05-02 15:53 --- Patch applied on trunk apparently -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27300
[Bug rtl-optimization/31771] [4.3 Regression] g++.dg/gomp/pr26913.C ICEs
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-05-02 15:53 --- I'm checking this. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-02 15:53:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31771
[Bug ada/30078] [ Ada ] problems mixing Tasks and recursion
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-02 15:50 --- lowering severity -- charlet at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30078
[Bug ada/29462] Sign ignored on fixed point multiplication
--- Comment #3 from dewi dot daniels at silver-software dot com 2007-05-02 15:48 --- Subject: RE: Sign ignored on fixed point multiplication Yes, that output looks correct to me :) > -Original Message- > From: charlet at gcc dot gnu dot org > [mailto:[EMAIL PROTECTED] > Sent: 02 May 2007 13:21 > To: [EMAIL PROTECTED] > Subject: [Bug ada/29462] Sign ignored on fixed point multiplication > > > > > --- Comment #2 from charlet at gcc dot gnu dot org > 2007-05-02 13:20 --- I get the following on trunk, which > I assume is the expected output: > > $ ./test > X = -1.0 > Y = -1.0 > X * Y = 1.0 > T (X) * Y = 1.0 > > > -- > > charlet 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=29462 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29462
[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|nobody at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31733
[Bug target/9511] [Cygwin] Can't detect whether threading enabled
--- Comment #12 from davek at gcc dot gnu dot org 2007-05-02 15:41 --- Sorry for the repeated emails, bugzilla wouldn't let me verify and close this bug without forcing me to add a comment. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9511
[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-05-02 15:40 --- I cannot reproduce this. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rakdver at gcc dot gnu dot |nobody at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31733
[Bug target/9511] [Cygwin] Can't detect whether threading enabled
--- Comment #11 from davek at gcc dot gnu dot org 2007-05-02 15:38 --- From the initial PR: > There ought to be a way to detect that threading support is disabled so that > pessimizations like mutex locks can be left out. From the definition of -mthreads in TFM: " `-mthreads' Support thread-safe exception handling on `Mingw32'. Code that relies on thread-safe exception handling must compile and link all code with the `-mthreads' option. When compiling, `-mthreads' defines `-D_MT'; when linking, it links in a special thread helper library `-lmingwthrd' which cleans up per thread exception handling data. " Having checked, the /only/ effects of -mthreads are to define the preprocessor symbol and add the library to the linker command (i.e., it makes no difference to the code generated by the backend, there is no target flag for it, no target switch, and no reference to it anywhere except in the specs), it is simply the case that cygwin does not implement or support the functionality in question; there is no equivalent cygwin link library. So, given that cygwin does *not* support -mthread and does *not* define _MT, I don't see any reason why #ifdef _MT / #ifndef _MT won't do the exactly correct thing on all platforms. Hence I am closing this 3-year old PR as invalid, just to tidy up Bugzila a little. Sorry for any surprise caused by seeing this ghost of the past coming at you from out of nowhere! cheers, DaveK -- davek at gcc dot gnu dot org changed: What|Removed |Added CC||davek at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9511
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #26 from braingrant at ebestmail dot com 2007-05-02 15:14 --- Created an attachment (id=13495) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13495&action=view) mortgage refinancing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #25 from braingrant at ebestmail dot com 2007-05-02 15:14 --- Created an attachment (id=13494) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13494&action=view) bad credit mortgage -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #24 from braingrant at ebestmail dot com 2007-05-02 15:11 --- Created an attachment (id=13493) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13493&action=view) san francisco hotel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #23 from braingrant at ebestmail dot com 2007-05-02 15:09 --- Created an attachment (id=13492) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13492&action=view) air conditioner -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #22 from braingrant at ebestmail dot com 2007-05-02 15:09 --- Created an attachment (id=13491) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13491&action=view) cheap cigarette -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #21 from braingrant at ebestmail dot com 2007-05-02 15:08 --- Created an attachment (id=13490) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13490&action=view) office furniture -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #20 from braingrant at ebestmail dot com 2007-05-02 15:05 --- Created an attachment (id=13489) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13489&action=view) mlm leads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #19 from braingrant at ebestmail dot com 2007-05-02 15:04 --- Created an attachment (id=13488) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13488&action=view) buy hgh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #18 from braingrant at ebestmail dot com 2007-05-02 15:03 --- Created an attachment (id=13487) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13487&action=view) chanel handbags -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug target/31787] New: bfin: Dreg expected for CLI. Input text was P0.
Building RTEMS for the bfin using gcc-4.2.0-20070430 raises the following
error:
bfin-rtems4.8-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../lib/include
-D__RTEMS_INSIDE__ -Wall -fasm -g -O2 -MT src/librtems_a-eventsurrender.o -MD
-MP -MF src/.deps/librtems_a-eventsurrender.Tpo -c -o
src/librtems_a-eventsurrender.o `test -f 'src/eventsurrender.c' || echo
'../../../../../rtems.orig/cpukit/rtems/'`src/eventsurrender.c
{standard input}: Assembler messages:
{standard input}:31: Error: Dreg expected for CLI. Input text was P0.
{standard input}:83: Error: Dreg expected for STI. Input text was P0.
{standard input}:154: Error: Dreg expected for STI. Input text was P0.
{standard input}:173: Error: Dreg expected for STI. Input text was P0.
make: *** [src/librtems_a-eventsurrender.o] Error 1
Changing the optimization level to -O0 causes the error to vanish.
--
Summary: bfin: Dreg expected for CLI. Input text was P0.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralf_corsepius at rtems dot org
GCC target triplet: bfin-rtems4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #17 from braingrant at ebestmail dot com 2007-05-02 15:01 --- Created an attachment (id=13486) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13486&action=view) ugg boots -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #16 from braingrant at ebestmail dot com 2007-05-02 15:00 --- Created an attachment (id=13485) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13485&action=view) bathroom vanities -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #14 from braingrant at ebestmail dot com 2007-05-02 14:59 --- Created an attachment (id=13483) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13483&action=view) cheap furniture -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #13 from braingrant at ebestmail dot com 2007-05-02 14:58 --- Created an attachment (id=13482) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13482&action=view) bed frames -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #12 from braingrant at ebestmail dot com 2007-05-02 14:57 --- Created an attachment (id=13481) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13481&action=view) corner computer armoire -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-05-02 14:55 --- *** Bug 31785 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||caolanm at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug c++/31785] RFE: Possible to avoid emitting ctor sections for simple constructors of static objects ?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-02 14:55 --- This is not a trivial constructor (or at least what the standard defines as trivial :) ). This is the same problem as PR 4131. *** This bug has been marked as a duplicate of 4131 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|RFE: Possible to avoid |RFE: Possible to avoid |emitting ctor sections for |emitting ctor sections for |trivial constructors of |simple constructors of |static objects ?|static objects ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31785
[Bug ada/28733] GNAT crash while compiling Ada-2005 code
--- Comment #9 from charlet at gcc dot gnu dot org 2007-05-02 14:54 --- Never mind, I could still reproduce it, although the sources need to be updated to conform to latest Ada 2005 rules (some interfaces must be marked limited). Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2006-10-11 21:53:56 |2007-05-02 14:54:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28733
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #11 from braingrant at ebestmail dot com 2007-05-02 14:51 --- Created an attachment (id=13480) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13480&action=view) bowflex -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #10 from braingrant at ebestmail dot com 2007-05-02 14:50 --- Created an attachment (id=13479) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13479&action=view) medifast weight loss -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #9 from braingrant at ebestmail dot com 2007-05-02 14:47 --- Created an attachment (id=13478) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13478&action=view) card credit reward -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #8 from braingrant at ebestmail dot com 2007-05-02 14:40 --- Created an attachment (id=13477) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13477&action=view) subaru wrx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #7 from braingrant at ebestmail dot com 2007-05-02 14:23 --- Created an attachment (id=13476) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13476&action=view) bicycle light -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug ada/21573] 'Valid attribute on enumeration types with holes
--- Comment #7 from charlet at gcc dot gnu dot org 2007-05-02 14:23 --- Runs fine at -O0 and -O2 on i686-linux on trunk -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21573
[Bug c++/13422] `class A' only defines a private destructor and has no friends
--- Comment #6 from braingrant at ebestmail dot com 2007-05-02 14:18 --- Created an attachment (id=13475) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13475&action=view) radiators -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13422
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Comment #36 from ralf_corsepius at rtems dot org 2007-05-02 14:16 --- (In reply to comment #35) > Now, bootstrapping 4.2.0 fails with a similar error Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug target/31786] New: error: unable to find a register to spill in class 'BASE_POINTER_REGS'
bootstrapping avr-rtems* gcc-4.2.0-200704030 fails with:
/builddir/build/BUILD/rtems-4.8-avr-rtems4.8-gcc-4.2.0/build/./gcc/xgcc
-B/builddir/build/BUILD/rtems-4.8-avr-rtems4.8-gcc-4.2.0/build/./gcc/ -nostdinc
-B/builddir/build/BUILD/rtems-4.8-avr-rtems4.8-gcc-4.2.0/build/avr-rtems4.8/newlib/
-isystem
/builddir/build/BUILD/rtems-4.8-avr-rtems4.8-gcc-4.2.0/build/avr-rtems4.8/newlib/targ-include
-isystem
/builddir/build/BUILD/rtems-4.8-avr-rtems4.8-gcc-4.2.0/gcc-4.2.0-20070430/newlib/libc/include
-B/opt/rtems-4.8/avr-rtems4.8/bin/ -B/opt/rtems-4.8/avr-rtems4.8/lib/ -isystem
/opt/rtems-4.8/avr-rtems4.8/include -isystem
/opt/rtems-4.8/avr-rtems4.8/sys-include -DPACKAGE_NAME=\"newlib\"
-DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.15.0\"
-DPACKAGE_STRING=\"newlib\ 1.15.0\" -DPACKAGE_BUGREPORT=\"\" -I.
-I../../../../../../gcc-4.2.0-20070430/newlib/libc/misc -Os
-DPREFER_SIZE_OVER_SPEED -mcall-prologues -DMALLOC_PROVIDED -DEXIT_PROVIDED
-DMISSING_SYSCALL_NAMES -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED
-DHAVE_OPENDIR -DNO_EXEC -DHAVE_FCNTL -fno-builtin -O2 -g -O2
-mmcu=avr25 -c -o lib_a-init.o `test -f 'init.c' || echo
'../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/'`init.c
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c: In function
'__libc_fini_array':
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c:59: error: unable
to find a register to spill in class 'BASE_POINTER_REGS'
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c:59: error: this is
the insn:
(insn 84 55 56 4
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c:56 (set (mem/c:HI
(plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [5 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c:59: confused by
earlier errors, bailing out
--
Summary: error: unable to find a register to spill in class
'BASE_POINTER_REGS'
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralf_corsepius at rtems dot org
GCC target triplet: avr-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Comment #35 from ralf_corsepius at rtems dot org 2007-05-02 14:07
---
Now, bootstrapping 4.2.0 fails with a similar error
/builddir/build/BUILD/rtems-4.8-avr-rtems4.8-gcc-4.2.0/build/./gcc/xgcc
-B/builddir/build/BUILD/rtems-4.8-avr-rtems4.8-gcc-4.2.0/b
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c: In function
'__libc_fini_array':
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c:59: error: unable
to find a register to spill in class 'BASE_POINTER_
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c:59: error: this is
the insn:
(insn 84 55 56 4
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c:56 (set (mem/c:HI
(plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [5 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
../../../../../../gcc-4.2.0-20070430/newlib/libc/misc/init.c:59: confused by
earlier errors, bailing out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug ada/29623] Assert_Failure sinfo.adb:649 in task allocator
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-02 14:02 --- Works fine on trunk. -- charlet 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=29623
[Bug ada/20797] Code gen creating out-of-bounds addresses on legit code
--- Comment #1 from charlet at gcc dot gnu dot org 2007-05-02 13:59 --- I'd suggest verifying with GCC 4.3.0, where the problem is likely fixed. If not, could you please identify which pass is faulty ? Since it works on so many other platforms, I suspect it's a codegen bug rather than an Ada bug. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20797
