[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From pluto at agmk dot net 2005-06-25 06:26 --- (In reply to comment #7) > (in reply to comment #6) > > This is a known problem, with a hack to mode-switching.c at > http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01434.html. > > Please, could you try to apply the mode-switching.c part of the patch > and see if it fix an ice for you. with this hack bootstrap still ices. ../../gcc/unwind.inc: In function '_Unwind_ForcedUnwind': ../../gcc/unwind.inc:215: internal compiler error: in create_pre_exit, at mode-switching.c:362 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-06-25 02:49 --- Ivopts seem to do several quite doubtful decisions in this testcase. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug c++/20789] [4.0 regression] ICE with incomplete type in template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 02:07 --- *** Bug 22181 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||micha at lrde dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789
[Bug c++/22181] Segv on undefined static member of a template class.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 02:07 --- *** This bug has been marked as a duplicate of 20789 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22181
[Bug c++/22181] New: Segv on undefined static member of a template class.
This code doesn't compile on both GCC 3.4.3 and GCC 4.1.0 (20050320).
-- begin .ii file
# 1 "bug_gcc.cc"
# 1 ""
# 1 ""
# 1 "bug_gcc.cc"
template
struct List
{
static const int Value = N;
typedef Tail_ Tail;
};
struct NullList;
template < bool B, int T, int F >
struct If_
{ static const int res = T; };
template < int T, int F >
struct If_< false, T, F >
{ static const int res = F; };
template < class List >
struct GreatestSub
{
private:
static const int N = List::Value;
static const int current = (If_<(N > 0), (N), (0)>::ret);
static const bool is_max = (current > 0);
static const int max_value = (If_<(is_max), (0), (0)>::ret);
};
template <>
struct GreatestSub
{};
int main()
{
GreatestSub< List<50, NullList> >::current;
}
-- end .ii file
-- begin version infos
sh-3.00$ g++ bug_gcc.cc -W -Wall
bug_gcc.cc: In instantiation of `GreatestSub >':
bug_gcc.cc:36: instantiated from here
bug_gcc.cc:25: error: `ret' is not a member of `If_< true, 50, 0>'
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://bugs.gentoo.org/> for instructions.
sh-3.00$ g++ --version
g++ (GCC) 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110-r2, ssp-3.4.3.20050110-0,
pie-8.7.7)
Copyright (C) 2004 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.
sh-3.00$ g++-snapshot bug_gcc.cc
bug_gcc.cc: In instantiation of 'GreatestSub >':
bug_gcc.cc:36: instantiated from here
bug_gcc.cc:25: error: 'ret' is not a member of 'If_'
g++-snapshot: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
sh-3.00$ g++-snapshot --version
g++-snapshot (GCC) 4.1.0 20050320 (experimental)
Copyright (C) 2005 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.
-- end version infos
gentoo configuration of gcc package options:
(-altivec) -bootstrap -boundschecking -build +fortran -gcj +gtk -hardened -ip28
(-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -static
--
Summary: Segv on undefined static member of a template class.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micha at lrde dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: Linux mahaena 2.6.11-gentoo-r6 #2 SMP Sat Apr 30
02:17:43 CEST 2
GCC host triplet: Linux mahaena 2.6.11-gentoo-r6 #2 SMP Sat Apr 30
02:17:43 CEST 2
GCC target triplet: Linux mahaena 2.6.11-gentoo-r6 #2 SMP Sat Apr 30
02:17:43 CEST 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22181
[Bug c++/22180] New: [3.4/4.0/4.1 regression] ICE on invalid destructor call
Since GCC 3.4.0 we get an ICE for the following code snippet.
Before we correctly issued an error message.
===
struct A {};
template void foo()
{
T::~T();
}
template void foo();
===
bug.cc: In function 'void foo() [with T = A]':
bug.cc:8: instantiated from here
bug.cc:5: internal compiler error: in lookup_member, at cp/search.c:1200
Please submit a full bug report, [etc.]
--
Summary: [3.4/4.0/4.1 regression] ICE on invalid destructor call
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22180
[Bug middle-end/17308] nonnull attribute not as useful as it could
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 23:13 --- *** Bug 22179 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jesse dot millan at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
[Bug c/22179] Erroneous compiler warning: null argument where non-null required
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 23:13 --- This is basicially PR 17308. *** This bug has been marked as a duplicate of 17308 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22179
[Bug fortran/21915] Would like atanh etc. as intrinsics
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-24 23:12 --- Subject: Bug 21915 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-24 23:12:32 Modified files: gcc/fortran: ChangeLog gfortran.h intrinsic.c intrinsic.h iresolve.c mathbuiltins.def simplify.c Log message: 2005-06-24 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/21915 * gfortran.h: Add symbols for new intrinsics * intrinsic.c: Add acosh, asinh, and atanh * intrinsic.h: Add prototypes * iresolve.c (gfc_resolve_acosh): New function (gfc_resolve_asinh): New (gfc_resolve_atanh): New * mathbuiltins.def: Add defines * simplify.c (gfc_simplify_acosh): New function (gfc_simplify_asinh): New (gfc_simplify_atanh): New Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.472&r2=1.473 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.71&r2=1.72 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/intrinsic.c.diff?cvsroot=gcc&r1=1.49&r2=1.50 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/intrinsic.h.diff?cvsroot=gcc&r1=1.29&r2=1.30 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/iresolve.c.diff?cvsroot=gcc&r1=1.34&r2=1.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/mathbuiltins.def.diff?cvsroot=gcc&r1=1.3&r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/simplify.c.diff?cvsroot=gcc&r1=1.27&r2=1.28 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21915
[Bug fortran/21915] Would like atanh etc. as intrinsics
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-24 23:10 --- Subject: Bug 21915 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-24 23:09:49 Added files: libgfortran/intrinsics: hyper.c Log message: 2005-06-24 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/21915 * intrinsics/hyper.c: New file, adds wrapper functions Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/hyper.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21915
[Bug middle-end/12963] Wrong and misleading warning encourages writing non-portable code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 23:10 --- *** Bug 22178 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||eggert at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
[Bug c/22178] bogus warning "comparison is always false due to limited range"
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 23:10 --- *** This bug has been marked as a duplicate of 12963 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22178
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Additional Comments From joseph at codesourcery dot com 2005-06-24 23:09 --- Subject: Re: #if #A == #B should have a diagnostic in ISO C mode On Fri, 24 Jun 2005, neil at gcc dot gnu dot org wrote: > My copy of the standard only requires a constant expression - can you point > out > where you read its requiring an integer constant expression? 6.10.1#1, "shall be an integer constant expression"; 6.8.1 in C90. > The standard explicitly permits extensions to constant expressions. Since > this But not to integer constant expressions (at least according to the view expressed in the DR#312 discussion in the draft Lillehammer minutes, although DR#032 implies a different view). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug fortran/21915] Would like atanh etc. as intrinsics
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-24 23:07 --- Subject: Bug 21915 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-24 23:07:15 Modified files: libgfortran: ChangeLog Makefile.am Makefile.in aclocal.m4 c99_protos.h config.h.in configure configure.ac Log message: 2005-06-24 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/21915 * Makefile.am: include intrinsics/hyper.c * c99_protos.h: add prototypes for single precision versions of acosh, asinh, and atanh for platforms that do not have these * config.h.in: add #undef for wrappers * configure.ac: add checks for single precision versions * aclocal.m4: generated * Makefile.in: generated * configure: generated Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.248&r2=1.249 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.am.diff?cvsroot=gcc&r1=1.37&r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.in.diff?cvsroot=gcc&r1=1.39&r2=1.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/aclocal.m4.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/c99_protos.h.diff?cvsroot=gcc&r1=1.5&r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/config.h.in.diff?cvsroot=gcc&r1=1.21&r2=1.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.diff?cvsroot=gcc&r1=1.39&r2=1.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.ac.diff?cvsroot=gcc&r1=1.29&r2=1.30 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21915
[Bug c/22179] Erroneous compiler warning: null argument where non-null required
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 23:06 --- This is because we don't use flow control for this warning at all and this warning is done in the front- end instead of the middle-end where we have flow control. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22179
[Bug c/22178] bogus warning "comparison is always false due to limited range"
--- Additional Comments From joseph at codesourcery dot com 2005-06-24 23:04 --- Subject: Re: New: bogus warning "comparison is always false due to limited range" On Fri, 24 Jun 2005, eggert at gnu dot org wrote: > Logically, the troublesome warnings fall into the same category as > these unsigned-expressions warnings, so they should be enabled only if > the unsigned-expression warnings are enabled: i.e., only when -Wextra > is specified and we are not in a system header. (a) This is bug 12963. (b) in_system_header checks are generally not needed, warnings in system headers are disabled by default. (c) A separate well-defined option, -Wcomparison-fixed (enabled by -Wextra) for all these warnings, is better than just putting more in -Wextra. Thus, the relevant warnings should have the "(0," changed to "(OPT_Wcomparison_fixed," rather than having explicit checks on the warning flag variable, which helps the aim to remove all warnings with "0" rather than a warning number. In general, passing warning number enumerations to "warning" is always better than explicit flag checks unless the conditions for the warning are expensive to check. (d) Patches changing warnings need testcases (in this case covering all the relevant warnings and testing they no longer appear if no special options are passed but do appear if -Wextra or any new option is passed). (e) The list of warnings in -Wextra is documented, so if a warning is added to that list the documentation of -Wextra needs to be updated (with a reference to any separate option for these warnings). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22178
[Bug c/22179] Erroneous compiler warning: null argument where non-null required
--- Additional Comments From jesse dot millan at gmail dot com 2005-06-24 22:49 --- Created an attachment (id=9146) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9146&action=view) The C file that will generate the warning. (-Wall required) Null is explicity checked for before making the function call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22179
[Bug c/22179] Erroneous compiler warning: null argument where non-null required
-- What|Removed |Added CC||jesse dot millan at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22179
[Bug c/22179] Erroneous compiler warning: null argument where non-null required
--- Additional Comments From jesse dot millan at gmail dot com 2005-06-24 22:50 --- Created an attachment (id=9147) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9147&action=view) Preprocessed version of the example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22179
[Bug c/22179] New: Erroneous compiler warning: null argument where non-null required
Even if Null is explicitly checked for, the compiler still gives the warning. -- Summary: Erroneous compiler warning: null argument where non-null required Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jesse dot millan at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22179
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Additional Comments From schwab at suse dot de 2005-06-24 22:41 --- The standard does not allow to extend the syntax. Since this violates the syntax of the language a diagnostic is required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug c/22178] New: bogus warning "comparison is always false due to limited range"
Maintainers of GNU packages that use gnulib are now starting to see
bug reports coming in from installers using GCC 4.0.0 on 64-bit
platforms. GCC is issuing an incorrect warning about valid code, but
installers don't necessarily know the code is valid, so they are
worried about it.
This is a regression, since GCC 3.x did not issue these warnings. (I
just checked this, with GCC 3.2.3.) I presume that the new warnings
occur because GCC 4.x is "smarter" about detecting the situation.
Example logs containing the bogus warnings can be found here (look for
"quotearg"):
http://lists.gnu.org/archive/html/bug-gnulib/2005-06/msg00076.html
http://josefsson.org/autobuild-logs/base64-1.1-192.233.54.149-output.html
http://hood.oook.cz/tb/logs/5-amd64-FreeBSD/gettext-0.14.4_1.log
Here is a small program that illustrates the problem. Compile this
for a 64-bit platform (where size_t is 64 bits and int is 32 bits).
I used "gcc -c -m64 t.c" on Solaris 8 sparc.
/* Return 1 if an array of N objects, each of size S, cannot exist due
to size arithmetic overflow. S must be positive and N must be
nonnegative. This is a macro, not an inline function, so that it
works correctly even when SIZE_MAX < N.
By gnulib convention, SIZE_MAX represents overflow in size
calculations, so the conservative dividend to use here is
SIZE_MAX - 1, since SIZE_MAX might represent an overflowed value.
However, malloc (SIZE_MAX) fails on all known hosts where
sizeof (ptrdiff_t) <= sizeof (size_t), so do not bother to test for
exactly-SIZE_MAX allocations on such hosts; this avoids a test and
branch when S is known to be 1. */
# define xalloc_oversized(n, s) \
((size_t) (sizeof (ptrdiff_t) <= sizeof (size_t) ? -1 : -2) / (s) < (n))
#include
int
too_large (unsigned int n)
{
return xalloc_oversized (n, sizeof (double));
}
GCC 4.0.0 issues a diagnostic like this:
$ gcc --version | sed 1q
gcc (GCC) 4.0.0
$ gcc -c -m64 t.c
t.c: In function 'too_large':
t.c:21: warning: comparison is always false due to limited range of data type
This warning is bogus, because the whole point of the xalloc_oversized
macro is to avoid a run-time comparison when possible. In effect, GCC
4.0.0 is warning the user that it is smart enough to generate better
code. I see no easy way to modify the code to work around the warning
(other than by making the code less efficient).
Looking at the GCC 4.x source code, it appears that other, similar
warnings are all enabled only if -Wextra is specified. These include:
comparison of unsigned expression >= 0 is always true
comparison of unsigned expression < 0 is always false
These warnings are similar because they also are comparisons that
return false (or true) due to the limited range of the data type.
Logically, the troublesome warnings fall into the same category as
these unsigned-expressions warnings, so they should be enabled only if
the unsigned-expression warnings are enabled: i.e., only when -Wextra
is specified and we are not in a system header.
Here is a proposed patch, against GCC sources I checked out today.
2005-06-24 Paul Eggert <[EMAIL PROTECTED]>
* c-common.c (shorten_compare): Unless -Wextra is used,
do not warn against comparisons always being false due to
limited range of data type. Such comparisons can occur
in real-world portable code dealing with system types
like size_t.
--- c-common.c.~1.636.~ 2005-06-24 14:37:22.0 -0700
+++ c-common.c 2005-06-24 14:37:38.380239000 -0700
@@ -2117,7 +2117,8 @@ shorten_compare (tree *op0_ptr, tree *op
type = c_common_unsigned_type (type);
}
- if (TREE_CODE (primop0) != INTEGER_CST)
+ if (extra_warnings && !in_system_header
+ && TREE_CODE (primop0) != INTEGER_CST)
{
if (val == truthvalue_false_node)
warning (0, "comparison is always false due to limited range of
data type");
--
Summary: bogus warning "comparison is always false due to limited
range"
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eggert at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.10
GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22178
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-24 22:26:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Additional Comments From neil at gcc dot gnu dot org 2005-06-24 22:24 --- (In reply to comment #6) > Yup, it's documented. However, it's still silently accepted even with -pedantic, and the language doesn't > permit that. My copy of the standard only requires a constant expression - can you point out where you read its requiring an integer constant expression? The standard explicitly permits extensions to constant expressions. Since this extension is explicitly documented as for use in #if expressions, it should be obvious that we intend #foo as a constant expression. No diagnostic is therefore required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug middle-end/22177] error: in assign_stack_temp_for_type, at function.c:655
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 22:04 --- Could you add -save-temps to the command line which is compiling the file and attach the preprocessed source? Also could you supply how you run gcc? -- What|Removed |Added Component|c |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22177
[Bug c/22177] New: error: in assign_stack_temp_for_type, at function.c:655
this bug occured when compiling the mplayer, file dsputil.c:3243.
here is the compiler report:
dsputil.c:3243: internal compiler error: in assign_stack_temp_for_type, at
function.c:655
the compiling code segment is:
3237 static int rd8x8_c(/*MpegEncContext*/ void *c, uint8_t *src1, uint8_t
*src2, int stride, int h){
3238 MpegEncContext * const s= (MpegEncContext *)c;
3239 const uint8_t *scantable= s->intra_scantable.permutated;
3240 uint64_t __align8 aligned_temp[sizeof(DCTELEM)*64/8];
3241 uint64_t __align8 aligned_bak[stride];
3242 DCTELEM * const temp= (DCTELEM*)aligned_temp;
3243 uint8_t * const bak= (uint8_t*)aligned_bak;
3244 int i, last, run, bits, level, distoration, start_i;
3245 const int esc_length= s->ac_esc_length;
3246 uint8_t * length;
3247 uint8_t * last_length;
--
Summary: error: in assign_stack_temp_for_type, at function.c:655
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zhr_buaa at 263 dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-linux-gcc
GCC target triplet: arm-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22177
[Bug java/13788] Zero propogate right shift in static final int initializer causes error
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-24 21:49 --- FWIW I agree with the analysis. This is related to PR 21540, but not the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13788
[Bug libgcj/10421] java.text.Collator.getInstance returns null for "de" locale
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-24 21:38 --- I'm not sure when this was fixed, but it works in 4.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10421
[Bug libgcj/6996] gij needs assertion-related command-line options
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-24 21:36 --- The patch was obsoleted by other changes. I don't think I have a copy of it any more. I'm throwing this PR back into the pool for now. -- What|Removed |Added AssignedTo|tromey at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6996
[Bug testsuite/22176] New: error executing dg-final: no files matched glob pattern "*.c.t??.dom*"
The following apparently cross-platform ERRORs (and corresponding UNRESOLVEDs) have appeared on mainline on 20050624 (between 20050623 07:00 UTC and 20050624 07:00 UTC). ERROR: gcc.dg/tree-ssa/20030708-1.c: error executing dg-final: no files matched glob pattern "20030708-1.c.t??.dom3" ERROR: gcc.dg/tree-ssa/20030709-1.c: error executing dg-final: no files matched glob pattern "20030709-1.c.t??.optimized" ERROR: gcc.dg/tree-ssa/20030714-1.c: error executing dg-final: no files matched glob pattern "20030714-1.c.t??.dom3" ERROR: gcc.dg/tree-ssa/20030807-1.c: error executing dg-final: no files matched glob pattern "20030807-1.c.t??.dom3" ERROR: gcc.dg/tree-ssa/20030807-5.c: error executing dg-final: no files matched glob pattern "20030807-5.c.t??.dom3" ERROR: gcc.dg/tree-ssa/20030807-8.c: error executing dg-final: no files matched glob pattern "20030807-8.c.t??.dom3" ERROR: gcc.dg/tree-ssa/20030815-1.c: error executing dg-final: no files matched glob pattern "20030815-1.c.t??.dom3" ERROR: gcc.dg/tree-ssa/20030922-2.c: error executing dg-final: no files matched glob pattern "20030922-2.c.t??.dom1" -- Summary: error executing dg-final: no files matched glob pattern "*.c.t??.dom*" Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22176
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From uros at kss-loka dot si 2005-06-24 20:33 --- (in reply to comment #6) > ../../gcc/unwind.inc: In function '_Unwind_ForcedUnwind': > ../../gcc/unwind.inc:215: internal compiler error: in create_pre_exit, >at mode-switching.c:350 This is a known problem, with a hack to mode-switching.c at http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01434.html. As this will fix an ice you got, the real problem is in fact, that this function is (like __builtin_apply case) trying to handle returned %mm register together with %st and this will confuse mode switching in the exit block. Please, could you try to apply the mode-switching.c part of the patch and see if it fix an ice for you. However, I think that __builtin_apply should process only an x87 output register, and should be limited only to functions that return in FPU_X87 mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 20:16 --- I think this is now fixed on the mainline at the RTL level: ior: movl4(%esp), %eax orb $1, (%eax) ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug tree-optimization/15596] [4.0/4.1 Regression] Missed optimization with bitfields
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 20:08 --- Actually this is another SRA issue. -- What|Removed |Added Last reconfirmed|2005-04-16 17:01:49 |2005-06-24 20:08:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15596
[Bug fortran/22175] BYTE Type Statement
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 19:50 --- Confirmed and g77 treates it as Integer*1. -- What|Removed |Added OtherBugsDependingO||19292 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-24 19:50:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22175
[Bug fortran/22175] New: BYTE Type Statement
BYTE Type Statement. This is a VAX Fortran extension that the majority of Fortran compilers support. The SGI/Absoft compilers treat as equivalent as INTEGER*1. The Portland compiler treats as LOGICAL*1. -- Summary: BYTE Type Statement Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinol at nrlssc dot navy dot mil CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22175
[Bug middle-end/22174] [4.1 Regression] xgcc ices on stage2/ada.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 19:28 --- I will be trying Ada on powerpc-darwin later tonight to see if I can reproduce it on that target. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|other |middle-end Keywords||build, ice-on-valid-code, ||wrong-code Summary|xgcc ices on stage2/ada.|[4.1 Regression] xgcc ices ||on stage2/ada. Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22174
[Bug other/22174] New: xgcc ices on stage2/ada.
# gcc 4.1 snap from 20050624/14:08 stage2/xgcc -Bstage2/ -B/usr/ppc-pld-linux/bin/ -c -O2 -gnatpg -gnata -I- -I. -Iada -I../../gcc/ada ../../gcc/ada/exp_ch3.adb -o ada/exp_ch3.o +===GNAT BUG DETECTED==+ | 4.1.0 20050624 (experimental) (powerpc-pld-linux-gnu) Segmentation fault | | Error detected at exp_ch3.adb:6396:1 | xgcc: Internal error: Aborted (program gnat1) -- Summary: xgcc ices on stage2/ada. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ppc-pld-linux GCC host triplet: ppc-pld-linux GCC target triplet: ppc-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22174
[Bug libstdc++/22131] std::num_get fails for input with invalid groups
--- Additional Comments From pcarlini at suse dot de 2005-06-24 18:22 --- Thanks Martin for the clarification: 100% agreed, also about the grammar thing. I will fix that in a few days, as soon as I'm back from GCCSummit. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-24 18:22:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22131
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-06-24 18:02 --- Yup, it's documented. However, it's still silently accepted even with -pedantic, and the language doesn't permit that. -- What|Removed |Added Summary|#if #A == #B should have a |#if #A == #B should have a |diagnostic |diagnostic in ISO C mode http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug c++/22173] [3.4/4.0/4.1 regression] Bogus template keyword accepted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 17:41 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-24 17:41:57 date|| Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22173
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-06-24 17:41 ---
(In reply to comment #21)
> The slow routine appears to be the buffer cleaning routine,
> though I haven't verified this with oprofile yet.
> Here's its loop:
> static char cleanse_ctr;
> ...
> while (len--) {
> *(ptr++) = cleanse_ctr;
> cleanse_ctr += (17 + (unsigned char) ((int) ptr & 0xF));
> }
[Not entirely related, but..] There's one obvious way to improve this loop.
The compiler cannot prove that the write *(ptr++) does not alias the global
variable cleanse_ptr, so it will read it from memory in each iteration.
To avoid the extra memory read just do something like:
void OPENSSL_cleanse(unsigned char *ptr, unsigned int len)
{
unsigned char local_cleanse_ctr = cleanse_ctr;
while (len--) {
*(ptr++) = local_cleanse_ctr;
local_cleanse_ctr += (17 + (unsigned char) ((int) ptr & 0xF));
}
local_cleanse_ctr += 63;
cleanse_ctr = local_cleanse_ctr;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug other/20128] ice with mudflap + profile generate
--- Additional Comments From pluto at agmk dot net 2005-06-24 17:16 --- also ices with current mainline. -- What|Removed |Added Known to fail||4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20128
[Bug libstdc++/22131] std::num_get fails for input with invalid groups
--- Additional Comments From sebor at roguewave dot com 2005-06-24 17:11 --- Yes, sorry for being too terse. The value is supposed to be stored even if the placement of the thousands separators is invalid, just as long as the input sequence matches the grammar in 22.2.3.1, p2. For example, while "00#0#1" matches the grammar, "000##1" doesn't (because consecutive thousands sperataors are not permitted). In neither case does the placement of the thousands separators match the grouping, so failbit is set. But in the former cases the facet is supposed to store the value while in the latter it must leave it unchanged. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22131
[Bug c++/22173] New: [3.4/4.0/4.1 regression] Bogus template keyword accepted
The following invalid code snippet is accepted since gcc 3.4.0:
struct A
{
static void foo();
};
template void bar()
{
A::template foo(); // bogus template keyword
}
Before it was correctly rejected.
--
Summary: [3.4/4.0/4.1 regression] Bogus template keyword accepted
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22173
[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-06-24 16:56 --- Actually, with -funroll-loops -fweb -frename-registers you get the code you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20376
[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-06-24 16:39 --- Induction variable splitting works as expected (note that r17 and r19 from each iteration are computed independently, so they should not block scheduling). Iv splitting does not rename the variables in different iterations of the unrolled loop directly. But you will get this if you also use -fweb. Note however that even with -fweb you won't get the code you would like, simply because register allocator decides to put all the new registers back into one (which is ok, since their life ranges do not overlap). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20376
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-06-24 16:24 --- Subject: Re: [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3 > I don't see how the precious register would matter much. But this compare > with memory is strange: > > cmpl%ecx, 12(%ebp) > > Why isn't len loaded into a register?? You answer your own question -- because there is no register free; that's why the precisious register maters that much. (I guess; I may be wrong). Zdenek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- Additional Comments From bangerth at ices dot utexas dot edu 2005-06-24 16:14 --- Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members (Sleep deprivation during the week leads to such marvels on Fridays...) > This PR will is about the that 4.0.1 won't This should read: "This PR is about the fact that 4.0.1 won't..." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- Additional Comments From bangerth at ices dot utexas dot edu 2005-06-24 16:03 --- Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members > Although I have not developed a patch, any patch will (more than likely) be > non-trivial. I'll work on a fix, but don't think we should hold up 4.0.1 > for it. Does 4.0.0 compile spec2005? I believe it does compile at least the one benchmark this affects. > If it does, then I don't think we > expect any performance difference between 4.0.0 and 4.0.1 anyway. If it > doesn't, are all of those failures fixed in 4.0.1? If they are not, I > don't think this one change matters in that regard. This PR will is about the that 4.0.1 won't be able to compile this one benchmark. However, given that SPEC 2005 isn't released yet, that's not such a big deal if the problem gets fixed in 4.0.2. I personally would like to see it fixed sooner rather than later, but I don't care too much if that is before or after 4.0.1 is released -- for me, the annoyance is just that if my nightly builds fail regularly, I don't catch other regressions that pop up over time, and things are only discovered at a later time... Cheers Wolfgang - Wolfgang Bangerth email:[EMAIL PROTECTED] www: http://www.ices.utexas.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-24 15:53 --- I don't see how the precious register would matter much. But this compare with memory is strange: cmpl%ecx, 12(%ebp) Why isn't len loaded into a register?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- Additional Comments From nathan at gcc dot gnu dot org 2005-06-24 15:53 --- looking carefully, this is exposing an existing bug that we deduce 'const X' against template void f (T &, void (T::*)() ); this should not happen. Previously we must have been deducing both and then selecting the second one as more specialized. Although I have not developed a patch, any patch will (more than likely) be non-trivial. I'll work on a fix, but don't think we should hold up 4.0.1 for it. Does 4.0.0 compile spec2005? If it does, then I don't think we expect any performance difference between 4.0.0 and 4.0.1 anyway. If it doesn't, are all of those failures fixed in 4.0.1? If they are not, I don't think this one change matters in that regard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug preprocessor/22168] #if #A == #B should have a diagnostic
--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-24 15:42 --- Subject: Re: New: #if #A == #B should have a diagnostic On Jun 23, 2005, at 10:04 PM, geoffk at gcc dot gnu dot org wrote: > GCC quietly accepts the following: > > #define A a > #define B a > #if #A == #B > #endif In fact if we look at the output for the following code: #define A b #define B c #if #A == #B void g(void); #endif We find that "void g(void);" is always outputted so in fact it does not do what David wanted it to do. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
Re: [Bug preprocessor/22168] New: #if #A == #B should have a diagnostic
On Jun 23, 2005, at 10:04 PM, geoffk at gcc dot gnu dot org wrote: GCC quietly accepts the following: #define A a #define B a #if #A == #B #endif In fact if we look at the output for the following code: #define A b #define B c #if #A == #B void g(void); #endif We find that "void g(void);" is always outputted so in fact it does not do what David wanted it to do. Thanks, Andrew Pinski
[Bug c++/22172] [3.4/4.0/4.1 Regression] Internal compiler error, seg fault.
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-24
15:30 ---
Your line should read:
typename SAX::basic_XMLReader::template
Property *>* prop;
If one fixes all four occurances in your file, the code compiles fine.
With your version
SAX::basic_XMLReader::Property *>* prop;
"SAX::basic_XMLReader::Property" is not a type, and therefore "<"
is the operator "less_than" which is followed by a type (followed by some
more stuff, but the compiler already crashed).
An even shorter testcase is the following:
===
namespace N { template struct A {}; }
template void foo()
{
+typename N::A<0>;
}
===
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
Known to fail|4.0.0 4.1.0 |3.4.0 3.4.4 4.0.0 4.1.0
Known to work|3.4.0 3.4.4 |3.3 3.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug preprocessor/22168] #if #A == #B should have a diagnostic
--- Additional Comments From schwab at suse dot de 2005-06-24 15:26 --- *Note (cpp)Assertions::. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug preprocessor/22168] #if #A == #B should have a diagnostic
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-06-24 15:19 --- Still a bug, even if a documented one; the syntax does not allow it. '#if #A' is neither an if-group (because '#A' is not syntactically a constant-expression in the preprocessor) nor a sequence of group-parts, because 'if' is not a non-directive; see 6.10 paragraph 1. Since this a syntax violation, a diagnostic is required. Where is it documented? -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dank at kegel dot com 2005-06-24 15:01 --- And, for what it's worth, the latest 4.1 snapshot also suffers from this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dank at kegel dot com 2005-06-24 15:00 --- Michael Meissner looked at the code, and saw that gcc-2.95.3 converts the loop to a countdown loop, but gcc-3.x doesn't, which wastes a precious register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug preprocessor/22168] #if #A == #B should have a diagnostic
--- Additional Comments From neil at gcc dot gnu dot org 2005-06-24 14:56 --- Documented behaviour. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug tree-optimization/22019] [4.1 Regression] do_structure_copy ICE on Ada gnatlib
--- Additional Comments From pluto at agmk dot net 2005-06-24 14:47 --- (In reply to comment #9) > The g-socket.o is not fixed, please file a new bug for the testsuite failures if they have not been fixed. $ gcc q.adb -O2 -c $ gcc -v Reading specs from /usr/lib/gcc/i686-pld-linux/4.1.0/specs Target: i686-pld-linux Configured with: ../configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++,ada --enable-c99 --enable-long-long --disable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib --without-x i686-pld-linux Thread model: posix gcc version 4.1.0 20050624 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22019
[Bug tree-optimization/22159] [4.1 Regression] gcc-4.1-20050618 ICE's during compilation of nbench-byte-2.2.2 file nbench0.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 14:24 --- Fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22159
[Bug tree-optimization/22051] [4.0/4.1 regression] Wrong code for function pointer comparision during optimization
--- Additional Comments From randolph at tausq dot org 2005-06-24 14:23 --- Subject: Re: [4.0/4.1 regression] Wrong code for function pointer comparision during optimization > The proposed patch has passed testing on x86_64-unknown-linux-gnu. confirmed on hppa-linux. works on original test case. thanks, randolph -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22051
[Bug tree-optimization/22117] [4.1 Regression] VRP thinks + is always nonnull.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 14:16 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22117
[Bug rtl-optimization/22167] Strange optimization bug when using -Os
-- What|Removed |Added Component|c++ |rtl-optimization Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22167
[Bug target/21760] [4.1 Regression] Powerpc atomic builtins missing PPC405 errata
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 14:12 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21760
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 14:11 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From pluto at agmk dot net 2005-06-24 14:03 --- (In reply to comment #5) > Uros, also for you it seems... > (http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01724.html) with this patch I get an ice on amd64 bootstrap: (..) -c ../../gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o In file included from ../../gcc/unwind-dw2.c:256: ../../gcc/config/i386/linux-unwind.h: In function 'x86_64_fallback_frame_state': ../../gcc/config/i386/linux-unwind.h:55: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind.inc: In function '_Unwind_ForcedUnwind': ../../gcc/unwind.inc:215: internal compiler error: in create_pre_exit, at mode-switching.c:350 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug tree-optimization/22171] [4.0/4.1 Regression] gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-24 13:52 --- Subject: Bug 22171 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-24 13:52:36 Modified files: gcc: tree-ssa-operands.c Log message: PR 22171 * tree-ssa-operands (get_expr_operands): Check s_ann for NULL before use. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-operands.c.diff?cvsroot=gcc&r1=2.88&r2=2.89 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug middle-end/7776] const char* p = "foo"; if (p == "foo") ... is compiled without warning!
--- Additional Comments From pluto at agmk dot net 2005-06-24 13:50 ---
(In reply to comment #10)
> (In reply to comment #9)
> > A revised patch, allowing equality and inequality comparisons against
NULL,
> yet
> > retaining warnings for things like 'if ("foo" > 0)' and 'if ("foo" ==
> "bar")'
> > was posted here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01177.html
> >
>
> with this patch I get an ice at amd64:
>
> (..)
> -c ../../gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
>
> In file included from ../../gcc/unwind-dw2.c:256:
> ../../gcc/config/i386/linux-unwind.h:
> In function 'x86_64_fallback_frame_state':
> ../../gcc/config/i386/linux-unwind.h:55: warning: dereferencing type-punned
>pointer will break strict-aliasing rules
> ../../gcc/unwind.inc: In function '_Unwind_ForcedUnwind':
> ../../gcc/unwind.inc:215: internal compiler error: in create_pre_exit,
>at mode-switching.c:350
>
oops, sorry. i've posted above in wrong PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7776
[Bug tree-optimization/22171] [4.0/4.1 Regression] gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
--- Additional Comments From pluto at agmk dot net 2005-06-24 13:47 --- (In reply to comment #7) > (...) > Log message: > PR 22171 > * tree-ssa-operands.c (get_expr_operands): Check s_ann for NULL > before use. You've missed commit for the tree-ssa-operands.c:mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug middle-end/7776] const char* p = "foo"; if (p == "foo") ... is compiled without warning!
--- Additional Comments From pluto at agmk dot net 2005-06-24 13:44 ---
(In reply to comment #9)
> A revised patch, allowing equality and inequality comparisons against NULL,
yet
> retaining warnings for things like 'if ("foo" > 0)' and 'if ("foo" ==
"bar")'
> was posted here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01177.html
>
with this patch I get an ice at amd64:
(..)
-c ../../gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
In file included from ../../gcc/unwind-dw2.c:256:
../../gcc/config/i386/linux-unwind.h:
In function 'x86_64_fallback_frame_state':
../../gcc/config/i386/linux-unwind.h:55: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../gcc/unwind.inc: In function '_Unwind_ForcedUnwind':
../../gcc/unwind.inc:215: internal compiler error: in create_pre_exit,
at mode-switching.c:350
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7776
[Bug libfortran/22170] Handle format slash error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 13:41 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-24 13:41:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22170
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- Additional Comments From nathan at gcc dot gnu dot org 2005-06-24 13:37 --- > > It could be fixed by backing out Nathan's patch (that, to the best of my > > knowledge didn't fix a regression). it did not fix a regression, but was something we wanted added (as I beleive things like Boost were having problems). I waited a while after applying to mainline to see if there were any problem ... > > I've CC'd nathan -- but he's on a plane over the Atlantic right now, so > I'm not sure we'll get a quick response. In any case, I think we can > live with this until 4.0.2. I'll have a look and see if the fix is 'trivial'. My inclination is that if it is not, then we should do nothing for 4.0.1 -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-05-28 17:55:16 |2005-06-24 13:37:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug c++/22172] [3.4/4.0/4.1 Regression] Internal compiler error, seg fault.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24
13:30 ---
Confirmed, here is a reduced testcase:
template
struct cla
{
template
struct clb {};
};
namespace nasa { template struct clc {}; }
template
void doGetProperty(void)
{
cla::clb *> *prop;
}
--- ICE ---
pr22172.cc:12: internal compiler error: tree check: expected class 'type', have
'declaration'
(namespace_decl) in dependent_type_p, at cp/pt.c:12027
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
What|Removed |Added
Severity|critical|normal
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-invalid-code
Known to fail||4.0.0 4.1.0
Known to work||3.4.0 3.4.4
Last reconfirmed|-00-00 00:00:00 |2005-06-24 13:30:49
date||
Summary|Internal compiler error, seg|[3.4/4.0/4.1 Regression]
|fault. |Internal compiler error, seg
||fault.
Target Milestone|--- |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug tree-optimization/22171] [4.0/4.1 Regression] gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-24 13:27 --- Subject: Bug 22171 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-24 13:27:26 Modified files: gcc: ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr22171.c Log message: PR 22171 * tree-ssa-operands.c (get_expr_operands): Check s_ann for NULL before use. PR 22171 * gcc.dg/tree-ssa/pr22171.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9216&r2=2.9217 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5681&r2=1.5682 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr22171.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug tree-optimization/22171] [4.0/4.1 Regression] gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-24 13:24 --- Subject: Bug 22171 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-24 13:24:00 Modified files: gcc: ChangeLog tree-ssa-operands.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr22171.c Log message: PR 22171 * tree-ssa-operands.c (get_expr_operands): Check s_ann for NULL before use. PR 22171 * gcc.dg/tree-ssa/pr22171.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.292&r2=2.7592.2.293 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-operands.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.63.2.1&r2=2.63.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.247&r2=1.5084.2.248 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr22171.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug tree-optimization/22051] [4.0/4.1 regression] Wrong code for function pointer comparision during optimization
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-06-24 13:23 --- The proposed patch has passed testing on x86_64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22051
[Bug tree-optimization/22171] [4.0/4.1 Regression] gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-06-24 13:12 --- I don't know what I'm talking about with 4.0. Anyhow, fix coming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug tree-optimization/22171] [4.0/4.1 Regression] gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-06-24 13:09 --- On the GCC 4.0 branch, this test still works fine. On the GCC mainline, s_ann is NULL. I do see that add_stmt_operand checks s_ann for NULL before using it; I will do the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug target/22169] internal compiler error
-- What|Removed |Added GCC target triplet||sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22169
[Bug tree-optimization/22171] [4.0/4.1 Regression] gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-06-24 13:04 --- I am saddenned. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug tree-optimization/22171] [4.0/4.1 Regression] gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 13:02 --- Caused by: PR 22000 * tree-ssa-operands.c (get_expr_operands): Check the volatility of the FIELD_DECL and set s_ann->has_volatile_ops accordingly. -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug tree-optimization/22171] [4.0/4.1 Regression] gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 13:01 --- Confirmed. -- What|Removed |Added Severity|normal |critical Status|UNCONFIRMED |NEW Component|regression |tree-optimization Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-06-24 13:01:35 date|| Summary|gcc-4.0-20050623 internal |[4.0/4.1 Regression] gcc- |compiler error in |4.0-20050623 internal |linux/drivers/serial/8250.c |compiler error in ||linux/drivers/serial/8250.c Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug c++/22172] Internal compiler error, seg fault.
--- Additional Comments From thomas dot magyar at navy dot mil 2005-06-24 12:43 --- Created an attachment (id=9143) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9143&action=view) The ii file from the compiler output where I received the seg fault. Line 35577 in this file contains the 'typename' that I added to make this compiler have an internal error. Without this keyword, I get a compile error. So, it seems to be required...but I can't build my source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug c++/22172] New: Internal compiler error, seg fault.
This internal compiler error is being generated when I add the keyword 'typename' to a line of code that before that was giving me an error that: SAX/wrappers/saxlibxml2.h:310: error: expected primary-expression before '*' token. In the saxlibxml2.ii file, it is at line 35577. Specs from /usr/local/lib/gc/mips-sgi-irix6.5/3.4.4/specs Configured with ./configure Thread model: single gcc v3.4.4 Command line: g++ -c -I../../Include/SAX ../../Include/SAX/wrappers/saxlibxml2.cpp - o ../../Include/SAX/wrappers/saxlibxml2.o Compiler output: In file included from ../../Include/SAX/wrappers/saxlibxml2.cpp:7: ../../Include/SAX/wrappers/sax libxml2.h: In member function 'virtual std::auto_ptr::PropertyBase> SAX::libxml2_wrapper::doGetProperty(const string_type&)': .../SAX/wrappers/saxlibxml2.:311: 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. gmake: *** [../../Include/SAX/wrappers/saxlibxml2.o] Error 1 -- Summary: Internal compiler error, seg fault. Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot magyar at navy dot mil CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug libstdc++/22131] std::num_get fails for input with invalid groups
--- Additional Comments From pcarlini at suse dot de 2005-06-24 12:18 --- If I understand correctly Martin, the point is that, according to 22.2.2.1.2/11-12, even when the groups are invalid (indeed, he expects a fail in the second assert) the value is stored in val anyway. If this is his point, I believe he is right, we have a bug, certainly not terribly difficult to fix ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22131
[Bug regression/22171] New: gcc-4.0-20050623 internal compiler error in linux/drivers/serial/8250.c
/*
* gcc401bug.c
* Written by Mikael Pettersson, [EMAIL PROTECTED], 2005-06-24.
* Adapted from linux-2.6.12/drivers/serial/8250.c.
*
* gcc-4.0-20050623 bootstrapped on i686-pc-linux-gnu
* gets an ICE when compiling this program at -O2:
*
* gcc401bug.c: In function 'serial8250_isa_init_ports':
* gcc401bug.c:30: internal compiler error: Segmentation fault
*
* Notes:
* - gcc-4.0.1-20050616 does not have this bug.
* - Using -O1 prevents the ICE.
*/
static unsigned int old_serial_port_irq[10];
static struct uart_8250_port {
volatile unsigned int slock;
unsigned int irq;
} serial8250_ports[10];
static __inline__ __attribute__((always_inline)) int irq_canonicalize(int irq)
{
return ((irq == 2) ? 9 : irq);
}
void serial8250_isa_init_ports(void)
{
struct uart_8250_port *up;
int i;
for (i = 0, up = serial8250_ports; i < 10; i++, up++)
up->irq = irq_canonicalize(old_serial_port_irq[i]);
}
int main(void)
{
serial8250_isa_init_ports();
return 0;
}
--
Summary: gcc-4.0-20050623 internal compiler error in
linux/drivers/serial/8250.c
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at csd dot uu dot se
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22171
[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os
-- What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158
[Bug libgcj/22084] [4.1 Regression] Divide_1 test case hangs
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-24 09:47 --- Today (20050624, IST), it seems to have become worse. Till now I used to see 2 FAILs, now I see 6 FAILs: FAIL: Divide_1 execution - source compiled test FAIL: Divide_1 output - gij test FAIL: Divide_1 execution - bytecode->native test FAIL: Divide_1 -O3 output - source compiled test FAIL: Divide_1 output - gij test FAIL: Divide_1 -O3 output - bytecode->native test S.N.A.F.U. -- What|Removed |Added Last reconfirmed|2005-06-17 13:13:47 |2005-06-24 09:47:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084
[Bug java/22166] 0x80000000/-1 is wrong
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-24 09:44 --- This is most likely the same as PR22084 (see the testcase $GCC_SRC_DIR/libjava/testsuite/libjava.lang/Divide_1.java). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22166
[Bug libfortran/22170] New: Handle format slash error
write (*, "(3/)") end output 9 lines. Seems to double count repeated slash. -- Summary: Handle format slash error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fengwang at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22170
[Bug preprocessor/22168] #if #A == #B should have a diagnostic
--- Additional Comments From schwab at suse dot de 2005-06-24 09:06 --- GCC should already reject the use of the # operator, which is only allowed in the replacement list of a macro and then only when followed by a macro parameter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug libstdc++/22131] std::num_get fails for input with invalid groups
--- Additional Comments From chris at bubblescope dot net 2005-06-24 08:52 --- It's probably me being blind, but could you point out the part of the standard which defines what should be happening? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22131
