[Bug libgomp/36469] bootstrap broken on HPUX PA
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:27 --- Subject: Bug 36469 Author: jakub Date: Wed Jun 11 06:27:04 2008 New Revision: 136650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136650 Log: PR libgomp/36469 * configure.ac: Add AC_CHECK_FUNCS (strtoull). * configure: Regenerated. * config.h.in: Regenerated. * env.c (strtoull): Define to strtoul if HAVE_STRTOULL is not defined. Modified: trunk/libgomp/ChangeLog trunk/libgomp/config.h.in trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/env.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36469
[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-11 06:31 --- Subject: Bug 36408 Author: jakub Date: Wed Jun 11 06:30:55 2008 New Revision: 136651 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136651 Log: PR c++/36408 * semantics.c (stmt_expr_value_expr): Don't crash on empty STATEMENT_LIST. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug libgomp/36208] Boolean type discrepancy between gfortran and libgomp
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:44 --- This ought to be fixed on the trunk - BT_BOOL is the C _Bool type even in Fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36208
[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-11 06:48 --- Subject: Bug 36408 Author: jakub Date: Wed Jun 11 06:47:36 2008 New Revision: 136652 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136652 Log: PR c++/36408 * semantics.c (stmt_expr_value_expr): Don't crash on empty STATEMENT_LIST. Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/semantics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug libgomp/35881] OMP wrong results for omp_get_max_threads
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-11 06:48 --- Fixed on the trunk as part of the OpenMP 3.0 support. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35881
[Bug libgomp/35644] omp_set_num_threads not working?
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:53 --- That's correct actually. omp_set_num_threads sets the NTHREADS_VAR ICV, i.e. something that will be used to determine the number of threads of the next #pragma omp parallel. omp_get_num_threads returns the number of threads in the current team, as you call it in sequential code, that has to be always 1. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35644
[Bug libgomp/36471] omp_get_ancestor_thread_num_8 has no implicit type.
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 07:07 --- Subject: Bug 36471 Author: jakub Date: Wed Jun 11 07:06:14 2008 New Revision: 136654 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136654 Log: PR libgomp/36471 * omp_lib.f90.in (omp_get_ancestor_thread_num_8, omp_get_team_size_8): Fix pastos. Modified: trunk/libgomp/ChangeLog trunk/libgomp/omp_lib.f90.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36471
[Bug libgomp/36471] omp_get_ancestor_thread_num_8 has no implicit type.
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-11 07:12 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36471
[Bug fortran/36495] New: libgfortran should be build with FCFLAGS -fimplicit-none
As PR 36471 shows, building libgfortran's Fortran parts with -fimplicit-none can help detecting programming errors in the Fortran written parts of libgfortran. I suggest to use such a patch: Index: configure.ac === --- configure.ac(Revision 136654) +++ configure.ac(Arbeitskopie) @@ -123,7 +123,7 @@ m4_rename([real_PRECIOUS],[_AC_ARG_VAR_P # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC. if test x$GCC = xyes; then - AM_FCFLAGS=-I . -Wall -fno-repack-arrays -fno-underscoring + AM_FCFLAGS=-I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring ## We like to use C99 routines when available. This makes sure that ## __STDC_VERSION__ is set such that libc includes make them available. AM_CFLAGS=-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings Index: intrinsics/dprod_r8.f90 === --- intrinsics/dprod_r8.f90 (Revision 136654) +++ intrinsics/dprod_r8.f90 (Arbeitskopie) @@ -20,6 +20,7 @@ elemental function _gfortran_specific__dprod_r8 (p1, p2) + implicit none real (kind=4), intent (in) :: p1, p2 real (kind=8) :: _gfortran_specific__dprod_r8 -- Summary: libgfortran should be build with FCFLAGS -fimplicit-none Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36495
[Bug tree-optimization/36493] [4.3/4.4 Regression] vectorizer aliasing bug
--- Comment #1 from irar at il dot ibm dot com 2008-06-11 08:00 --- Reproduced on powerpc64-suse-linux. Doesn't occur when compiled with -O2 -ftree-vectorize instead of -O3 (the vectorizer generates the same code in both cases). -- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-11 08:00:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493
[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry
--- Comment #61 from rguenther at suse dot de 2008-06-11 08:07 --- Subject: Re: [4.2 Regression] points-to analysis slow and memory hungry On Tue, 10 Jun 2008, giovannibajo at libero dot it wrote: --- Comment #60 from giovannibajo at libero dot it 2008-06-10 17:26 --- If a knowledgable GCC developer could suggest *any* workaround at -O1 for this bug in 4.2 (including disabling whatever alias analysys causes the problem), it might be proposed as a fix within distros at least. You can try if --param max-fields-for-field-sensitive=0 improves the situation. Other than that, try, in tree-ssa-structalias.c:create_variable_info_for remove the make_constraint_from_escaped and make_constraint_to_escaped calls for the is_global cases. Note that you need to adjust find_what_p_points_to to include escaped variables if escaped_id is set in the solution and that call clobbering will need similar adjustments (and remember escaped_id includes all globals implicitly). The problem with the sipQt testcase is that it has 1s of global vars it creates constraints for, even though they are unused. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug libgomp/36475] [gomp] register keyword in openmp handled for-loop fails
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 08:20 --- IMHO pedantically that's not valid OpenMP. #pragma omp for for (init-expr; test-expr; incr-expr) structured-block One of the following: init-exprvar = lb integer-type var = lb random-access-iterator-type var = lb pointer-type var = lb register keyword isn't part of the integer-type, it is a storage-class-specifier and the above syntax doesn't mention storage class specifiers anywhere. Furthermore, I don't see why you'd actually need register keyword there at all, in today's compilers the keyword is pretty useless, except when used together with asm (regname), but that's not something we can/want to support for #pragma omp for loops. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36475
[Bug tree-optimization/36493] [4.3/4.4 Regression] vectorizer aliasing bug
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-11 08:37 --- Vectors have the alias set of their element type and int and long do not have conflicting alias sets. The vectorizer clearly should choose vector long * instead of vector int *. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493
[Bug tree-optimization/36474] [4.3 Regression] GCC takes forever to compile a certain file
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-06-11 09:17 --- Fixed as far as possible. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug tree-optimization/36474] [4.3 Regression] GCC takes forever to compile a certain file
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-06-11 09:17 --- Subject: Bug 36474 Author: rguenth Date: Wed Jun 11 09:16:09 2008 New Revision: 136656 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136656 Log: 2008-06-11 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36474 * opts.c (decode_options): Set max-fields-for-field-sensitive parameter to 100 for -O2, -Os and -O3. * params.def (max-fields-for-field-sensitive): Set default to zero. * doc/invoke.texi (max-fields-for-field-sensitive): Document defaults. * gcc.dg/tree-ssa/alias-15.c: Adjust testcase. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/doc/invoke.texi branches/gcc-4_3-branch/gcc/opts.c branches/gcc-4_3-branch/gcc/params.def branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/alias-15.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug middle-end/32492] [4.3 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
--- Comment #16 from josep dot m dot perez at bsc dot es 2008-06-11 10:06
---
The following code still triggers this bug in 4.3 but not in 4.2:
templateclass T
class B {
public:
class C {
public:
__attribute__((always_inline)) C(C const c)
{
}
};
void __attribute__((always_inline)) g(C c)
{
}
};
void trigger(Bint b, Bint::C c)
{
b.g(c);
}
I'm using g++-4.3 (Debian 4.3.1-1) 4.3.1 on x86.
--
josep dot m dot perez at bsc dot es changed:
What|Removed |Added
CC||josep dot m dot perez at bsc
||dot es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32492
[Bug target/36450] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem
--- Comment #8 from aldot at gcc dot gnu dot org 2008-06-11 10:35 --- Created an attachment (id=15747) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15747action=view) ICEs on trunk This ICEs on trunk with -mpreferred-stack-boundary=2 but works wih =4 gcc-4.4-HEAD -std=gnu99 -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -Os -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -march=i386 -mpreferred-stack-boundary=2 -O3 -ftree-vect-loop-version -ftree-vectorize -fvariable-expansion-in-unroller -funswitch-loops -funroll-all-loops -ftree-loop-distribution -ftree-loop-im -fivopts -fvect-cost-model -mtune=pentium4 -march=pentium4 -Wfatal-errors -c -o sort.o sort.5.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug middle-end/35412] [4.4 Regression] Correctness with -ftrapv depended on libcall notes
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35542
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug c++/36407] [4.3/4.4 regression] ICE with conversion and -fpermissive
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-11 11:10 --- Thanks for the clarification. I agree. Jason, can you have a look here? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com Priority|P4 |P1 Summary|[4.3/4.4 regression] ICE|[4.3/4.4 regression] ICE |with invalid conversion |with conversion and - ||fpermissive http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36407
[Bug target/35860] [4.3/4.4 Regression] [avr] code bloat caused by -fsplit-wide-types
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 Regression] [avr] code |[4.3/4.4 Regression] [avr] |bloat caused by -fsplit-|code bloat caused by - |wide-types |fsplit-wide-types Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug fortran/36342] [4.4 Regression] Missing file name in compilation diagnostics of preprocessed fortran source
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug testsuite/36440] [4.4 Regression] FAIL: g++.dg/cdce3.C on powerpc-apple-darwin8.5.0
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36440
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #7 from aph at gcc dot gnu dot org 2008-06-11 10:49 --- This isn't just a mingw bug. It is also manifested in GNU/Linux if gcc itself is built with -O0, as you need to do when debugging gcc. There perhaps should be some limit to how far VRP goes before giving up. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-11 10:49:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug testsuite/36458] [4.4 Regression] Invalid fortran-torture -msse2 tests on Athlon XP
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36458
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug tree-optimization/36493] [4.3/4.4 Regression] vectorizer aliasing bug
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493
[Bug tree-optimization/36449] Incorrect code generated for access to a large struct
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-11 11:15 --- Fixed for 4.3.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.4.0 |4.3.2 4.4.0 Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36449
[Bug c++/35336] Broken diagnostic: 'bit_field_ref' not supported by dump_expr
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-11 11:15 --- Subject: Bug 35336 Author: rguenth Date: Wed Jun 11 11:14:59 2008 New Revision: 136662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136662 Log: 2008-06-11 Richard Guenther [EMAIL PROTECTED] PR middle-end/35336 * fold-const.c (fold_truthop): Remove code generating BIT_FIELD_REFs of structure bases. (fold_binary): Likewise. (make_bit_field_ref): Remove. (optimize_bit_field_compare): Remove. (all_ones_mask_p): Remove. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35336
[Bug c++/36407] [4.3/4.4 regression] ICE with invalid conversion
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-06-11 10:47 --- The code used to compile with -fpermissive, so this is actually an ice-on-valid-code bug. Given that this is also a regression on the 4.3 branch, the priority should by P1, I think. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords|error-recovery, ice-on- |ice-on-valid-code |invalid-code| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36407
[Bug bootstrap/33396] add --enable-intermodule
--- Comment #11 from aldot at gcc dot gnu dot org 2008-06-11 12:30 --- Created an attachment (id=15748) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15748action=view) updated patch including unwind and eh and handling of static includes untested draft for --disable-shared which contains: # XXX: FIXME: for static libs vis_hide is forced off, so why does the normal # build above have this superfluous occurence? # Play safe and provide this wrong rule and retain the mention of vis_hide # above. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Attachment #15046|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33396
[Bug c++/36486] g++ accepts code with ambiguous overloading
--- Comment #3 from richard-gccbugzilla at metafoo dot co dot uk 2008-06-11 12:58 --- I'm not 100% certain that g++ is at fault. Given that icc, Comeau and MS all reject it, I'm inclined to think that g++ is probably the one which gets this wrong, so I've raised this here first. This hinges on whether f0 and f1 are ordered by the standard partial ordering on function templates. It appears superficially that they are not, since from the arguments to f1 you cannot deduce the template parameters of f0, nor vice versa. However, it appears to depend on interpretation of [temp.deduct.type]/5, which says that The non-deduced contexts are: [...] A template parameter used in the parameter type of a function parameter that has a default argument that is being used in the call for which argument deduction is being done. I'm not sure whether that applies here, but if it does, perhaps that makes f1 more specialized than f0, and this is a bug in all the other compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
[Bug bootstrap/36496] New: [4.2.3/4.2.4 regression] bootstrap error - section .eh_frame: bad cie version
During bootstrap get ld: fatal: unwind table: file /usr/local/gcc-4.2.4/src/obj-x86_64-SunOS/./gcc/amd64/crtend.o: section .eh_frame: bad cie version 0: offset 0xfd7fffdfcbe0 This did NOT happen during build of gcc-4.2.3. This may be related to gccbug # 33100. -- Summary: [4.2.3/4.2.4 regression] bootstrap error - section .eh_frame: bad cie version Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kate01123 at gmail dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36496
[Bug other/36498] New: [4.3 Regression] time/memory hog for large c++ source.
the 4.3.1 release introduces a new time/memory hog which wasn't present in 4.3.0-20080417. results (with default max-fields-for-field-sensitive param): 4.3.0-20080417 : mem: 580MB, time: 1min32sec. 4.3.1 : aborted at 4.3GB/14min. -- Summary: [4.3 Regression] time/memory hog for large c++ source. Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #1 from pluto at agmk dot net 2008-06-11 14:05 --- Created an attachment (id=15749) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15749action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug fortran/36497] New: USE association, cray pointers and error checking
gfortran -fcray-pointer accepts the following program while ifort rejects it with: Error: line 11: The attributes of this name conflict with those made accessible by a USE statement. [X] If one comments the Cray pointer out, gfortran prints: Error: Symbol 'x' at (1) already has basic type of INTEGER Expected: a) gfortran also detects this problem when using Cray pointers b) The error message is made clearer by pointing to the module module test integer(8) ipt, x pointer (ipt, x) end module program bar use test ! implicit none integer(8) x x = 2 print *,x end -- Summary: USE association, cray pointers and error checking Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36497
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #2 from pluto at agmk dot net 2008-06-11 14:10 --- testcase tested with: $ i486-gnu-linux-g++ -g0 -O2 -std=gnu++0x -fno-threadsafe-statics -fPIC hescoreScr.ii -c gdb report still the same backtrace: (gdb) bt #0 0x0066891b in set_bb_for_stmt () #1 0x0069c4cb in create_phi_node () #2 0x0068d066 in insert_phi_nodes_for () #3 0x0068d3e8 in insert_updated_phi_nodes_for () #4 0x0068e59c in update_ssa () #5 0x006bd21a in compute_may_aliases () #6 0x005f2c8a in execute_function_todo () #7 0x005f274d in execute_todo () #8 0x005f294a in execute_one_pass () #9 0x005f2a9c in execute_pass_list () #10 0x005f2aae in execute_pass_list () #11 0x00695892 in tree_rest_of_compilation () #12 0x00792902 in cgraph_expand_function () #13 0x0079404e in cgraph_optimize () #14 0x004482ef in cp_write_global_declarations () #15 0x0066362e in toplev_main () #16 0x2b69a416c4a4 in __libc_start_main () from /lib64/libc.so.6 #17 0x004023a9 in _start () -- pluto at agmk dot net changed: What|Removed |Added GCC target triplet||i486-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug c++/36499] New: non-compliant behaviour with nested classes
First, please excuse me for my poor english.
Actual standard says on section 11.8 Nested classes [class.access.nest]
The members of a nested class have no special access to members of an enclosing
class, nor to classes or
functions that have granted friendship to an enclosing class; the usual access
rules (clause 11) shall be
obeyed. The members of an enclosing class have no special access to members of
a nested class; the usual
access rules (clause 11) shall be obeyed and gives as example
class E {
int x;
class B { };
class I {
B b; // error: E::B is private
int y;
void f(E* p, int i)
{
p-x = i; // error: E::x is private
}
};
int g(I* p)
{
return p-y; // error: I::y is private
}
};
While trying this code, Gcc sees well that I::y is private in the g function,
but doesn't in the void e::i::f one, nor for the B b declaration.
--
Summary: non-compliant behaviour with nested classes
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe dot dunski at ibelgique dot com
GCC host triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36499
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-11 14:17 --- The warning happens also with the pointer being ref-all as the alias warning code asks for the alias set of the pointed-to type. Thus it probably makes sense to give that alias-set zero as well (or rather special-case the alias check, as tree-ssa-alias.c:may_alias_p does). I have a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug c++/36405] [4.3/4.4 regression] ICE with typeid of member function
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-11 14:27 --- Caused by PR29928. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36405
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-06-11 14:29
---
Note that the documentation of may_alias is extremely confusing IMHO (and
c_common_get_alias_set is wrong).
Accesses to objects with types with this attribute are not subjected to
type-based alias analysis, but are instead assumed to be able to alias
any other type of objects, just like the @code{char} type.
the char type is not special, but instead you are allowed to access all
memory via an _lvalue_ of character type!
The above suggests that
long __attribute__((__may_alias__)) x;
*(short *)x;
is ok, but it is not.
A better wording would be to say
Accesses through pointers to types with this attribute are not subject
to type-based alias analysis, but are instead assumed to be able to alias
any other type of objects. These lvalue expressions are treated like
having a character type. ...
Note that an object of a type with this attribute does not have any
special semantics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug bootstrap/36496] [4.2.3/4.2.4 regression] bootstrap error - section .eh_frame: bad cie version
--- Comment #1 from hjl dot tools at gmail dot com 2008-06-11 14:41 --- *** This bug has been marked as a duplicate of 33100 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36496
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #18 from hjl dot tools at gmail dot com 2008-06-11 14:41 --- *** Bug 36496 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||kate01123 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-11 14:46 --- Eventually the fix for PR36154 may be the cause. Can you check backing out 2008-05-08 Richard Guenther [EMAIL PROTECTED] PR middle-end/36154 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Make sure to create a representative for trailing arrays for PTA. ? Or the fix for PR36339, which would be 2008-05-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Move pt_anything and subvariable clobbering code out of the loop. 2008-05-27 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Escaped pt_anything pointers cause all addressable variables to be call clobbered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-11 14:55 --- Created an attachment (id=15750) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15750action=view) unincluded testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-06-11 15:20 --- The offending function is virtual bool hcScr::hescoreScr::init(Tcl_Interp*, hc::IAccessBase*, vcm::vcmptrcfgmgr::IConfigManager) but probably only after inlining. The trunk is fine, as is compiling with --param max-fields-for-field-sensitive=0. Most of the time/memory is spent in update_ssa () in phi-insertion. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||compile-time-hog, memory-hog Known to work|4.3.0 |4.3.0 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-06-11 15:20:43 date|| Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug tree-optimization/36245] [4.4 Regression] internal compiler error: in build2_stat, at tree.c:3116
--- Comment #14 from dnovillo at gcc dot gnu dot org 2008-06-11 15:39 --- Subject: Bug 36245 Author: dnovillo Date: Wed Jun 11 15:39:09 2008 New Revision: 136672 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136672 Log: 2008-06-11 Diego Novillo [EMAIL PROTECTED] Merge from lto-streamer sub-branch: 2008-06-09 Bill Maddox [EMAIL PROTECTED] * lto-tags.h: Add new tags LTO_local_type_ref and LTO_global_type_ref. Split LTO_type_decl and LTO_field_decl into LTO_type_decl0, LTO_type_decl1, LTO_field_decl0, and LTO_field_decl1. * lto-tree-tags.h: Set names and tree code mappings for the new tags. * lto-function-out.c: Tidy comments and formatting. (output_record_start): Add forward declaration. (type_function_context): New function. (field_decl_is_local, type_decl_is_local): New functions. (output_type_ref_1): Write local (e.g., variably-modified) types to local_decls stream. (output_type_ref): Use type_ref as debug token to avoid confusing clash with use of type elsewhere. (output_local_decl_ref): Update comment. (output_expr_operand): Cases for FIELD_DECL and TYPE_DECL now write local declarations to local_decls stream. (output_local_var): Rename to output_local_var_decl. (output_local_var_decl): Remove code to set slot in local_decls_index, now handled by output_local_decl. (output_local_tree): New function. (output_local_field_decl, output_local_type_decl, output_local_type): New functions. (output_local_decl): New function. (output_field_decl): Use new tag LTO_field_decl1, to distinguish from local fields. (output_type_decl): Use new tag LTO_type_decl1, to distinguish from local fields. * lto-function-in.c: Tidy comments and formatting. (input_local_tree, input_local_var_decl, input_local_field_decl, input_local_type_decl, input_local_type): Add forward declarations. (input_type_ref_1): Distinguish references to global or local declaration streams. (input_type_ref): Use type_ref as debug token to avoid confusing clash with use of type elsewhere. (input_expr_operand): Cases for FIELD_DECL and TYPE_DECL now read local declarations from local_decls stream. (input_local_tree): New function. (input_local_var): Rename to input_local_var_decl. (input_local_var_decl): Input record tag is now an argument. (input_local_field_decl, input_local_type_decl, input_local_type): New functions. (input_local_decl): New function. (input_local_vars): Call input_local_decl instead of input_local_var. (lto_static_init_local): Don't call add_referenced_var on non-vars. * lto-section-out.c (lto_hash_decl_slot_node, lto_eq_decl_slot_node): Use object pointer, not UID, as hash key. 2008-06-04 Rafael Espindola [EMAIL PROTECTED] * lto-function-out.c (output_tree): call error with the TREE_CODE name. 2008-06-04 Ollie Wild [EMAIL PROTECTED] * dwarf2out.c (dwarf2_called_from_lto_p): Remove. (current_fde): New function. (add_fde_cfi): Call current_fde. (lookup_cfa): Call curent_fde. (dwarf2out_end_epilogue): Call current_fde. (dwarf2out_switch_text_section: Call current_fde. (lto_void_type_die): Remove. (dwarf_attr_name): Declare static. Remove flag_generate_lto check. (assign_symbol_name): Remove. (assign_symbol_names): Expand call to assign_symbol_name. (base_type_die): Replace DW_ATE_GNU_complex_unsigned and DW_ATE_GNU_complex_signed encodings with DW_ATE_lo_user. Remove byte_size computation. Remove extra precision information. (may_reference_to_unused): Rename reference_to_unused. (rtl_for_decl_init): Rename calls to may_reference_to_unused. (convert_cfa_to_fb_loc_list): Call current_fde. (gen_subprogram_die): Remove flag_generate_lto and dwarf2_called_from_lto_p checks. (gen_variable_die): Remove context_die == comp_unit_die checks. (add_high_low_attributes): Remove
[Bug c++/36405] [4.3/4.4 regression] ICE with typeid of member function
--- Comment #3 from paolo dot carlini at oracle dot com 2008-06-11 16:58 --- Ok... -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-11 16:58:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36405
[Bug c++/4131] The C++ compiler don't place a const class object to .rodata section with non trivial constructor
--- Comment #22 from jyasskin at gmail dot com 2008-06-11 18:05 ---
This is related to generalized constant expressions
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf) in C++0x.
Those will be marked by the explicit 'constexpr' keyword and will require the
initialization to be done at static rather than dynamic initialization time,
while this bug is about the optional optimization of moving some extra objects
from dynamic to static time.
If I understand it correctly, in C++0x, the following code will require f to be
placed in either the .rodata or .data sections, rather than .bss as it's placed
now.
struct Foo
{
constexpr Foo(int a) { t = a; }
int t;
}
constexpr Foo f(1);
I'd also like to point out that with the extra optimization described here, the
following code could also place f in the .data section:
struct Foo
{
constexpr Foo(int a) { t = a; }
int t;
}
Foo f(1); // Note that f is non-const.
This would be useful for getting atomic variables initialized before anything
else starts up, but it may well belong in a separate feature request.
--
jyasskin at gmail dot com changed:
What|Removed |Added
CC||jyasskin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
gfortran-4.3.1 internal compiler error
gfortran built on a CoreDuo running MacOSX 10.4.11 from gcc-4.3.1 using --enable-languages=c,c++,fortran,objc,java,obj-c++,treelang --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x- includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable- libjava-multilib --with-arch=nocona --build=i686-apple-darwin8 # gfortran -v Using built-in specs. Target: i686-apple-darwin8 Configured with: ../gcc-4.3.1/configure --prefix=/sw --prefix=/sw/lib/ gcc4.3 --mandir=/sw/share/man --infodir=/sw/share/info --enable- languages=c,c++,fortran,objc,java,obj-c++,treelang --with-arch=nocona --build=i686-apple-darwin8 --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/ X11R6/lib --disable-libjava-multilib Thread model: posix gcc version 4.3.1 (GCC) The option -ftree-loop-linear causes an internal compiler error in the following command : gfortran -fPIC -O3 -Wall -ftree-loop-linear -c cget35.f -o cget35.o cget35.f: In function 'cget35': cget35.f:1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. (and the same with zget35.f _ both come from netlib's LAPACK testing, in lapack-3.1.1/TESTING/EIG from http://www.netlib.org/lapack/ lapack-3.1.1.tgz, both attached) The difficulty arose originally with several additional -f flags on the compile command, removed them for clarity. Also it is not machine-specific; I get the same on a powerpc G5 . (with appropriately changed machine-specific configure options for gcc-4.3.1) Note also there are many variants of those files in that directory [sget... , zget... , other numbers (24, 36, ..) replacing 35 ] that do not have this trouble. gfortran-4.3.0 did not have this problem. JF Mertens cget35.f Description: Binary data zget35.f Description: Binary data
[Bug target/36450] [4.4 Regression] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem
--- Comment #9 from aldot at gcc dot gnu dot org 2008-06-11 18:12 --- (In reply to comment #8) Created an attachment (id=15747) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15747action=view) [edit] ICEs on trunk This ICEs on trunk with -mpreferred-stack-boundary=2 but works wih =4 s/wih =4/with anything but 2/ and of course works with e.g. 4.3.0 20080218 or trunk from a few weeks ago. gcc-4.4-HEAD -S -o /dev/null -fno-guess-branch-probability -mpreferred-stack-boundary=2 -Os sort.5.i -v Using built-in specs. Target: i686-linux-gnu Configured with: ../../src/gcc-4.4/configure -v --enable-languages=c,fortran --prefix=/opt/i686/gcc-4.4/ --enable-shared --with-system-zlib --libexecdir=/opt/i686/gcc-4.4/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.4-HEAD --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-werror --enable-checking=yes --enable-debug --with-gmp=/opt/i686/gmp-4.2.2/ --with-mpfr=/opt/i686/mpfr-2.3.0 --disable-multilib --disable-intermodule i686-linux-gnu Thread model: posix gcc version 4.4.0 20080611 (experimental) (GCC) COLLECT_GCC_OPTIONS='-S' '-o' '/dev/null' '-fno-guess-branch-probability' '-mpreferred-stack-boundary=2' '-Os' '-v' '-mtune=generic' /opt/i686/gcc-4.4/bin/../../gcc-4.4/lib/gcc/i686-linux-gnu/4.4.0/cc1 -fpreprocessed sort.5.i -quiet -dumpbase sort.5.i -mpreferred-stack-boundary=2 -mtune=generic -auxbase-strip /dev/null -Os -version -fno-guess-branch-probability -o /dev/null GNU C (GCC) version 4.4.0 20080611 (experimental) (i686-linux-gnu) compiled by GNU C version 4.4.0 20080611 (experimental), GMP version 4.2.1, MPFR version 2.3.0-p4. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0d5bbb5fdfd81762cf963cab59cb1e94 sort.5.i:13: warning: useless storage class specifier in empty declaration sort.5.i: In function sort_main: sort.5.i:75: internal compiler error: in insert_save, at caller-save.c:787 Please submit a full bug report, -- aldot at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in |[4.4 Regression] ICE in |insert_restore/insert_save |insert_restore/insert_save |with GET_MODE_ALIGNMENT mem |with GET_MODE_ALIGNMENT mem http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug c/36500] New: gcc ICEs when being passed -mfpu=neon
When crosscompiling for OMAP3 gcc will ICE if you use -mfpu=neon
No ICE: -march=armv7-a -mtune=cortex-a8 -mfpu=vfp -mfloat-abi=softfp
ICE: -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
Testcase:
[EMAIL PROTECTED]:/OE/angstrom-tmp/work$ cat helloworld.c
#include stdio.h
int main(void)
{
printf(Hello world!\n); while(1);
return 0;
}
[EMAIL PROTECTED]:/OE/angstrom-tmp/work$ arm-angstrom-linux-gnueabi-gcc-4.3.1
helloworld.c -o helloworld -march=armv7-a -mtune=cortex-a8 -mfpu=neon
-mfloat-abi=softfp
helloworld.c:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Replace it with -mfpu=vfp:
[EMAIL PROTECTED]:/OE/angstrom-tmp/work$ arm-angstrom-linux-gnueabi-gcc-4.3.1
helloworld.c -o helloworld -march=armv7-a -mtune=cortex-a8 -mfpu=vfp
-mfloat-abi=softfp
[EMAIL PROTECTED]:/OE/angstrom-tmp/work$ file helloworld
helloworld: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux
2.6.14, dynamically linked (uses shared libs), not stripped
--
Summary: gcc ICEs when being passed -mfpu=neon
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: koen at openembedded dot org
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36500
[Bug c/36500] gcc ICEs when being passed -mfpu=neon
--- Comment #1 from koen at openembedded dot org 2008-06-11 18:53 --- marking it as blocker, since NEON can't be used -- koen at openembedded dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36500
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #6 from pluto at agmk dot net 2008-06-11 19:27 --- this patch causes regression. r135125 | rguenth | 2008-05-09 21:19:33 +0200 (Fri, 09 May 2008) | 10 lines 2008-05-09 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36187 * tree-dfa.c (dump_variable): Correct dumping of SFT_BASE_FOR_COMPONENTS_P. * tree-ssa-structalias.c (set_uids_in_ptset): Set SFT_UNPARTITIONABLE_P correctly for the union case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-06-11 19:36 --- Then the following should fix it. Index: tree-flow-inline.h === --- tree-flow-inline.h (revision 135770) +++ tree-flow-inline.h (working copy) @@ -1712,6 +1712,11 @@ var_can_have_subvars (const_tree v) if (!DECL_P (v) || MTAG_P (v)) return false; + /* Unions cannot have subvars. */ + if (TREE_CODE (TREE_TYPE (v)) == UNION_TYPE + || TREE_CODE (TREE_TYPE (v)) == QUAL_UNION_TYPE) +return false; + /* Aggregates can have subvars. */ if (AGGREGATE_TYPE_P (TREE_TYPE (v))) 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|2008-06-11 15:20:43 |2008-06-11 19:36:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug c++/36501] New: GCC accepts invalid namespace qualified name when last namespace is repeated
The following code is accepted by GCC without any error. It shows that if the
last qualified name given is repeated any number of times then GCC ignores it.
GCC versions from v3.3.3 to v4.3.1 tested on Darwin and Linux platforms.
namespace fred
{
class A
{
public:
A()
{ }
};
}
int main()
{
fred::A a0;
fred::A::A a1;
fred::A::A::Aa2;
fred::A::A::A::A a3;
return 0;
}
--
Summary: GCC accepts invalid namespace qualified name when last
namespace is repeated
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gp dot bolton at computer dot org
GCC build triplet: i386-apple-darwin9.2.2
GCC host triplet: i386-apple-darwin9.2.2
GCC target triplet: i386-apple-darwin9.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36501
[Bug c/36500] gcc ICEs when being passed -mfpu=neon
--- Comment #2 from jsm28 at gcc dot gnu dot org 2008-06-11 19:54 --- Already fixed by my patches r136660 on trunk, r136661 on 4.3 branch. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36500
[Bug target/36425] Option -mno-isel not working
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-06-11 20:03 --- Subject: Bug 36425 Author: jsm28 Date: Wed Jun 11 20:02:55 2008 New Revision: 136681 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136681 Log: 2008-06-11 Edmar Wienskoski [EMAIL PROTECTED] PR target/36425 * config/rs6000/rs6000.c (rs6000_override_options): Set rs6000_isel conditionally to the absence of comand line override. * config/rs6000/linuxspe.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Remove duplicate rs6000_isel setting. * config/rs6000/eabispe.h: Ditto. testsuite: 2008-06-11 Edmar Wienskoski [EMAIL PROTECTED] * gcc.target/powerpc/e500-1.c: New test case to verify mno-isel option. Added: trunk/gcc/testsuite/gcc.target/powerpc/e500-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/eabispe.h trunk/gcc/config/rs6000/linuxspe.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36425
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #8 from pluto at agmk dot net 2008-06-11 20:14 --- (In reply to comment #7) Then the following should fix it. Index: tree-flow-inline.h === --- tree-flow-inline.h (revision 135770) +++ tree-flow-inline.h (working copy) @@ -1712,6 +1712,11 @@ var_can_have_subvars (const_tree v) if (!DECL_P (v) || MTAG_P (v)) return false; + /* Unions cannot have subvars. */ + if (TREE_CODE (TREE_TYPE (v)) == UNION_TYPE + || TREE_CODE (TREE_TYPE (v)) == QUAL_UNION_TYPE) +return false; + /* Aggregates can have subvars. */ if (AGGREGATE_TYPE_P (TREE_TYPE (v))) return true; with this change g++ needs ~1GB and ~4minutes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug c++/36242] OpenMP multi-threading crashes
--- Comment #3 from steven at gcc dot gnu dot org 2008-06-11 20:19 --- Jakub is the OpenMP guru. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242
[Bug c++/36242] OpenMP multi-threading crashes
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-11 20:29 --- Using OpenMP pragmas in multiple pthread_create created threads concurrently isn't supported in 4.2/4.3. There is a support for it on the trunk since a few days ago though. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-11 20:41 --- Hm, the patch in comment #6 only affects the case where we have a union with subvars. Did you check that just reverting this patch brings us back to 580MB and 1min32? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #10 from pluto at agmk dot net 2008-06-11 20:50 --- (In reply to comment #9) Hm, the patch in comment #6 only affects the case where we have a union with subvars. Did you check that just reverting this patch brings us back to 580MB and 1min32? yes, i've checked r135124 and it needs only ~580MB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-06-11 21:04 --- Ah, but that test also reverts all followup patches, like 2008-05-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Move pt_anything and subvariable clobbering code out of the loop. 2008-05-27 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Escaped pt_anything pointers cause all addressable variables to be call clobbered. so, did you apply the patch in comment #7 on top of r135125 or on top of the branch head? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug target/36494] Char arrays gets corrupted in avr programs.
--- Comment #3 from martin at kfib dot org 2008-06-11 21:13 --- Exact line for compiling is: avr-gcc -mmcu=atmega48 -Walltest.c -o test And now I'm very confused. I KNOW I've tried with and without optimization before and that it made no difference (or possibly I'm a major clutz) but now I can only reproduce the bug if I don't optimize. If I optimize (all kinds), I get 3, but without optimization I get 2. This is what I get without optimization: 6c: df 93 pushr29 6e: cf 93 pushr28 70: 00 d0 rcall .+0 ; 0x72 main+0x6 72: 00 d0 rcall .+0 ; 0x74 main+0x8 74: 00 d0 rcall .+0 ; 0x76 main+0xa 76: cd b7 in r28, 0x3d ; 61 78: de b7 in r29, 0x3e ; 62 7a: 80 91 00 01 lds r24, 0x0100 7e: 90 91 01 01 lds r25, 0x0101 82: 9c 83 std Y+4, r25; 0x04 84: 8b 83 std Y+3, r24; 0x03 86: 8a e3 ldi r24, 0x3A ; 58 88: 8d 83 std Y+5, r24; 0x05 8a: 1e 82 std Y+6, r1 ; 0x06 8c: 1a 82 std Y+2, r1 ; 0x02 8e: 19 82 std Y+1, r1 ; 0x01 90: 8b 81 ldd r24, Y+3; 0x03 92: 8a 33 cpi r24, 0x3A ; 58 94: 29 f4 brne.+10; 0xa0 main+0x34 96: 89 81 ldd r24, Y+1; 0x01 98: 9a 81 ldd r25, Y+2; 0x02 9a: 81 60 ori r24, 0x01 ; 1 9c: 9a 83 std Y+2, r25; 0x02 9e: 89 83 std Y+1, r24; 0x01 a0: 8d 81 ldd r24, Y+5; 0x05 a2: 8a 33 cpi r24, 0x3A ; 58 a4: 29 f4 brne.+10; 0xb0 main+0x44 a6: 89 81 ldd r24, Y+1; 0x01 a8: 9a 81 ldd r25, Y+2; 0x02 aa: 82 60 ori r24, 0x02 ; 2 ac: 9a 83 std Y+2, r25; 0x02 ae: 89 83 std Y+1, r24; 0x01 b0: e7 e2 ldi r30, 0x27 ; 39 b2: f0 e0 ldi r31, 0x00 ; 0 b4: 8f e0 ldi r24, 0x0F ; 15 b6: 80 83 st Z, r24 b8: e8 e2 ldi r30, 0x28 ; 40 ba: f0 e0 ldi r31, 0x00 ; 0 bc: 89 81 ldd r24, Y+1; 0x01 be: 80 83 st Z, r24 c0: 80 e0 ldi r24, 0x00 ; 0 c2: 90 e0 ldi r25, 0x00 ; 0 c4: 26 96 adiwr28, 0x06 ; 6 c6: 0f b6 in r0, 0x3f; 63 c8: f8 94 cli ca: de bf out 0x3e, r29 ; 62 cc: 0f be out 0x3f, r0; 63 ce: cd bf out 0x3d, r28 ; 61 d0: cf 91 pop r28 d2: df 91 pop r29 d4: 08 95 ret The result is that my LEDs indicate a very shining 0x02 on the outport. However, with -Os I get: 6c: 8f e0 ldi r24, 0x0F ; 15 6e: 87 b9 out 0x07, r24 ; 7 70: 83 e0 ldi r24, 0x03 ; 3 72: 90 e0 ldi r25, 0x00 ; 0 74: 88 b9 out 0x08, r24 ; 8 76: 80 e0 ldi r24, 0x00 ; 0 78: 90 e0 ldi r25, 0x00 ; 0 7a: 08 95 ret This is with version 4.3.1. I've verified with 4.1.2 and it behaves the same; without optimization it bugs, with it works. I guess I forgot to do a make clean and thus deserve the title klutz. Sorry for the confusion. Unfortunately the same doesn't go for my actual program (this one was just a test case). It bugs badly no matter optimization (yes, I've verified that I've made a make clean this time) and it boils down to that if I do: display.write_string (Hello); it bugs, but if I do: char h[6]; h[0] = 'H'; h[1] = 'e'; h[2] = 'l'; h[3] = 'l'; h[4] = 'o'; h[5] = 0; display.write_string (h); it prints out a nice little Hello on my LCD. Something is definitely very fishy in how the char-arrays are handled and I can't figure it out. I know you said in the faq that you don't want the source code, but if you want to look at it it's at http://martin.kfib.org/atmelLCD.zip. Maybe it can shed some light over this. It behave the same if I optimize or not (and I hope that I haven't screwed anything up now...); in test.cc if I use the code that I claim works I get a nice little Hello on the LCD but if I use the one that I clam doesn't work I just get garbage on the LCD. Would you like me to generate .i-files too or what's the next step? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36494
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #12 from pluto at agmk dot net 2008-06-11 21:17 --- (In reply to comment #11) Ah, but that test also reverts all followup patches, like (...) so, did you apply the patch in comment #7 on top of r135125 or on top of the branch head? on top of the branch head (r136662). summary: r135124 needs max. 580MB(the 'virt' column from htop)/~1.5min r135125 and newer needs at least 4.3GB/14min. r136662 with suggested patch needs ~1GB/4min. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug c/36500] gcc ICEs when being passed -mfpu=neon
--- Comment #3 from koen at openembedded dot org 2008-06-11 21:44 --- And indeed that patch fixes it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36500
[Bug target/36494] Char arrays gets corrupted in avr programs.
--- Comment #4 from hutchinsonandy at aim dot com 2008-06-11 22:05 --- I'm sure Eric will weight in again to verify code posted executes correctly (it looks correct to me). I suspect you have some config or memory issue. For example, unoptimized, the string is stored at location 0x100 and 0x101. So if this get trashed, (by another part of software) the result will be 2. Also watch your stack space. Unoptimized, it will be large and overflow data areas The optimization, of course will bypass such problems -and that works. This also shows that front end and middle of gcc are ok. The code contains no tricky or seldom used instructions - so it appears highly unlikely to be a problem with back end which is specfic to avr. If Eric confirms this he may mark bug as invalid - but you can pursue a solution on other forums (such as http://lists.nongnu.org/mailman/listinfo/avr-gcc-list) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36494
[Bug target/36502] New: i386/darwin generates unnecessary stack ops in every function
gcc -v
Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../gcc/configure --prefix=/usr/local/gcc44
--enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw
--with-mpfr=/sw --disable-nls --disable-bootstrap --enable-checking=yes,rtl
--enable-languages=c,c++,objc
Thread model: posix
gcc version 4.4.0 20080611 (experimental) (GCC)
gcc changes esp in every function, even if it has no stack values. Given:
int a;
void f() {a++;}
gcc -O -fomit-frame-pointer -fno-pic -S add.c
_f:
subl$12, %esp
incl_a
addl$12, %esp
ret
Apple's GCC doesn't do this and neither does 4.4 on other systems (as far as I
know).
--
Summary: i386/darwin generates unnecessary stack ops in every
function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC target triplet: i386-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36503] New: x86 can use x -y for x 32-y
gcc -v
Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../gcc/configure --prefix=/usr/local/gcc44
--enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw
--with-mpfr=/sw --disable-nls --disable-bootstrap --enable-checking=yes,rtl
--enable-languages=c,c++,objc
Thread model: posix
gcc version 4.4.0 20080611 (experimental) (GCC)
gcc compiles
int shift32(int i, int n)
{
return i (32 - n);
}
to
_shift32:
subl$12, %esp
movl$32, %ecx
subl20(%esp), %ecx
movl16(%esp), %eax
sarl%cl, %eax
addl$12, %esp
ret
Since all 286-and-up CPUs only use the low 5 bits of ecx when shifting, this
can be:
_shift32:
movl8(%esp), %ecx
movl4(%esp), %eax
negl %ecx
sarl%cl, %eax
ret
This is very common in bitstream readers, where it's used to read the top N
bits from a word. ffmpeg already has an inline asm to do it, which I'd like to
get rid of.
I'd guess this applies to some other architectures; it probably works on
x86-64, but doesn't on PPC.
--
Summary: x86 can use x -y for x 32-y
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC target triplet: i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
[Bug target/36503] x86 can use x -y for x 32-y
-- astrange at ithinksw dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
[Bug target/36504] New: [4.3 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
when building xorg-server with -O3 -fprefetch-loop-arrays and gcc-4.3.1 on an amd64 linux system, we hit an ICE like so: texenvprogram.c: In function 'emit_combine': texenvprogram.c:739: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. older versions of gcc seem to work. building for x86 seems to work. -- Summary: [4.3 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vapier at gentoo dot org GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug target/36504] [4.3 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
--- Comment #1 from vapier at gentoo dot org 2008-06-11 23:37 --- Created an attachment (id=15751) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15751action=view) reduced texenvprogram.i $ gcc -c -O3 -fprefetch-loop-arrays texenvprogram.i texenvprogram.i: In function ?create_new_program?: texenvprogram.i:20: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-11 23:43 --- This is due to alignment requirement interacting weirdly with the back-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug c++/36501] GCC accepts invalid namespace qualified name when last namespace is repeated
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-11 23:44 --- *** This bug has been marked as a duplicate of 11764 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36501
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-06-11 23:44 --- *** Bug 36501 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gp dot bolton at computer ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
[Bug c++/36499] non-compliant behaviour with nested classes
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-11 23:49 --- This is not a bug in GCC, read PR 359 for more info why. *** This bug has been marked as a duplicate of 359 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36499
[Bug c++/359] [DR 45] g++ incorrectly grants access to private members to nested classes
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-06-11 23:49 --- *** Bug 36499 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||philippe dot dunski at ||ibelgique dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=359
[Bug target/36503] x86 can use x -y for x 32-y
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 00:05 --- I'd guess this applies to some other architectures; Not really. It depends on the definition of the shift. Most targets have undefined values are produced from negative shifts values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #7 from kris dot van dot hees at oracle dot com 2008-06-12 00:12 --- Patch looks good to me. Good catch! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
