[Bug java/30292] ICE on compiling .java by gcc(1)
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-27 11:14 --- The reason we did this is that, when we wrote libgcj, we wanted to be able to control various abi-changing things via command-line arguments. And, the best place to do much of the checking was in the libgcj configure script; many of the discoveries made here need to be known both to libgcj and to gcj at compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30292
[Bug c++/30309] New: ICE with g++ -fipa-pta and malloc(?)
Since a few days the following code triggers an ICE with the latest SVN
version:
cat bug.c
void* malloc(unsigned);
void f()
{
void* p = malloc(0);
}
g++ -fipa-pta bug.c
bug.c: In function 'void f()':
bug.c:5: internal compiler error: Segmentation fault
Compilation with gcc works as expected. Renaming 'malloc' solves (or hides?)
the problem.
--
Summary: ICE with g++ -fipa-pta and malloc(?)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at pi dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30309
[Bug fortran/20896] ambiguous interface not detected
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-27 13:46 --- Subject: Bug 20896 Author: pault Date: Wed Dec 27 13:46:47 2006 New Revision: 120218 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120218 Log: 2006-12-27 Paul Thomas [EMAIL PROTECTED] PR fortran/20896 * interface.c (check_sym_interfaces): Try to resolve interface reference as a global symbol, if it is not a nodule procedure. (compare_actual_formal): Remove call to gfc_find_symbol; if the expression is already a variable it is locally declared and this has precedence. gfortran.h : Add prototype for resolve_global_procedure. resolve.c (resolve_global_procedure): Remove static attribute from function declaration. (resolve_fl_procedure): Remove symtree declaration and the redundant check for an ambiguous procedure. PR fortran/25135 * module.c (load_generic_interfaces): If the symbol is present and is not generic it is ambiguous. 2006-12-27 Paul Thomas [EMAIL PROTECTED] PR fortran/20896 * gfortran.dg/interface_10.f90: New test. * gfortran.dg/dummy_procedure_1.f90: Add error for call s1(z), since z is already, locally a variable. PR fortran/25135 * gfortran.dg/generic_11.f90: New test. * gfortran.dg/interface_7.f90: Remove name clash between module name and procedure 'x' referenced in the interface. Added: trunk/gcc/testsuite/gfortran.dg/generic_11.f90 trunk/gcc/testsuite/gfortran.dg/interface_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90 trunk/gcc/testsuite/gfortran.dg/interface_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20896
[Bug fortran/25135] Interface name does not conflict with subroutine name
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-27 13:46 --- Subject: Bug 25135 Author: pault Date: Wed Dec 27 13:46:47 2006 New Revision: 120218 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120218 Log: 2006-12-27 Paul Thomas [EMAIL PROTECTED] PR fortran/20896 * interface.c (check_sym_interfaces): Try to resolve interface reference as a global symbol, if it is not a nodule procedure. (compare_actual_formal): Remove call to gfc_find_symbol; if the expression is already a variable it is locally declared and this has precedence. gfortran.h : Add prototype for resolve_global_procedure. resolve.c (resolve_global_procedure): Remove static attribute from function declaration. (resolve_fl_procedure): Remove symtree declaration and the redundant check for an ambiguous procedure. PR fortran/25135 * module.c (load_generic_interfaces): If the symbol is present and is not generic it is ambiguous. 2006-12-27 Paul Thomas [EMAIL PROTECTED] PR fortran/20896 * gfortran.dg/interface_10.f90: New test. * gfortran.dg/dummy_procedure_1.f90: Add error for call s1(z), since z is already, locally a variable. PR fortran/25135 * gfortran.dg/generic_11.f90: New test. * gfortran.dg/interface_7.f90: Remove name clash between module name and procedure 'x' referenced in the interface. Added: trunk/gcc/testsuite/gfortran.dg/generic_11.f90 trunk/gcc/testsuite/gfortran.dg/interface_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90 trunk/gcc/testsuite/gfortran.dg/interface_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25135
[Bug tree-optimization/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-27 16:18 --- The patch referenced only could have uncovered a latent problem. mem-ssa might simply have hidden it again. The reduced testcase doesn't link for me btw: /tmp/ccGXFf9y.o: In function `A::bar()': 589.ii:(.text+0x2c): undefined reference to `sigc::slot_base::slot_base(sigc::internal::slot_rep*)' collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug target/30255] register spills in x87 unit need to be 80-bit, not 64
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-12-27 16:21 --- Just to mention it - you can use 'long double' to force 80bit spills. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255
[Bug fortran/20896] [4.2 and 4.1 only] ambiguous interface not detected
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-27 16:38 --- I suppose that I had better accept it... Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-31 19:56:44 |2006-12-27 16:38:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20896
[Bug middle-end/30267] folding (~ -x) = (-2147483647-1) to x != -2147483648
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-27 16:48 ---
This is folded to
;; Function notneg (notneg)
;; enabled by -tree-original
{
return x != -2147483648;
}
;; Function negnot (negnot)
;; enabled by -tree-original
{
return x != 2147483647;
}
via
/* Convert - (~A) to A + 1. */
if (INTEGRAL_TYPE_P (type) TREE_CODE (arg0) == BIT_NOT_EXPR)
return fold_build2 (PLUS_EXPR, type, TREE_OPERAND (arg0, 0),
build_int_cst (type, 1));
and
/* Convert ~ (-A) to A - 1. */
else if (INTEGRAL_TYPE_P (type) TREE_CODE (arg0) == NEGATE_EXPR)
return fold_build2 (MINUS_EXPR, type, TREE_OPERAND (arg0, 0),
build_int_cst (type, 1));
and
/* Transform comparisons of the form X +- C1 CMP C2 to X CMP C2 +- C1.
*/ if ((TREE_CODE (arg0) == PLUS_EXPR || TREE_CODE (arg0) == MINUS_EXPR)
(TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST
!TREE_OVERFLOW (TREE_OPERAND (arg0, 1))
!TYPE_UNSIGNED (TREE_TYPE (arg1))
!(flag_wrapv || flag_trapv))
(TREE_CODE (arg1) == INTEGER_CST
!TREE_OVERFLOW (arg1)))
{
tree const1 = TREE_OPERAND (arg0, 1);
tree const2 = arg1;
tree variable = TREE_OPERAND (arg0, 0);
tree lhs;
int lhs_add;
lhs_add = TREE_CODE (arg0) != PLUS_EXPR;
lhs = fold_build2 (lhs_add ? PLUS_EXPR : MINUS_EXPR,
TREE_TYPE (arg1), const2, const1);
if (TREE_CODE (lhs) == TREE_CODE (arg1)
(TREE_CODE (lhs) != INTEGER_CST
|| !TREE_OVERFLOW (lhs)))
return fold_build2 (code, type, variable, lhs);
}
(citing from the 4.1 branch)
Note this is actually wrong-code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Known to fail||4.1.2 4.3.0
Known to work||4.0.3
Last reconfirmed|-00-00 00:00:00 |2006-12-27 16:48:37
date||
Summary|missed optimization due to |folding (~ -x) = (-
|bad range propagation |2147483647-1) to x != -
|without -fwrapv |2147483648
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30267
[Bug middle-end/30267] folding (~ -x) = (-2147483647-1) to x != -2147483648
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-27 17:01 --- (In reply to comment #1) Note this is actually wrong-code. No, it is not. In notneg, if x is -2147483647-1, it is obviously, we have an overflow as -(-2147483647-1) is overflowed. In negnot, if x is 2147483647, then ~ 2147483647 == -2147483647-1, and then we have an overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30267
[Bug fortran/30034] pure subroutine requires intent for procedure argument
--- Comment #2 from patchapp at dberlin dot org 2006-12-27 19:35 --- Subject: Bug number PR30034 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/2006-12/msg01730.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30034
[Bug tree-optimization/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #5 from belyshev at depni dot sinp dot msu dot ru 2006-12-27 20:19 --- (In reply to comment #4) The reduced testcase doesn't link for me btw: sorry, forgot to mention: both tests require -lsigc-2.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug preprocessor/29966] crash in cc1 with backtrace from free()
--- Comment #8 from tromey at gcc dot gnu dot org 2006-12-27 21:43 --- I looked at this a bit. The basic problem resembles bug #14438 in a way. The source code here has an unterminated call to a function-like macro. cpp thinks all the subsequent #define directives are in the expansion (try -pedantic to see the errors). I believe what happens is that during a call to create_iso_definition, we call _cpp_lex_token at a point where it must allocate a new token run. But then upon returning we restore the old cur_token pointer (see _cpp_create_definition), leading to the bug. I'm testing a fix which works by saving and restoring cur_token in lex_expansion_token. I'm not positive this is correct, though. Another possible fix might be to change create_iso_definition to call _cpp_lex_direct rather than _cpp_lex_token. BTW, my reading of _cpp_lex_token is that it assumes that cur_token is in the current token run. One easy way to make gdb stop when the first bug is hit is to make a breakpoint conditional on this not being true. For debugging I added an assert() for this, but cpp doesn't seem to use assertions anywhere, so I won't be submitting this. -- 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 |2006-12-27 21:43:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
[Bug debug/26964] Duplicate debug info for enums in namespaces
--- Comment #2 from ian at gcc dot gnu dot org 2006-12-27 21:48 --- Subject: Bug 26964 Author: ian Date: Wed Dec 27 21:48:05 2006 New Revision: 120221 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120221 Log: PR debug/26964 * dwarf2out.c (gen_type_die): Don't write out a DIE for ENUMERAL_TYPE if it was already written out. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26964
[Bug c/26567] ICE in c_lex_with_flags, at c-lex.c:472 with cc1 -C (without -E)
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-27 22:08 --- FWIW this doesn't entirely look like a bug to me. The code is reaching a gcc_unreachable() statement, so this is more along the lines of a properly functioning internal check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26567
[Bug c/26567] ICE in c_lex_with_flags, at c-lex.c:472 with cc1 -C (without -E)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-27 22:14 --- (In reply to comment #3) FWIW this doesn't entirely look like a bug to me. The code is reaching a gcc_unreachable() statement, so this is more along the lines of a properly functioning internal check. But we should really have it error out instead of an ICE really. It is only a bug because we get an ICE, if we got an error or ignored the -C, then this would not be a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26567
[Bug debug/26964] Duplicate debug info for enums in namespaces
--- Comment #3 from ian at gcc dot gnu dot org 2006-12-27 22:22 --- Subject: Bug 26964 Author: ian Date: Wed Dec 27 22:22:47 2006 New Revision: 120222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120222 Log: PR debug/26964 * dwarf2out.c (gen_type_die): Don't write out a DIE for ENUMERAL_TYPE if it was already written out. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26964
[Bug debug/26964] Duplicate debug info for enums in namespaces
--- Comment #4 from ian at gcc dot gnu dot org 2006-12-27 22:24 --- Subject: Bug 26964 Author: ian Date: Wed Dec 27 22:23:55 2006 New Revision: 120223 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120223 Log: PR debug/26964 * dwarf2out.c (gen_type_die): Don't write out a DIE for ENUMERAL_TYPE if it was already written out. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26964
[Bug debug/26964] Duplicate debug info for enums in namespaces
--- Comment #5 from ian at airs dot com 2006-12-27 22:54 --- Fixed on active branches. -- ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26964
[Bug debug/26964] Duplicate debug info for enums in namespaces
--- Comment #6 from ian at gcc dot gnu dot org 2006-12-27 23:40 --- Subject: Bug 26964 Author: ian Date: Wed Dec 27 23:39:58 2006 New Revision: 120225 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120225 Log: PR debug/26964 * dwarf2out.c (gen_type_die): Don't write out a DIE for ENUMERAL_TYPE if it was already written out. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26964
[Bug regression/30311] New: Gcc 4.3 revision 120211 failed to compile perlbench
[EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.3/bin/gcc foo.i -O2 -S foo.c: In function Perl_pp_int: foo.c:60: internal compiler error: in subreg_get_info, at rtlanal.c:3065 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.3/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.3 --with-local-prefix=/usr/local Thread model: posix gcc version 4.3.0 20061226 (experimental) [trunk revision 120211] -- Summary: Gcc 4.3 revision 120211 failed to compile perlbench Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30311
[Bug regression/30311] Gcc 4.3 revision 120211 failed to compile perlbench
--- Comment #1 from hjl at lucon dot org 2006-12-28 00:11 --- Created an attachment (id=12844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12844action=view) A testcase A testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30311
[Bug bootstrap/30312] New: [4.3 regression] ICE in voidify_wrapper_expr, at gimplify.c:1015
This is actually a bootstrap failure on i386-unknown-freebsd5.4, but with
some work I managed to destill this radically.
When invoking `${BUILDDIR}/gcc/xgcc -B${BUILDDIR}/gcc -O1 x.cc` on
#define f(x) ({ unsigned tmp=x; tmp; })
unsigned foo(unsigned x) {
return __builtin_constant_p(x) ? 0 : f(x);
}
I, and several other FreeBSD committers, get
x.cc: In function 'unsigned int foo(unsigned int)':
x.cc:6: internal compiler error: in voidify_wrapper_expr, at gimplify.c:1015
This regression was introduced between 23:03 GMT +0200 on December 4th and
the same time on December 5th 2006.
--
Summary: [4.3 regression] ICE in voidify_wrapper_expr, at
gimplify.c:1015
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
GCC host triplet: i386-unknown-freebsd5.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30312
[Bug preprocessor/20077] [4.0/4.1/4.2/4.3 Regression] GCC accepts macro definitions that fail a constraint
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-28 00:59 --- The followup patch here: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00868.html .. looked reasonable to me (although the ChangeLog entry is overly verbose). However I can't approve it. -- 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=20077
[Bug bootstrap/30312] [4.3 regression] ICE in voidify_wrapper_expr, at gimplify.c:1015
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-28 01:10 --- The patch I have for PR 30253 also fixes this issue. *** This bug has been marked as a duplicate of 30253 *** -- 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=30312
[Bug middle-end/30253] [4.3 Regression] ICE with statement expression inside a conditional
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-12-28 01:10 --- *** Bug 30312 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gerald at pfeifer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30253
[Bug middle-end/30253] [4.3 Regression] ICE with statement expression inside a conditional
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-28 01:11 ---
Another Testcase (simplier):
#define f(x) ({ unsigned tmp=x; tmp; })
unsigned foo(unsigned x) {
return __builtin_constant_p(x) ? 0 : f(x);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30253
[Bug middle-end/30311] [4.3 regression] revision 120211 failed to compile perlbench
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-12-28 01:14
---
Reduced testcase, fails with -O or higher:
=
inline double bar(double x)
{
long double d;
__asm__ ( : =t (d) : 0 (x));
return d;
}
double foo(double x)
{
if (x)
return bar(x);
else
return bar(x);
}
=
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-12-28 01:14:50
date||
Summary|Gcc 4.3 revision 120211 |[4.3 regression] revision
|failed to compile perlbench |120211 failed to compile
||perlbench
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30311
[Bug preprocessor/28227] valid #ifdef rejected
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-28 01:28 --- Also 6.10.8.4 says that various other macros, like __DATE__, shall not be the subject of #define or #undef. Currently we warn in these cases but perhaps we ought to have a pedwarn instead. I have a patch for the '#ifdef defined' case which I am testing. Also I note that '#if defined defined' is undefined. I wonder if we ought to warn for this. -- 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 |2006-12-28 01:28:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28227
[Bug preprocessor/19753] different LANG settings and ccache don't work together
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-28 01:34 --- This seems reasonable enough to me, offhand. I suppose built-in and command line are translated because they may be visible as part of error reporting, but this doesn't seem super compelling to me. I think the fix for this is a couple of minor changes in gcc/c-opts.c. I will submit it a bit later to see what other gcc developers think. -- 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 |2006-12-28 01:34:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19753
[Bug pch/13676] GCC failes to recognize files ending in .hpp as headers to be precompiled
--- Comment #10 from tromey at gcc dot gnu dot org 2006-12-28 01:38 --- Is this patch just waiting for someone to commit it? The paperwork is all done? If so please respond and I will check it in. -- 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=13676
[Bug translation/29796] I18N (german): virtual outside class declaration incorrectly translated
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-12-28 01:39 --- I can reproduce the problem with the following code snippet: = virtual void foo(); = Fehler in der deutschen Übersetzung sind an [EMAIL PROTECTED] zu melden. This is printed if the compiler crashes, so you should to try your luck there. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-28 01:39:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29796
[Bug libfortran/30014] INQUIRE (iolength = xx) limited to kind=4
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-12-28 01:39 --- Subject: Bug 30014 Author: jvdelisle Date: Thu Dec 28 01:39:15 2006 New Revision: 120233 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120233 Log: 2006-12-27 Jerry DeLisle [EMAIL PROTECTED] PR fortran/30014 *io.c (resolve_tag): Don't issue error for tag_size type not being default integer size for -std=F2003. Add similar check for tag_iolength. *ioparm.def: Change size and iolength parameters to ioint pointer, which corresponds to GFC_IO_INT on the library side. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/fortran/ioparm.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30014
[Bug libfortran/30014] INQUIRE (iolength = xx) limited to kind=4
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-12-28 01:40 --- Subject: Bug 30014 Author: jvdelisle Date: Thu Dec 28 01:40:23 2006 New Revision: 120234 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120234 Log: 2006-12-27 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/30014 *io/io.h (st_parameter_dt): Change *size and *iolength type to GFC_IO_INT. *io/transfer.c (finalize_transfer): Cast dtp-u.p.size_used to GFC_IO_INT. (iolength_transfer): Cast size * nelems to GFC_IO_INT. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30014
[Bug libfortran/30014] INQUIRE (iolength = xx) limited to kind=4
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-12-28 01:42 --- Subject: Bug 30014 Author: jvdelisle Date: Thu Dec 28 01:41:57 2006 New Revision: 120235 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120235 Log: 2006-12-27 Jerry DeLisle [EMAIL PROTECTED] PR fortran/30014 * gfortran.dg/io_constraints_1.f90: Update test. * gfortran.dg/io_constraints_2.f90: Update test. * gfortran.dg/inquire_iolength.f90: Ne test. Added: trunk/gcc/testsuite/gfortran.dg/inquire_iolength.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/io_constraints_1.f90 trunk/gcc/testsuite/gfortran.dg/io_constraints_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30014
[Bug translation/29796] I18N (german): virtual outside class declaration incorrectly translated
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-28 01:42 --- http://gcc.gnu.org/translation.html http://www.iro.umontreal.ca/translation/ We cannot fix this at all. report it to the german translation maintainer for GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29796
[Bug middle-end/30311] [4.3 regression] revision 120211 failed to compile perlbench
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-28 01:44 --- Hmm, I don't know this is really valid code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30311
[Bug c/30313] New: sizeof of expression including bit-field
gcc rejects following valid code.
static inline void bar(){}
struct S
{
signed int i: 32;
};
int main()
{
struct S x = {32};
sizeof(x.i+0);
return 0;
}
gcc version: 4.2 20061212
--
Summary: sizeof of expression including bit-field
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
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 #1 from pinskia at gcc dot gnu dot org 2006-12-28 03:05 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2006-12-28 03:05:44 date|| Summary|sizeof of expression|[4.1/4.2/4.3 Regression] |including bit-field |sizeof of expression ||including bit-field Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30313
[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-28 04:22 --- FWIW what happens here is that 'foo;' is turned into '- ;' by cpp; then the second error is emitted by the C parser. You can easily see this by comparing the -E output against the --syntax-only output. The problem here is that paste_tokens backs up over the '' token, but it leaves the half-pasted '-' token in *plhs. I have a fix that I'm testing. -- 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=28709
[Bug preprocessor/14460] --enable-c-mbchar will not work
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-28 04:49 --- This is a bug against a very old release for code that no longer exists. Is it ok to give up and close it as invalid? The bug management page is not clear on when old bugs can be closed; I think this one should be because 3.3 is (afaik) not maintained any longer. -- 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=14460
[Bug libfortran/30308] [4.1,4.2,4.3] open_errors.f90 fails on cygwin
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-28 05:28:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30308
[Bug tree-optimization/30314] New: optimize multiply-by-constant overflow (wrap) test
I was experimenting with some code to test for overflow (wrapping) in unsigned
multiplication in C. My test code:
typedef unsigned long size_t;
extern void *malloc(size_t), abort(void);
void *allocate(size_t num) {
const size_t size = 140;
size_t total = num * size;
if (total / size != num) abort();
/* call malloc, whatever */
return 0;
}
With snapshot gcc-4.3-20061223, hosted on ppc Mac, targeted for i386-linux,
options -O9 -fomit-frame-pointer -fexpensive-optimizations -S, the generated
assembly code is:
allocate:
subl$12, %esp
movl16(%esp), %ecx
leal(%ecx,%ecx,4), %eax
leal0(,%eax,8), %edx
subl%eax, %edx
andl$1073741823, %edx
movl$981706811, %eax
mull%edx
shrl$3, %edx
cmpl%ecx, %edx
jne .L6
xorl%eax, %eax
addl$12, %esp
ret
.L6:
callabort
In this assembly code, the division has been implemented via multiplication,
and the result is compared against the original value.
Dividing 2**32-1 by 140 gives 30678337 and a fraction. If the supplied NUM is
larger than that, it can't be equal to the quotient of any 32-bit number
divided by 140. If it's 30678337 or less, the multiplication can't wrap, and
thus the quotient must be equal to the original value.
Since the quotient, as such, isn't of any other use in this code, I think it
would be more efficient, and give the same result, to test NUM=30678337, and
omit the division altogether. (And since the malloc call in the comment isn't
actually made in this example, the product stored in TOTAL isn't needed either,
if we don't do the division.)
I think on x86 we could also test the carry flag after the multiply operation.
--
Summary: optimize multiply-by-constant overflow (wrap) test
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raeburn at raeburn dot org
GCC build triplet: powerpc-apple-darwin
GCC host triplet: powerpc-apple-darwin
GCC target triplet: i386-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30314
[Bug target/30315] New: optimize unsigned-add overflow test on x86 to use cpu flags from addl
Using gcc-4.3-20061223 targeting i386-linux and options -O9
-fomit-frame-pointer -fexpensive-optimizations -S, my test program to detect
unsigned integer overflow:
extern void abort(void);
unsigned foo(unsigned a, unsigned b) {
unsigned sum = a + b;
if (sum a) abort(); /* check for overflow (wrapping) */
if (sum b) abort(); /* redundant */
return sum;
}
compiles to:
foo:
subl$12, %esp
movl16(%esp), %eax
movl20(%esp), %edx
addl%eax, %edx
cmpl%edx, %eax
ja .L7
cmpl%edx, 20(%esp)
ja .L7
movl%edx, %eax
addl$12, %esp
ret
.L7:
callabort
After the addition, which sets the ALU flags, the compiler issues two compare
instructions and conditional branches. This sequence could be replaced by a
conditional branch following the addl, testing one of the flags (overflow?
carry? I forget which) set by it.
I realize for other processors (e.g., with -march=pentiumpro), the addl may be
replaced by something like leal, which may not set the flags the same way. But
if the flags are set when building for a certain architecture, use them
And is leal+cmp with data dependence still going to be better than addl?
(Also, I think a different set of register selections could eliminate the last
movl instruction, by putting the result of the addition into the return-value
register.)
--
Summary: optimize unsigned-add overflow test on x86 to use cpu
flags from addl
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raeburn at raeburn dot org
GCC build triplet: powerpc-apple-darwin
GCC host triplet: powerpc-apple-darwin
GCC target triplet: i386-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug c++/30316] New: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434
O.k sorry about the bad summary (I know almost nothing about c++). I had installed 4.2.0 pre-release for my fortran needs and was trying to compile a package (beast-0.7.1, from beast.gtk.org) on fedora rawhide and I'm getting this ICE; if g++ -DHAVE_CONFIG_H -DBIRNET_LOG_DOMAIN='signal' -DPARANOID -DG_DISABLE_CONST_RETURNS -I. -I. -I../.. -I../.. -I../.. -I. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -D_BIRNET_SOURCE_EXTENSIONS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -g -DG_ENABLE_DEBUG -Wdeprecated -Wno-cast-qual -ftracer -finline-functions -fno-keep-static-consts -fmessage-length=80 -MT signal.o -MD -MP -MF .deps/signal.Tpo -c -o signal.o signal.cc; \ then mv -f .deps/signal.Tpo .deps/signal.Po; else rm -f .deps/signal.Tpo; exit 1; fi ./birnetsignalslot.hh: In function 'Birnet::Signals::Slot3R0, A1, A2, A3, void Birnet::Signals::slot(Class, R0 (Class::*)(A1, A2, A3)) [with Class = unnamed::Connection3, R0 = void, A1 = int, A2 = Birnet::String, A3 = float]': ./birnetsignalslot.hh:126: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [signal.o] Error 1 I did try to run 'cpp -DHAVE_CONFIG_H -DBIRNET_LOG_DOMAIN='datalist' -DPARANOID -DG_DISABLE_CONST_RETURNS -I. -I. -I../.. -I../.. -I../.. -I. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -D_BIRNET_SOURCE_EXTENSIONS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -g -DG_ENABLE_DEBUG -Wdeprecated -Wno-cast-qual -ftracer -finline-functions -fno-keep-static-consts -fmessage-length=80 -MT datalist.o -MD -MP -MF .deps/datalist.Tpo datalist.cc datalist.cpp', the output is attached. [EMAIL PROTECTED] tests]$ g++ --version g++ (GCC) 4.2.0 20061225 (prerelease) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: internal compiler error: in set_lattice_value, at tree- ssa-ccp.c:434 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: deji_aking at yahoo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30316
[Bug c++/30316] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434
--- Comment #1 from deji_aking at yahoo dot ca 2006-12-28 07:26 --- The pre-processed is too big to attach, I've put it on ftp://czar.eas.yorku.ca/pub/datalist.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30316
