[Bug fortran/30512] MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1 maximum values.
--- Comment #8 from burnus at gcc dot gnu dot org 2007-01-29 08:40 --- > Should we commit the combined fix? I do think this > is a bug. So do I, but we also need a test case, I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
[Bug fortran/30626] New: Wrong-code for internal read
Ante-scriptum: This PR might be related to PR30284 (or not). $ cat a.f90 character(len=12) :: date(1) = (/ '200612231200' /) integer :: foo read (date(:)(1:4),'(i4)') foo print *, foo end $ ifort a.f90 && ./a.out 2006 $ gfortran a.f90 && ./a.out 2 gfortran has an incorrect behaviour here, while ifort is doing the right thing (like all other compilers I could test). -- Summary: Wrong-code for internal read Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org BugsThisDependsOn: 30284 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30626
[Bug fortran/30626] Wrong-code for internal read
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 09:07:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30626
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #11 from doerr at kis dot uni-freiburg dot de 2007-01-29 09:43 --- Hi, I still get the same problem after installing the gcc-4.2-20070124 on OpenSUSE 10.2 for amd64 only (configured with --disable-multilib). $prefix/lib64 is in my ld.so.conf as well as in $LD_LIBRARY_PATH. It seems that this bug was not fixed within one year, so is there any possibility to work around it? Greetings, Hans-Peter Doerr -- doerr at kis dot uni-freiburg dot de changed: What|Removed |Added CC||doerr at kis dot uni- ||freiburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #12 from martin at mpa-garching dot mpg dot de 2007-01-29 10:04 --- Well, I just copy libgomp.spec from lib64/ to lib/ by hand after installing. For the long term this not the right thing of course, but as a quick fix it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug fortran/30554] ICE in mio_pointer_ref at module.c:1945
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-29 10:28 --- Subject: Bug 30554 Author: pault Date: Mon Jan 29 10:27:50 2007 New Revision: 121281 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121281 Log: 2007-01-29 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30554 * module.c (read_module): If a symbol is excluded by an ONLY clause, check to see if there is a symtree already loaded. If so, attach the symtree to the pointer_info. 2007-01-29 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30554 * gfortran.dg/used_dummy_types_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_dummy_types_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #15 from bkoz at gcc dot gnu dot org 2007-01-29 10:51 --- Subject: Bug 28125 Author: bkoz Date: Mon Jan 29 10:51:01 2007 New Revision: 121282 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121282 Log: 2007-01-28 Benjamin Kosnik <[EMAIL PROTECTED]> Revert. 2006-12-11 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/28125 * acinclude.m4 (GLIBCXX_CHECK_ICONV_SUPPORT): Remove link test, ie AC_CHECK_LIB for libiconv. Instead, use bits of AM_ICONV. * configure: Regenerate. * scripts/testsuite_flags.in (cxxflags): Add LIBICONV bits. Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_1-branch/libstdc++-v3/configure branches/gcc-4_1-branch/libstdc++-v3/scripts/testsuite_flags.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug c++/28236] wrong "control reaches" warning with enums.
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-29 11:09 --- WONTFIX as decided here: http://gcc.gnu.org/ml/gcc/2007-01/msg01179.html -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
[Bug c++/30627] New: missed optimization, large stack frame, oodles of upfront movl $0
Compiling the attached testcase at O > 0 for an ia32 target, ie /usr/local/gcc-4.3-20070119/bin/g++ -O3 -march=k8 -msse3 -fomit-frame-pointer, i get something like subl$2812, %esp leal1100(%esp), %eax leal2808(%esp), %edx movl$0, 976(%esp) movl$0, 980(%esp) movl$0, 968(%esp) movl$0, 972(%esp) movl$0, 960(%esp) movl$0, 964(%esp) movl$0, 952(%esp) movl$0, 956(%esp) movl$0, 928(%esp) movl$0, 932(%esp) movl$0, 904(%esp) movl$0, 908(%esp) movl$0, 888(%esp) movl$0, 892(%esp) movl$0, 872(%esp) movl$0, 876(%esp) ... for the app::frontend_loop() function. There's 2 problems: a) g++ generates a larger stack frame than other compilers, msvc 8 sp1: 1152 bytes, icc 9.1: 2108 bytes b) long strings of movl $0 get coalesced to the top of the function, that symptom is specific to ia32, it doesn't happen on x86-64 It's not new to 4.3 but with the flashy string op infrastructure one could hope that b) would be taken care of :) -- Summary: missed optimization, large stack frame, oodles of upfront movl $0 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbptbp at gmail dot com GCC host triplet: x86* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30627
[Bug c++/30627] missed optimization, large stack frame, oodles of upfront movl $0
--- Comment #1 from tbptbp at gmail dot com 2007-01-29 12:08 --- Created an attachment (id=12975) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12975&action=view) fat testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30627
[Bug c/30628] New: ICE with __may_alias__ attribute.
[EMAIL PROTECTED] tmp]$ cat may_alias.c typedef unsigned int T1[1]; typedef T1 __attribute__((__may_alias__)) T1A; [EMAIL PROTECTED] tmp]$ ~/try/bin/gcc -c -g may_alias.c -o may_alias.o -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/home/osv/try Thread model: posix gcc version 4.1.1 /home/osv/try/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v may_alias.c -quiet -dumpbase may_alias.c -mtune=pentiumpro -auxbase-strip may_alias.o -g -version -o /tmp/cc7vnJKn.s ignoring nonexistent directory "/home/osv/try/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /home/osv/try/include /home/osv/try/lib/gcc/i686-pc-linux-gnu/4.1.1/include /usr/include End of search list. GNU C version 4.1.1 (i686-pc-linux-gnu) compiled by GNU C version 4.0.2 20051125 (Red Hat 4.0.2-8). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 024b74b82ea166b936dc5fd3b214e11c may_alias.c:2: internal compiler error: in modified_type_die, at dwarf2out.c:8463 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] tmp]$ -- Summary: ICE with __may_alias__ attribute. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: osv at javad 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=30628
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #8 from dir at lanl dot gov 2007-01-29 13:45 --- It hangs on a Intel iMac - [pactech01:~/tests] dir% gfortran -o recursiveio recursiveio.f90 [pactech01:~/tests] dir% recursiveio test 1.00 ^C [pactech01:~/tests] dir% cat recursiveio.f90 external fun real fun real a a = fun() print *, a print *, fun() end real function fun() print *, 'test' fun = 1.0 end [dranta:~] dir% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug c++/29993] typdef declaration of cv-qualified function in class
--- Comment #3 from doug dot gregor at gmail dot com 2007-01-29 13:50 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01828.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29993
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #9 from dominiq at lps dot ens dot fr 2007-01-29 14:13 --- Subject: Re: recursive I/O hangs under OSX 10.3 > It hangs on a Intel iMac Thanks for the answer. So it hangs for the different flavor of OSX, but not for x86_64-unknown-linux-gnu (4.3.0 20061231) and i386-pc-linux-gnu (4.3.0 20070129). What about the other supported OS and architecture? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug target/30406] ICE in LOGICAL(8) functions
--- Comment #25 from dominiq at lps dot ens dot fr 2007-01-29 15:13 --- What is the fate of the patch in comment #22? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
[Bug target/30406] ICE in LOGICAL(8) functions
--- Comment #26 from fxcoudert at gcc dot gnu dot org 2007-01-29 15:30 --- (In reply to comment #25) > What is the fate of the patch in comment #22? I suppose Andrew should submit it for review by the PowerPC maintainers. If he doesn't have time, you could do it (unless he objects): bootstrap and regtest the patch (complete regtest, not only Fortran), post the patch (with ChangeLog entry and a testcase for addition to our testsuite) to gcc-patches, CCing the PowerPC maintainers (Geoff Keating and David Edelsohn), asking for it to be reviewed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-01-10 08:11:39 |2007-01-29 15:30:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
[Bug middle-end/27657] [4.2/4.3 regression] bogus undefined reference error to static var with -g and -O
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-01-29 15:43
---
I'm testing
Index: dwarf2out.c
===
--- dwarf2out.c (revision 121287)
+++ dwarf2out.c (working copy)
@@ -10045,8 +10045,14 @@ reference_to_unused (tree * tp, int * wa
if (DECL_P (*tp) && ! TREE_PUBLIC (*tp) && ! TREE_USED (*tp)
&& ! TREE_ASM_WRITTEN (*tp))
return *tp;
- else
-return NULL_TREE;
+ else if (DECL_P (*tp))
+{
+ struct varpool_node *node = varpool_node (*tp);
+ if (!node->needed)
+ return *tp;
+}
+
+ return NULL_TREE;
}
/* Generate an RTL constant from a decl initializer INIT with decl type TYPE,
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2006-08-27 22:32:58 |2007-01-29 15:43:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug debug/30629] New: [Regression:4.3/4.2] -g causes undefined references
Consider this testcase:
=== Cut ===
static int hacky_auxmaps[2];
static signed int auxmap_used = 0;
static int *auxmap = &hacky_auxmaps[0];
static void
mc_pre_reg_read ( unsigned size)
{
vgPlain_message ("memcheck: auxmaps: %d auxmap entries in use", auxmap_used);
}
=== Cut ===
compiling it with -O2 -g results in an undefined reference to "hacky_auxmaps".
just compiling with -O2 or with -O0 fixes it.
--
Summary: [Regression:4.3/4.2] -g causes undefined references
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
GCC host triplet: i686-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30629
[Bug middle-end/27657] [4.2/4.3 regression] bogus undefined reference error to static var with -g and -O
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-01-29 15:49 --- *** Bug 30629 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mueller at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug debug/30629] [Regression:4.3/4.2] -g causes undefined references
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-29 15:49 --- Dup of PR27657. *** This bug has been marked as a duplicate of 27657 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30629
[Bug c/30313] [4.1/4.2/4.3 Regression] sizeof of expression including bit-field
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-29 16:13 --- We also are 'in_gimple_form', so non_lvalue doesn't do anything on us in non-unit-at-a-time mode. With -funit-at-a-time the testcase is fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30313
[Bug c/30313] [4.1/4.2/4.3 Regression] sizeof of expression including bit-field
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-01-29 16:16 --- I'm testing the following: Index: passes.c === *** passes.c(revision 121287) --- passes.c(working copy) *** execute_one_pass (struct tree_opt_pass * *** 1054,1059 --- 1054,1062 dump_file = NULL; } + /* Reset in_gimple_form to not break non-unit-at-a-time mode. */ + in_gimple_form = false; + return true; } -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-12-28 03:05:44 |2007-01-29 16:16:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30313
[Bug c++/28266] [4.0/4.1/4.2/4.3 regression] ICE on invalid default variable
--- Comment #3 from jason at gcc dot gnu dot org 2007-01-29 16:27 --- Subject: Bug 28266 Author: jason Date: Mon Jan 29 16:27:21 2007 New Revision: 121288 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121288 Log: PR c++/28266 * gimplify.c (gimplify_target_expr): Make sure that the TARGET_EXPR is expanded only once even if an error occurs. Added: trunk/gcc/testsuite/g++.dg/parse/defarg12.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28266
[Bug tree-optimization/30630] New: Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
GCC 4.3 compiler revision 121206 goes into infinitive loop while compiling cpu2k6/perlbench source file regcomp.c at -O2 optimization level on x86_64-redhat-linux. GDB attached to cc1 process, gives the hang point: 0x00711bd8 in solve_graph (graph=0xd37150) at /home/testbot/bootstrap/009454/src/gcc/tree-ssa-structalias.c:1619 1619if (!TEST_BIT (ti->visited, i) && find (i) == i) You can find the minimal reproducer attached. This regression is caused by "Rewrite of portions of points-to solver" patch http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01541.html revision 120931 http://gcc.gnu.org/viewcvs?view=rev&revision=120931 -- Summary: Trunk GCC hangs while compiling cpu2k6/perlbench at -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grigory_zagorodnev at linux dot intel dot com GCC host triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug tree-optimization/30630] Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
--- Comment #1 from grigory_zagorodnev at linux dot intel dot com 2007-01-29 16:47 --- Created an attachment (id=12976) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12976&action=view) Minimal reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug tree-optimization/30631] New: Trunk GCC fails to compile cpu2k6/dealII at -O2
GCC 4.3 compiler revision 121206 gets ICE while compiling cpu2006/447.dealII source file data_out_base.cc at -O2 optimization level on x86_64-redhat-linux. Similar to previously reported cpu2k6/perlbench failure, this regression is caused by "Rewrite of portions of points-to solver" patch http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01541.html (revision 120931). Error log is listed below. data_out_base.cc: In static member function 'static void DataOutBase::write_vtk(const std::vector, std::allocator > >&, const std::vector, std::allocator >, std::allocator, std::allocator > > >&, const DataOutBase::VtkFlags&, std::ostream&) [with int dim = 3, int spacedim = 4]': data_out_base.cc:2949: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'reduc_max_expr' in add_call_clobber_ops, at tree-ssa-operands.c:1780 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: Trunk GCC fails to compile cpu2k6/dealII at -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grigory_zagorodnev at linux dot intel dot com GCC host triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30631
[Bug tree-optimization/30631] Trunk GCC fails to compile cpu2k6/dealII at -O2
--- Comment #1 from grigory_zagorodnev at linux dot intel dot com 2007-01-29 16:51 --- Failing source file contains ~3500 lines of C++ code. That would take a while to get a minimal reproducer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30631
[Bug c/30628] ICE with __may_alias__ attribute.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-29 16:52 --- Dup of PR29436. *** This bug has been marked as a duplicate of 29436 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30628
[Bug debug/29436] [4.0/4.1/4.2/4.3 Regression] ICE in modified_type_die
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-01-29 16:52 --- *** Bug 30628 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||osv at javad dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug tree-optimization/30630] Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-29 16:56 --- Confirmed. We're iterating a lot (gdb) #3 0x00959baa in solve_graph (graph=0x11f58c0) at /space/rguenther/src/svn/trunk/gcc/tree-ssa-structalias.c:2043 2043 compute_topo_order (graph, ti); (gdb) print stats.iterations $1 = 11197125 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 16:56:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #6 from jconner at gcc dot gnu dot org 2007-01-29 16:58 --- Subject: Bug 29683 Author: jconner Date: Mon Jan 29 16:58:04 2007 New Revision: 121289 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121289 Log: 2007-01-29 Josh Conner <[EMAIL PROTECTED]> PR middle-end/29683 * calls.c (compute_argument_addresses): Set stack and stack_slot for partial args, too. (store_one_arg): Use locate.size.constant for the size when generating a save_area. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/calls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug tree-optimization/30631] Trunk GCC fails to compile cpu2k6/dealII at -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-29 16:59 --- Can you nevertheless attach preprocessed source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30631
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #7 from jconner at gcc dot gnu dot org 2007-01-29 16:59 --- Subject: Bug 29683 Author: jconner Date: Mon Jan 29 16:59:35 2007 New Revision: 121290 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121290 Log: 2007-01-29 Josh Conner <[EMAIL PROTECTED]> PR middle-end/29683 * gcc.dg/pr29683.c: New. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr29683.c Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #8 from jconner at gcc dot gnu dot org 2007-01-29 17:08 --- Subject: Bug 29683 Author: jconner Date: Mon Jan 29 17:08:31 2007 New Revision: 121291 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121291 Log: 2007-01-29 Josh Conner <[EMAIL PROTECTED]> PR middle-end/29683 * calls.c (compute_argument_addresses): Set stack and stack_slot for partial args, too. (store_one_arg): Use locate.size.constant for the size when generating a save_area. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/calls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #9 from jconner at gcc dot gnu dot org 2007-01-29 17:09 --- Subject: Bug 29683 Author: jconner Date: Mon Jan 29 17:09:38 2007 New Revision: 121292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121292 Log: 2007-01-29 Josh Conner <[EMAIL PROTECTED]> PR middle-end/29683 * gcc.dg/pr29683.c: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr29683.c Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #10 from jconner at apple dot com 2007-01-29 17:11 --- Same fix that was applied to mainline resolved the issue in 4.1 and 4.2 branches. Checked in to both of those branches. -- jconner at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug tree-optimization/30630] Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-01-29 17:25 --- Subject: Bug 30630 Author: dberlin Date: Mon Jan 29 17:25:04 2007 New Revision: 121295 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121295 Log: 2007-01-29 Daniel Berlin <[EMAIL PROTECTED]> PR tree-optimization/30630 * tree-ssa-structalias.c (do_complex_constraint): Mark correct variable as changed. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20070129.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug tree-optimization/30630] Trunk GCC hangs while compiling cpu2k6/perlbench at -O2
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-01-29 17:25 --- Fixed -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30630
[Bug target/30406] ICE in LOGICAL(8) functions
--- Comment #27 from pinskia at gcc dot gnu dot org 2007-01-29 17:57 --- (In reply to comment #26) > (In reply to comment #25) > > What is the fate of the patch in comment #22? > > I suppose Andrew should submit it for review by the PowerPC maintainers. I will try to regest test it later today on powerpc-linux-gnu (on a PS3 really). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
[Bug tree-optimization/30559] [4.3 Regression] compiler loops forever with flag -O3
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-29 18:01 --- Can you try after: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121295 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-29 18:08 --- (In reply to comment #9) > I will submit two patches. The first one will remove the function. Then, I > have > to regtest the second one: perhaps we find another unused function! Another one: genautomata.c: static int longest_path_length (state_t state) Should also be removed completely? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #11 from stevenb dot gcc at gmail dot com 2007-01-29 18:22 --- Subject: Re: -Wunused doesn't warn about static function only called by itself. If it is unused, don't hesitate to remove it. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug tree-optimization/30631] Trunk GCC fails to compile cpu2k6/dealII at -O2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30631
[Bug libgcj/30570] Word "DEBUG" used as a variable in VMAccessController.java breaks build
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-29 19:03 --- Hmm, we use "DEBUG" in java-assert.h. That is a bit unfriendly. Anyway if this define is coming from a system header, the traditional fix is to #undef it somewhere. Typically this is done in the platform flavor's header file, e.g., libjava/include/win32.h. We already have "#undef STRICT" there... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30570
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
-- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 19:03:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-29 19:07 --- Created an attachment (id=12977) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12977&action=view) proposed patch Please try this patch. Now we look for magic_t and, if not found, we disable the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug java/30607] gcj -I x -C doesn't include x as source dir search patch
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-29 19:16 --- I didn't realize that -I's argument could be separate, but now I see this in c.opt: I C ObjC C++ ObjC++ Joined Separate -I Add to the end of the main include path -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 19:16:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30607
[Bug java/30607] gcj -I x -C doesn't include x as source dir search patch
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-29 19:34 --- Tetsing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-29 19:16:32 |2007-01-29 19:34:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30607
[Bug java/30035] libjava cannot be built when objdir != srcdir
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30035
[Bug libgcj/30071] make install fails for libjava
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-29 20:00 --- We can't modify the Makefile.in, since those changes will be lost the next time someone runs automake. Could you try adding this to Makefile.am and then re-running automake? (If you can't re-run automake, let me know and I will send you a patch.) install-binPROGRAMS: install-toolexeclibLTLIBRARIES This is not really supported by automake, but really this is working around an automake bug anyhow. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 20:00:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30071
[Bug java/30292] ICE on compiling .java by gcc(1)
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-29 20:03 --- I thought I'd point out that you'll have to submit this patch the usual way; patches generally aren't reviewed in bugzilla. Also since this is a driver patch it probably won't get attention by the appropriate people, since it is filed as a java bug. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 20:03:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30292
[Bug libgcj/30632] New: libgcj failed to build for Linux/ia64
Libgcj in revision 121297 failed to build for Linux/ia64: /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc: In function 'jvmtiError _Jv_JVMTI_SuspendThread(jvmtiEnv*, java::lang::Object*)': /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc:159: error: 'class java::lang::Object' has no member named 'isAlive' /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc:161: error: invalid conversion from 'java::lang::Object*' to 'java::lang::Thread*' /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc:161: error: initializing argument 1 of '_Jv_Thread_t* _Jv_ThreadGetData(java::lang::Thread*)' /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc: In function 'jvmtiError _Jv_JVMTI_ResumeThread(jvmtiEnv*, java::lang::Object*)': /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc:173: error: 'class java::lang::Object' has no member named 'isAlive' /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc:175: error: invalid conversion from 'java::lang::Object*' to 'java::lang::Thread*' /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc:175: error: initializing argument 1 of '_Jv_Thread_t* _Jv_ThreadGetData(java::lang::Thread*)' /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc: In function 'jvmtiError _Jv_JVMTI_InterruptThread(jvmtiEnv*, java::lang::Object*)': /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc:191: error: 'class java::lang::Object' has no member named 'isAlive' /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc:192: error: 'class java::lang::Object' has no member named 'interrupt' /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc: In function 'jvmtiError _Jv_JVMTI_SetEventNotificationMode(jvmtiEnv*, jvmtiEventMode, jvmtiEvent, java::lang::Object*, ...)': /net/gnu-13/export/gnu/src/gcc/gcc/libjava/jvmti.cc:1171: error: 'class java::lang::Object' has no member named 'isAlive' make[4]: *** [jvmti.lo] Error 1 make[4]: Leaving directory `/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava' Revision 121290 is OK: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg01092.html This patch http://gcc.gnu.org/ml/java-patches/2007-q1/msg00217.html may be the cause. -- Summary: libgcj failed to build for Linux/ia64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30632
[Bug libgcj/30632] libgcj failed to build for Linux/ia64
--- Comment #1 from hjl at lucon dot org 2007-01-29 20:08 --- Oops. I meant to say this patch http://gcc.gnu.org/ml/java-patches/2007-q1/msg00237.html might be the cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30632
[Bug java/30466] gcj crashes when using invalid options
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-29 20:11 --- Note that the '-Manything' argument is superfluous, the bug occurs without it: opsy. gcj -MT anything HelloWorld.java jc1: ../../trunk/gcc/java/jcf-depend.c:138: jcf_dependency_write: Assertion `dependencies' failed. /tmp/ccGS8k5Z.jar:0: internal compiler error: Aborted -M handling got pretty much nuked by the merge. But, apparently, nuked in an unfriendly way :( -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-29 20:11:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30466
[Bug libgcj/30632] libgcj failed to build for Linux/ia64
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-29 20:16 --- This is very weird. I don't see how it can happen... The definition is: static jvmtiError JNICALL _Jv_JVMTI_SuspendThread (MAYBE_UNUSED jvmtiEnv *env, jthread thread) and afaics jthread is defined in include/jvmti_md.h: typedef java::lang::Thread *jthread; Hmm... perhaps this compilation is picking up some *other* jvmti.h? One that defines jthread as 'jobject'? Perhaps -E or the .d file would help here. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30632
[Bug target/30406] ICE in LOGICAL(8) functions
--- Comment #28 from dominiq at lps dot ens dot fr 2007-01-29 20:47 ---
Subject: Re: ICE in LOGICAL(8) functions
> I suppose Andrew should submit it for review by the PowerPC maintainers.
> If he doesn't have time, you could do it (unless he objects):
Never do today what someone else can do tomorrow?
> bootstrap and regtest the patch (complete regtest, not only Fortran),
Applied to gcc-4.3-20070126 and built through fink. I only learnt two
weeks ago how to run "test_installed", so I am very new in the regtest
game. The summaries follow:
=== gcc Summary ===
# of expected passes43171
# of unexpected failures39
# of unexpected successes 3
# of expected failures 109
# of unresolved testcases 2
# of untested testcases 28
# of unsupported tests 460
/sw/lib/gcc4//bin/gcc version 4.3.0 20070126 (experimental)
WARNING: Couldn't find the global config file.
Test Run By dominiq on Mon Jan 29 19:52:53 2007
Native configuration is powerpc-apple-darwin7.9.0
=== g++ Summary ===
# of expected passes12135
# of unexpected failures1427
# of unexpected successes 3
# of expected failures 80
# of unresolved testcases 90
# of unsupported tests 131
/sw/lib/gcc4//bin/g++ version 4.3.0 20070126 (experimental)
WARNING: Couldn't find the global config file.
Test Run By dominiq on Mon Jan 29 20:18:55 2007
Native configuration is powerpc-apple-darwin7.9.0
Here the results are probably due to a hack I am applying to avoid
spurious warning at link time. I have also several messages such as:
/sw/lib/odcctools/bin/ld: warning can't open dynamic library:
/libgcc_s.1.dylib referenced from:
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin7/4.3.0/../../../libstdc++.dylib
(checking for undefined symbols may be affected) (No such file or directory,
errno = 2)
The lib should be /sw/lib/gcc4/lib/libgcc_s.1.dylib, I'ld have to
investigate the origin of the problem
=== gfortran Summary ===
# of expected passes15904
# of unexpected failures24
# of expected failures 7
# of unsupported tests 57
/sw/lib/gcc4//bin/gfortran version 4.3.0 20070126 (experimental)
WARNING: Couldn't find the global config file.
Test Run By dominiq on Mon Jan 29 21:12:00 2007
Native configuration is powerpc-apple-darwin7.9.0
Note that I moved away the files
gcc/testsuite/gfortran.dg/actual_array_interface_1.f90
(which is empty) and
gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90
whose executable is hanging under OSX (see my post:
http://gcc.gnu.org/ml/fortran/2006-11/msg00394.html)
Note also that beside the files large_real_kind_2.F90 and
large_real_kind_form_io_2.f90, I have also some failures such as:
WARNING: gfortran.dg/iso_fortran_env_3.f90 -O0 compilation failed to produce
executable
I do not see when compiling the file directly (will all the failing
options I have tested). The errors are:
use iso_fortran_env, foo => numeric_storage_size
1
Error: Symbol 'numeric_storage_size' referenced at (1) not found in module
'iso_fortran_env'
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/gfortran.dg/iso_fortran_env_3.f90:18.29:
use iso_fortran_env, only : numeric_storage_size, character_storage_size
1
Error: Symbol 'numeric_storage_size' referenced at (1) not found in module
'iso_fortran_env'
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/gfortran.dg/iso_fortran_env_3.f90:18.51:
use iso_fortran_env, only : numeric_storage_size, character_storage_size
1
Error: Symbol 'character_storage_size' referenced at (1) not found in module
'iso_fortran_env'
compiler exited with status 1
=== objc Summary ===
# of expected passes2976
# of unsupported tests 1
/sw/lib/gcc4//bin/gcc version 4.3.0 20070126 (experimental)
Note that I have several errors such as:
Running
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp
...
ERROR: tcl error sourcing
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp.
ERROR: can't read "HOSTCC": no such variable
while executing
"remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd""
invoked from within
"set status [remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd"]"
(file
"/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp"
line 40)
invoked from within
"source
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/Users/dominiq/test/gcc-4.3-20070126/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
> post the patch
--- gcc-4.3-20070126/gcc/config/rs6000/rs6000.c Thu Jan 25 21:32:06 2007
+++ gcc-4.3-20070127/gcc/config/rs6000/rs6000.c S
[Bug libgcj/30632] libgcj failed to build for Linux/ia64
--- Comment #3 from hjl at lucon dot org 2007-01-29 21:00 --- I do have an older gcc 4.3 installed and I am doing "make -j8" on an ia64 machine with 16 pocessors. Is libjava parallel build safe? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30632
[Bug c++/30633] New: Weird uninit in Boost `add_edge'
Ran across this while using the Boost graph package. Test program:
--
#include
#include
namespace boost {
enum vertex_subgraph_t { vertex_subgraph };
BOOST_INSTALL_PROPERTY(vertex, subgraph);
enum vertex_order_t { vertex_order };
BOOST_INSTALL_PROPERTY(vertex, order);
enum edge_back_t { edge_back };
BOOST_INSTALL_PROPERTY(edge, back);
};
typedef boost::property > > > VertexProperty;
typedef boost::property EdgeProperties;
typedef boost::adjacency_list< boost::vecS, boost::vecS, boost::bidirectionalS,
VertexProperty, EdgeProperties > FlowLayoutGraph;
typedef boost::graph_traits< FlowLayoutGraph >::vertex_descriptor
vertex_descriptor;
void break_gcc(FlowLayoutGraph& m_graph, vertex_descriptor v1,
vertex_descriptor v2)
{
add_edge(v1, v2, m_graph);
}
Obtain and unpack Boost 1.33.1. Compile the above with a command like:
g++ -c -I/path/to/boost_1_33_1 -O -Wuninitialized filename.cpp
You should see a message complaining that `p$m_value' is used uninitialized.
(This is, as you probably already realize, a name generated internally by g++;
there is no such variable in the source.)
--
Summary: Weird uninit in Boost `add_edge'
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Scott at coral8 dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30633
[Bug java/30607] gcj -I x -C doesn't include x as source dir search patch
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-29 21:30 --- Subject: Bug 30607 Author: tromey Date: Mon Jan 29 21:30:10 2007 New Revision: 121311 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121311 Log: PR java/30607: * jvspec.c (lang_specific_driver): Handle separate -I argument. * lang.opt (-I): Add 'Separate'. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/jvspec.c trunk/gcc/java/lang.opt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30607
[Bug java/30607] gcj -I x -C doesn't include x as source dir search patch
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-29 21:38 --- Subject: Bug 30607 Author: tromey Date: Mon Jan 29 21:38:06 2007 New Revision: 121312 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121312 Log: PR java/30607: * jvspec.c (lang_specific_driver): Handle separate -I argument. * lang.opt (-I): Add 'Separate'. Modified: branches/redhat/gcc-4_1-branch-java-merge-20070117/gcc/java/ChangeLog branches/redhat/gcc-4_1-branch-java-merge-20070117/gcc/java/jvspec.c branches/redhat/gcc-4_1-branch-java-merge-20070117/gcc/java/lang.opt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30607
[Bug java/30607] gcj -I x -C doesn't include x as source dir search patch
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-29 21:39 --- Fix checked in. -- tromey 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=30607
[Bug libgcj/30550] Missing dependencies for ecjx target
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30550
[Bug fortran/30626] Wrong-code for internal read
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-29 21:55
---
What's funny is that we create the temporary well (see original dump):
static char date[1][1:12] = {"200612231200"};
{
char A.2[1][1:4];
struct array1_unknown atmp.1;
atmp.1.dim[0].stride = 1;
atmp.1.dim[0].lbound = 0;
atmp.1.dim[0].ubound = 0;
atmp.1.data = (void *) &A.2;
atmp.1.offset = 0;
And we
But then we don't translate the assignment well:
{
int4 S.3;
S.3 = 0;
while (1)
{
if (S.3 > 0) goto L.1;
(*(char[0:][1:4] *) atmp.1.data)[S.3] = date[NON_LVALUE_EXPR
][1]{lb: 1 sz: 1};
S.3 = S.3 + 1;
}
L.1:;
}
The above should be date[1][S.3] instead of date[S.3][1], and the S.3 loop
should have 4 elements.
PS: Slightly modified testcase that ICEs on i686-linux:
$ cat a.f90
character(len=12) :: date(1) = (/ '200612231200' /)
integer :: foo
read (date(:)(1:12),'(i4)') foo
print *, foo
end
$ ./bin/gfortran -static a.f90 -fdump-tree-original
a.f90: In function MAIN__:
a.f90:4: internal compiler error: in operand_subword_force, at emit-rtl.c:1352
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30626
[Bug c++/29948] G++ OOM's when compiling kmail
--- Comment #3 from n dot escuder at intra-links dot com 2007-01-29 21:58 --- I have the same problems too on an x86_64-unknown-linux-gnu. No distrib it's build from stratch. Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.1.1/configure --prefix=/opt/gcc --enable-static --enable-shared --enable-threads --with-slibdir=/lib --enable-__cxa_atexit --enable-clocale=gnu -enable-languages=c,c++ --disable-multilib Thread model: posix gcc version 4.1.2 20070129 (prerelease) g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../libkmime -I../libkpgp -I../libkdenetwork -I../libkdepim -I../libkpimidentities -I../libemailfunctions -I../libksieve -I../mimelib -I../certmanager/lib -I../certmanager/lib/ui -I../indexlib -I.. -I../libkdenetwork/libgpgme-copy/gpgme -I../libkdenetwork/libgpg-error-copy -I../libkdenetwork/libgpg-error-copy -I../libkdepim -I/opt/kde/include -I/usr/lib/qt-3.3.7//include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT libkmailprivate_la.all_cpp.lo -MD -MP -MF ".deps/libkmailprivate_la.all_cpp.Tpo" -c -o libkmailprivate_la.all_cpp.lo libkmailprivate_la.all_cpp.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29948
[Bug libfortran/30533] minval, maxval missing for kind=1 and kind=2
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-01-29 22:42 --- For maxval, the usual method of converting the arguments to default integer kind will have an "interesting" side effect with an all-false mask: The value will be a conversion of the default integer minimum value (soon to be 0x80 after the fix for PR 30512 goes in) to kind=1 or kind=2. Definitely not recommended (this will probably be 0x00 or 0x)l The best solution is to generate new maxval_i[12].c files, which will be better for performance anyway. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-23 13:26:59 |2007-01-29 22:42:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30533
[Bug libgomp/30540] Document default value of implementation-dependent OpenMP settings
--- Comment #3 from patchapp at dberlin dot org 2007-01-29 22:55 --- Subject: Bug number PR30540 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02413.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30540
[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
-- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-30 00:05:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30600
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
--- Comment #18 from pcarlini at suse dot de 2007-01-30 00:34 --- Implementing the really trivial solution of providing what() members returning "std::bad_alloc", "std::bad_cast", "std::bad_typeid", and "std::bad_exception". -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-01-30 00:54 --- (In reply to comment #18) > Implementing the really trivial solution of providing what() members returning > "std::bad_alloc", "std::bad_cast", "std::bad_typeid", and > "std::bad_exception". I don't think that is the correct solution as if you subclass these functions, you get the incorrect result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
--- Comment #20 from pcarlini at suse dot de 2007-01-30 00:58 --- (In reply to comment #19) > I don't think that is the correct solution as if you subclass these functions, > you get the incorrect result. What do you mean by "incorrect"?!? If you subclass, either you provide your own what(), or you get the what() provided by the base class, which is implementation defined and, very reasonably, "std::bad_cast" for class bad_cast, and so on... -- pcarlini at suse dot de changed: What|Removed |Added CC||gdr at integrable-solutions ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
[Bug target/30634] New: FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
Executing on host: /home/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/home/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/xxx/gnu/gcc/gcc/gcc/testsuit
e/gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 -w -O1
-L/home
/gnu/gcc/objdir/hppa64-hp-hpux11.00/./libgfortran/.libs
-L/home/gnu/gcc/objdir/h
ppa64-hp-hpux11.00/./libgfortran/.libs
-L/home/gnu/gcc/objdir/hppa64-hp-hpux11.0
0/./libiberty -lm -o
/xxx/gnu/gcc/objdir/gcc/testsuite/gfortran/intrinsic_set
_exponent.x(timeout = 300)
/xxx/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_set_ex
ponent.f90: In function 'test_real8':
/xxx/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_set_ex
ponent.f90:86: error: unrecognizable insn:
(insn 239 84 87 11 (set (reg:DF 32 %fr4 [ equiv.1 ])
(mem/u/c/i:DF (symbol_ref/u:DI ("*L$C0007") [flags 0x2]) [0 S8 A64]))
-1
(nil)
(nil))
/xxx/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_set_ex
ponent.f90:86: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
/xxx/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_set_ex
ponent.f90: In function 'test_real8':
/xxx/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_set_ex
ponent.f90:86: error: unrecognizable insn:
(insn 239 84 87 11 (set (reg:DF 32 %fr4 [ equiv.1 ])
(mem/u/c/i:DF (symbol_ref/u:DI ("*L$C0007") [flags 0x2]) [0 S8 A64]))
-1
(nil)
(nil))
/xxx/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_set_ex
ponent.f90:86: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90, -O1
(intern
al compiler error)
--
Summary: FAIL: gfortran.fortran-
torture/execute/intrinsic_set_exponent.f90
Product: gcc
Version: 4.1.2
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: hppa64-hp-hpux11.11
GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30634
[Bug target/30634] FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
--- Comment #1 from danglin at gcc dot gnu dot org 2007-01-30 01:16 --- Maybe I'll finally get the details right: Target: hppa64-hp-hpux11.00 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-4.2.0 --host=hppa64-hp-hpux11.00 --disable-nls --with-gmp=/opt/gnu64/gcc/gcc-4.2.0 Thread model: posix gcc version 4.2.0 20070127 (prerelease) -- danglin at gcc dot gnu dot org changed: What|Removed |Added Version|4.1.2 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30634
[Bug target/30634] FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
--- Comment #2 from danglin at gcc dot gnu dot org 2007-01-30 01:20 --- Test didn't fail at revision 121050. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30634
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
--- Comment #21 from gdr at cs dot tamu dot edu 2007-01-30 01:30 --- Subject: Re: std::bad_alloc::what() does not explain what happened "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | What do you mean by "incorrect"?!? If you subclass, either you | provide your own what(), or you get the what() provided by the base | class, which is implementation defined and, very reasonably, | "std::bad_cast" for class bad_cast, and so on... Paolo is technically right: what() is a virtual member function; so one should not derive from those classes and except that what() returned something they did not define or we did not promise. I suspect Andrew Pinski's point might be that what() could return a string that represents the name of the most derived type of the exception. But, nothing so far forces to do that. A reasonable definition is to what Paolo suggest, with clear documentation (that mentions this). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
[Bug java/5178] Method call on qualified static field doesn't initialize its class
--- Comment #2 from daney at gcc dot gnu dot org 2007-01-30 01:33 --- The testcase no longer fails as of 4.3.0 -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5178
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
--- Comment #22 from pcarlini at suse dot de 2007-01-30 01:42 --- (In reply to comment #21) > I suspect Andrew Pinski's point might be that what() could return a > string that represents the name of the most derived type of the > exception. But, nothing so far forces to do that. A reasonable > definition is to what Paolo suggest, with clear documentation (that > mentions this). Agreed. Gaby, do you have any strong opinion about std::exception itself? In my current patch draft I'm leaving it alone, but in principle we could change also its what() to return "std::exception" instead of typeid(*this).name(). In other terms, I'm not sure whether your Comment #13 contrary to the mangled typeid applies also to the base std::exception... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
[Bug java/20312] No warning on bad method
--- Comment #7 from daney at gcc dot gnu dot org 2007-01-30 01:53 --- In 4.3.0 this is correctly flagged as an error. With the testcase in comment #1 we get: $ gcj -o t --main=t t.java t.java:3: error: Exception IOException is not compatible with throws clause in Object.toString() public String toString() throws java.io.IOException ^^ 1 problem (1 error) -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20312
[Bug java/5411] gcjh -stubs creates stubs for classes which have no native methods
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-30 02:05 --- The new gjavah does not have this bug. -- tromey 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=5411
[Bug java/5519] add some dummy checking to compilation phase
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-30 02:06 --- ecj has a ton of warning settings, which are now available via gcj. -- tromey 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=5519
[Bug java/11298] nl_langinfo (CODESET) handling
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-30 02:08 --- We removed the lexer in 4.3 and so this bug has gone away. -- tromey 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=11298
[Bug java/14372] MIRANDA bug in java.net.URLConnection
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-30 02:11 --- We may have fixe this earlier; I'm not sure. In any case I think miranda problems were eliminated by removing the gcj .java front end. -- tromey 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=14372
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
--- Comment #23 from gdr at cs dot tamu dot edu 2007-01-30 02:11 --- Subject: Re: std::bad_alloc::what() does not explain what happened "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | --- Comment #22 from pcarlini at suse dot de 2007-01-30 01:42 --- | (In reply to comment #21) | > I suspect Andrew Pinski's point might be that what() could return a | > string that represents the name of the most derived type of the | > exception. But, nothing so far forces to do that. A reasonable | > definition is to what Paolo suggest, with clear documentation (that | > mentions this). | | Agreed. Gaby, do you have any strong opinion about std::exception | itself? In my current patch draft I'm leaving it alone, but in | principle we could change also its what() to return "std::exception" | instead of typeid(*this).name(). >From consistency point of view I would say that the change should also be done for std::exception. However, the use of typeid is very convenient in the sense that we have to defined what() only once. Now, if we change that definition in std::exception, it means that we should revisit all other exception classes, such as std::runtime_error, etc. I have no strong opinion. Probably just leave it as is, and document the choices we face so that people see the rationale behind the implementations. Thanks, -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
[Bug java/30035] libjava cannot be built when objdir != srcdir
--- Comment #4 from liulk at types dot bu dot edu 2007-01-30 02:11 ---
(In reply to comment #3)
> I always build GCC with a separate objdir, and I don't see this problem.
Make sure you're building java, so --enable-languages contains at least the
'java' target or 'all'. In the case of 'all', the only way to be sure is of
course to specify 'java' explicitly. You should check that configure gives you
the following line, and 'java' is one of the languages to be built:
The following languages will be built: c,c++,fortran,java,objc
Obviously, language targets such as c, c++, fortran, ada, obj-c, etc. don't
make use of libjava. If you're not building java, then libjava is not going to
be built, and the build process would succeed fine. I can build all the other
language targets just fine. I just can't build java because of libjava build
error.
> Furthermore my 4.1 tree has a copy of config.{guess,sub} in libjava/libltdl.
> I believe these are used by the libltdl build.
I see these files too, but they're not being referenced by libjava/Makefile.am,
which means the build system doesn't think libltdl exists. Furthermore,
libjava/libltdl/config.sub assumes it will find ../../config.sub, which is not
the case when srcdir != objdir.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30035
[Bug java/15411] CNI: gcjh not aware of "miranda" methods
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-30 02:11 --- The gjavah in 4.3 does not have this bug. -- tromey 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=15411
[Bug java/16843] gcjh generated headers don't define final constants
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-30 02:16 --- Hmm, I thought this was fixed in gjavah, but apparently it is not emitting the #defines either. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Last reconfirmed|2005-05-11 01:06:19 |2007-01-30 02:16:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16843
[Bug java/14712] gcj - ICE in final_scan_insn, at final.c:2247
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-30 02:17 --- Fixed by the gcj-eclipse merge. -- tromey 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=14712
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
--- Comment #24 from pcarlini at suse dot de 2007-01-30 02:21 --- (In reply to comment #23) > From consistency point of view I would say that the change should also > be done for std::exception. Right. > However, the use of typeid is very convenient in the sense that we > have to defined what() only once. Now, if we change that definition > in std::exception, it means that we should revisit all other exception > classes, such as std::runtime_error, etc. I see, but I don't think we have to do much, because the other exception classes, provided in , per the standard requirements are already overriding what() to return _M_msg.c_str(). Thus, I'm coming to the conclusion that we should consistently change std::exception too and be done with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
[Bug java/20597] [meta-bug] missing Java 1.4 support
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-30 02:37 --- No more dependencies. -- tromey 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=20597
[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-30 02:47 --- Subject: Bug 30600 Author: tromey Date: Tue Jan 30 02:46:54 2007 New Revision: 121329 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121329 Log: 2007-01-29 Kaloian Doganov <[EMAIL PROTECTED]> PR libgcj/30600: * gnu/gcj/convert/BytesToCharsetAdaptor.java (read): Fix call to 'limit'. Modified: trunk/libjava/ChangeLog trunk/libjava/classpath/lib/gnu/gcj/convert/BytesToCharsetAdaptor.class trunk/libjava/gnu/gcj/convert/BytesToCharsetAdaptor.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30600
[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-30 02:48 --- Subject: Bug 30600 Author: tromey Date: Tue Jan 30 02:48:26 2007 New Revision: 121330 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121330 Log: 2007-01-29 Kaloian Doganov <[EMAIL PROTECTED]> PR libgcj/30600: * gnu/gcj/convert/BytesToCharsetAdaptor.java (read): Fix call to 'limit'. Modified: branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/ChangeLog branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/gnu/gcj/convert/BytesToCharsetAdaptor.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30600
[Bug target/30634] FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
--- Comment #3 from kargl at gcc dot gnu dot org 2007-01-30 02:53 --- A scan of libgfortran/ChangeLog and gcc/fortran/ChangeLog does not reveal anything that would cause this failure. Can you identify the exact commit that causes the problem? Perhaps, something got mismerged from trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30634
[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-30 03:06 --- I put this into 4.2 and trunk. Thanks! -- tromey 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=30600
[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
--- Comment #7 from tromey at gcc dot gnu dot org 2007-01-30 03:08 --- Subject: Bug 30600 Author: tromey Date: Tue Jan 30 03:08:19 2007 New Revision: 121331 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121331 Log: 2007-01-29 Kaloian Doganov <[EMAIL PROTECTED]> PR libgcj/30600: * gnu/gcj/convert/BytesToCharsetAdaptor.java (read): Fix call to 'limit'. Modified: branches/gcc-4_2-branch/libjava/ChangeLog branches/gcc-4_2-branch/libjava/gnu/gcj/convert/BytesToCharsetAdaptor.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30600
[Bug bootstrap/30635] New: --enable-stage1-langauges configure option is not documented.
This configure option should (I would think) be documented in gccinstall.texi. It isn't. The original patch (http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00614.html) does not contain any documentation. -- Summary: --enable-stage1-langauges configure option is not documented. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30635
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
--- Comment #25 from gdr at cs dot tamu dot edu 2007-01-30 03:53 --- Subject: Re: std::bad_alloc::what() does not explain what happened "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | > However, the use of typeid is very convenient in the sense that we | > have to defined what() only once. Now, if we change that definition | > in std::exception, it means that we should revisit all other exception | > classes, such as std::runtime_error, etc. | | I see, but I don't think we have to do much, because the other exception | classes, provided in , per the standard requirements are already | overriding what() to return _M_msg.c_str(). Thus, I'm coming to the conclusion | that we should consistently change std::exception too and be done with it. You're right. I agree with your analysis. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
[Bug c/30636] New: incorrect array bounds warning on multi-dimensional arrays
It seems that the code is unaware that emergency_buffer is a multidimensional array and so prohibits arithmetic like base+sizeof (emergency_buffer) as exceeding the array bounds. Dirk wrote in private mail: "This seems to be caused by pass 028t.ccp1 because during vrp1 the code looks like: :; if (ptr_3 < &emergency_buffer[0][2048]) goto ; else goto ; which is what it is warning about." -- Summary: incorrect array bounds warning on multi-dimensional arrays Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bje at gcc dot gnu dot org GCC host triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
[Bug c/30636] incorrect array bounds warning on multi-dimensional arrays
--- Comment #1 from bje at gcc dot gnu dot org 2007-01-30 04:01 --- Created an attachment (id=12978) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12978&action=view) Reduced test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
[Bug c/30636] incorrect array bounds warning on multi-dimensional arrays
-- bje at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
[Bug middle-end/30636] [4.3 Regression] incorrect array bounds warning on multi-dimensional arrays
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end GCC host triplet|powerpc-linux | GCC target triplet||powerpc-linux Keywords||diagnostic Priority|P2 |P3 Summary|incorrect array bounds |[4.3 Regression] incorrect |warning on multi-dimensional|array bounds warning on |arrays |multi-dimensional arrays Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
