[Bug c++/24967] New: ICE with misplaced typename
Hi,
my latest typo (a typename in the return statement of a template
function) caused an internal compiler error with gcc 4.0.2 and
gcc 3.4.3. (No ICE with gcc 3.3.4).
#include utility
templatetypename It typename std::pairIt,double
test(It it)
{
return typename std::pairIt,double(it, 0.0); // ICE
// return std::pairIt,double(it, 0.0); // no ICE
}
Output of gcc:
[EMAIL PROTECTED]/src/c++/test]214: g++ -c ice.cpp
ice.cpp: In function 'std::pairIt, double test(It)':
ice.cpp:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
I hope this is not a duplicate of an allready existing
bug report. (In the past I was not very successfully in
searching for known bugs).
Best regards and thanks for all the great work on gcc,
Christoph
--
Summary: ICE with misplaced typename
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christoph dot pesch at siemens dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24967
[Bug target/24951] [4.1/4.2 Regression] ICE: RTL check: expected code 'const_int', have 'const_double' in output_vec_const_move, at config/rs6000/rs6000.c
--- Comment #2 from bonzini at gcc dot gnu dot org 2005-11-21 08:24 --- easy_altivec_constant should only be called with AltiVec integer vector modes, all of which can be represented with a const_vector of const_ints. Anyway, looking into it. Paolo -- bonzini at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-11-21 02:15:40 |2005-11-21 08:24:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951
[Bug libfortran/24909] libmatmul.a breaks darwin build
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2005-11-21 09:02 --- It should now work again on all supported platforms. Confirmed on all versions of Solaris. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24909
[Bug libfortran/24903] dotprod should use conj?
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-21 09:11 --- (In reply to comment #0) conjga = conj(*pa); or conjga = conjl(*pa); or conjga = conjf(*pa); I'm ready to do that, but since complex numbers in C are always a pain, I want to know: are we sure that conj/conjf/conjl are *always* available? I mean, are they part of the things gcc provides even if there is no library support for them in the runtime libm? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24903
[Bug target/24951] [4.1/4.2 Regression] ICE: RTL check: expected code 'const_int', have 'const_double' in output_vec_const_move, at config/rs6000/rs6000.c
--- Comment #3 from bonzini at gcc dot gnu dot org 2005-11-21 09:12 --- Got a patch, but I am curious about Andrew's comment. I couldn't find a reason why r106588 *introduced* the bug rather than unveiling a latent one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951
[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #11 from krebbel at gcc dot gnu dot org 2005-11-21 09:29 --- Ok, knowing that this may only happen if the return value of a function has a complex type a trivial fix could look like this: Index: gcc/flow.c === *** gcc/flow.c.orig 2005-11-15 14:21:23.0 +0100 --- gcc/flow.c 2005-11-21 09:34:05.0 +0100 *** mark_used_regs (struct propagate_block_i *** 4020,4026 recursively scan the value being stored. */ if ((GET_CODE (testreg) == PARALLEL ! GET_MODE (testreg) == BLKmode) || (REG_P (testreg) (regno = REGNO (testreg), ! (regno == FRAME_POINTER_REGNUM --- 4020,4027 recursively scan the value being stored. */ if ((GET_CODE (testreg) == PARALLEL ! (GET_MODE (testreg) == BLKmode !|| COMPLEX_MODE_P (GET_MODE (testreg || (REG_P (testreg) (regno = REGNO (testreg), ! (regno == FRAME_POINTER_REGNUM This fixes the problem for my x86_64 crosscompiler but certainly needs further testing. Could somebody with an Intel 64bit system try to bootstrap this? Bootstraps on s390 wouldn't help here because we do not return complex types that way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug middle-end/17965] ice in expand_call
--- Comment #12 from jakub at gcc dot gnu dot org 2005-11-21 09:41 --- Subject: Bug 17965 Author: jakub Date: Mon Nov 21 09:41:42 2005 New Revision: 107289 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107289 Log: PR middle-end/17965 * calls.c (expand_call, emit_library_call_value_1): Use xmalloc/free instead of alloca for really big argument sizes. * gcc.c-torture/compile/20050622-1.c: New test. Added: branches/gcc-4_0-rhl-branch/gcc/testsuite/gcc.c-torture/compile/20050622-1.c Modified: branches/gcc-4_0-rhl-branch/gcc/ChangeLog branches/gcc-4_0-rhl-branch/gcc/calls.c branches/gcc-4_0-rhl-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17965
[Bug c/20303] [4.0 only] Can't push more than 16 nested visibility
--- Comment #13 from jakub at gcc dot gnu dot org 2005-11-21 09:43 --- Subject: Bug 20303 Author: jakub Date: Mon Nov 21 09:43:10 2005 New Revision: 107290 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107290 Log: 2005-05-18 H.J. Lu [EMAIL PROTECTED] PR middle-end/20303 * c-pragma.c: Include vec.h. (handle_pragma_visibility): Use VEC. * doc/invoke.texi: Remove the nested visibility push limit. 2005-07-22 Jakub Jelinek [EMAIL PROTECTED] PR middle-end/20303 * gcc.dg/visibility-d.c: New test. Added: branches/gcc-4_0-rhl-branch/gcc/testsuite/gcc.dg/visibility-d.c Modified: branches/gcc-4_0-rhl-branch/gcc/ChangeLog branches/gcc-4_0-rhl-branch/gcc/c-pragma.c branches/gcc-4_0-rhl-branch/gcc/doc/invoke.texi branches/gcc-4_0-rhl-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug ada/24946] [4.1/4.2 Regression] make[7]: rc: Command not found
--- Comment #1 from charlet at gcc dot gnu dot org 2005-11-21 09:43 --- I got a bugzilla internal error when trying to attach a proposed patch, so here it is inline (be careful with tabs and spaces, I'd suggest applying the patch manually): --- libada/Makefile.in.orig 2005-11-21 04:34:39.422364000 -0500 +++ libada/Makefile.in 2005-11-21 04:34:17.812698000 -0500 @@ -75,6 +75,9 @@ prefix=$(prefix) \ STAGE_PREFIX=$(STAGE_PREFIX) \ CC=$(host_cc_for_libada) \ + AR_FOR_TARGET=$(AR_FOR_TARGET) \ + RANLIB_FOR_TARGET=$(RANLIB_FOR_TARGET) \ + GCC_FOR_TARGET=$(GCC_FOR_TARGET) \ CFLAGS=$(CFLAGS) $(WARN_CFLAGS) # Rules to build gnatlib. Apparently the libada Makefile is not passing some variables to ada/Makefile properly, so this patch might address the problem you are seeing. Not clear why we are not seeing this problem on other platforms so far though. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24946
[Bug target/17828] -O2 -fPIC doesn't work with switches in linkonce functions and new binutils
--- Comment #10 from jakub at gcc dot gnu dot org 2005-11-21 09:52 --- Subject: Bug 17828 Author: jakub Date: Mon Nov 21 09:52:20 2005 New Revision: 107297 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107297 Log: PR target/17828 * g++.old-deja/g++.other/comdat5.C: New test. * g++.old-deja/g++.other/comdat5-aux.cc: New file. Added: branches/gcc-4_0-rhl-branch/gcc/testsuite/g++.old-deja/g++.other/comdat5-aux.cc branches/gcc-4_0-rhl-branch/gcc/testsuite/g++.old-deja/g++.other/comdat5.C Modified: branches/gcc-4_0-rhl-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17828
[Bug debug/20268] With optimization, generating incomplete debug information
--- Comment #12 from jakub at gcc dot gnu dot org 2005-11-21 09:55 --- Subject: Bug 20268 Author: jakub Date: Mon Nov 21 09:55:14 2005 New Revision: 107300 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107300 Log: PR debug/20268 * dwarf2out.c (add_high_low_attributes): New function, extracted from gen_lexical_block_die. (gen_lexical_block_die, gen_inlined_subroutine_die): Call it. Modified: branches/gcc-4_0-rhl-branch/gcc/ChangeLog branches/gcc-4_0-rhl-branch/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20268
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #31 from pcarlini at suse dot de 2005-11-21 10:40 --- (In reply to comment #30) Created an attachment (id=10303) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10303action=view) [edit] Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8 As-is, this cannot be right, because that file is shared between *all* the Solaris version besides 5 and 6. See configure.host around line 247. If I understand correctly Comment #8, the corrected default should be overriden *only* for Solaris 8. In general, I'm also in favor of this approach, we all agree about that (see Comment #24, 25, 26...). Therefore, my plan would be involving Eric for some tests on *all* the Solaris versions of an amended patch which really would deal specially with Solaris 8 only. It would involve adding a solaris2.8 dir in config/os/solaris, and tweaking configure.host to use the existing solaris2.7 dir for 2.7, 2.9, 2.10... , i.e., skipping 2.8, and the new 2.8 dir (getting the override) for 2.8 only. Are you willing to work on that? -- pcarlini at suse dot de changed: What|Removed |Added CC||ebotcazou at libertysurf dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Comment #39 from gdr at gcc dot gnu dot org 2005-11-21 10:41 --- Fixed in 4.0.0 and higher. Won't fix for 3.4.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|3.4.5 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug target/14552] compiled trivial vector intrinsic code is ineffiencent
--- Comment #16 from pluto at agmk dot net 2005-11-21 11:29 --- without Uros' mmx-patch the gcc-4.1.0-20051113 generates amazing code: (gcc -O3 -march=pentium3 -S -fomit-frame-pointer pr14552.c) test: subl$20, %esp movlw, %eax movlw+4, %edx movl%ebx, 8(%esp) movl%esi, 12(%esp) movl%eax, (%esp) movl%edx, 4(%esp) movswl (%esp),%esi movl%edi, 16(%esp) movswl 4(%esp),%ecx movswl 2(%esp),%edi movswl 6(%esp),%ebx addl%esi, %esi addl%ecx, %ecx movzwl %si, %esi sall$17, %edi movzwl %cx, %ecx sall$17, %ebx movl%edi, %eax movl16(%esp), %edi movl%ebx, %edx orl %esi, %eax movl8(%esp), %ebx orl %ecx, %edx movl12(%esp), %esi movl%eax, w movl%edx, w+4 movlw, %eax movlw+4, %edx movl%eax, dw movl%edx, dw+4 addl$20, %esp ret .size test, .-test .comm dw,8,8 .comm w,8,8 .ident GCC: (GNU) 4.1.0 20051113 (experimental) .section.note.GNU-stack,,@progbits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|uros at kss-loka dot si |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|compiled trivial vector |compiled trivial vector |intrinsic code is |intrinsic code is |ineffiencent|inefficient http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #17 from pcarlini at suse dot de 2005-11-21 11:34 --- Sorry. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug libfortran/24432] [4.1 regression] Missing symbols
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2005-11-21 11:45 --- FreeBSD has the same problem with missing long double math functions. I tried to add an appropriate XFAIL clause for FreeBSD, but dejagnu would still process the file. Huh... the following patch fixes the problem for me. Can I install it? Index: lib/target-supports.exp === --- lib/target-supports.exp (revision 107161) +++ lib/target-supports.exp (working copy) @@ -530,6 +530,7 @@ puts $f integer,parameter :: k = puts $f selected_real_kind (precision (0.0_8) + 1) puts $f real(kind=k) :: x +puts $f x = cos (x); puts $f end close $f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24432
[Bug libfortran/24432] [4.1 regression] Missing symbols
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2005-11-21 12:04 --- (In reply to comment #15) Huh... the following patch fixes the problem for me. Can I install it? Fine with me. Consider approved after testing on some C99-aware platform (like solaris2.10). Please commit on 4.1 as well as mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24432
[Bug c/24968] New: wrong will never be executed warning
The following source will report
C:\Dev-Cpp\Projects\test-stlport\main_17.cpp In function `void test_17()':
12 C:\Dev-Cpp\Projects\test-stlport\main_17.cpp [Warning] will never be
executed
12 C:\Dev-Cpp\Projects\test-stlport\main_17.cpp [Warning] will never be
executed
when using -Wunreachable-code
I reduced this from a way bigger source file with STL and even more if - else
involved and this was the only two warnings from the beginning (whole file) to
the end (this sample). Happens with C and C++.
void test_17()
{
int pos = 1;
while(1) {
if ( pos )
{
if ( pos == 2 ) /* */
{
}
else
{
break;
}
}
else
{
break;
}
}
}
C:\MinGW_3.4.4\bingcc -v
Reading specs from ../lib/gcc/mingw32/3.4.4/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable
-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared
--e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x
--enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.4 (mingw special)
--
Summary: wrong will never be executed warning
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliverst at online dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24968
[Bug c/24969] New: [4.1/4.2 Regression] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o execute (more specifically, test2495 fails) -- Summary: [4.1/4.2 Regression] tmpdir-gcc.dg-struct-layout-1/t026 fails execution Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug c/24969] [4.1/4.2 Regression] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-21 12:22 --- Created an attachment (id=10306) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10306action=view) testcase Compile and link the three files in the tar with -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug c/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-21 12:26 --- works on i686 with 4.1.0 and 4.0.2 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.3.3 4.1.0 4.2.0 Summary|[4.1/4.2 Regression] tmpdir-|tmpdir-gcc.dg-struct-layout- |gcc.dg-struct-layout-1/t026 |1/t026 fails execution |fails execution | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #32 from pedro dot lamarao at mndfck dot org 2005-11-21 12:26 --- Yes, I'll take a shot at this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug c/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-21 12:29 --- 4.0.2 seems to fail also, maybe a testsuite bug? Still somebody needs to investigate closer. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.3.3 4.1.0 4.2.0 |3.3.3 4.0.2 4.1.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug tree-optimization/24653] [4.1/4.2 regression] EON regressed seriously on x86-64
--- Comment #7 from hubicka at gcc dot gnu dot org 2005-11-21 13:14 --- Subject: Bug 24653 Author: hubicka Date: Mon Nov 21 13:14:02 2005 New Revision: 107304 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107304 Log: PR tree-optimization/24653 * tree-ssa-ccp.c (ccp_fold): Strip down useless conversions. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24653
[Bug middle-end/24968] wrong will never be executed warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 13:17 --- Fixed for 4.0.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24968
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #33 from pedro dot lamarao at mndfck dot org 2005-11-21 13:26 --- Created an attachment (id=10307) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10307action=view) Defines __cplusplus to 199711L and overrides it for solaris 8 *only* Please see comment #33 before applying this patch. -- pedro dot lamarao at mndfck dot org changed: What|Removed |Added Attachment #10303|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #34 from pedro dot lamarao at mndfck dot org 2005-11-21 13:29
---
I attached a patch containing Paolo's suggestions.
It was produced with svn diff -x -up after an svn copy like this:
[EMAIL PROTECTED] gcc] svn copy libstdc++-v3/config/os/solaris/solaris2.{7,8}
svn diff doesn't contain this copy directly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug tree-optimization/24653] [4.1 regression] EON regressed seriously on x86-64
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 13:30 --- Fixed at least on the mainline for 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.0 Summary|[4.1/4.2 regression] EON|[4.1 regression] EON |regressed seriously on x86- |regressed seriously on x86- |64 |64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24653
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #35 from pcarlini at suse dot de 2005-11-21 13:35 --- (In reply to comment #34) I attached a patch containing Paolo's suggestions. Thanks. Looks fine to me. If Eric could test it on his Solaris machines it would be great (remember the svn copy! ;) ... Before finally committing it, probably we want to add a short comment before the undef in solaris/solaris2.8/os_defines.h -- pcarlini at suse dot de changed: What|Removed |Added Last reconfirmed|2005-09-26 00:51:24 |2005-11-21 13:35:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug middle-end/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-21 13:40 ---
Old value = 0
New value = 1
check2495 (arg0={a = 27121, b = {c = {d = true, e = 359101392}}},
arg1=0x5019ec, arg2={a = 30216, b = {c = {d = true, e = 1}}})
at t026_y.min.i:71
71 if (arg2.b.c.e != a2495[2].b.c.e) ++fails;
Reduced testcase:
void abort(void);
struct S2495 {
short int a;
union{
struct{
_Bool d;
int e:31;
} c;
} b;
};
struct S2495 x;
void foo(struct S2495 a) __attribute__((noinline));
void foo(struct S2495 a)
{
if (a.a != x.a)
abort();
if (a.b.c.d != x.b.c.d)
abort();
if (a.b.c.e != x.b.c.e)
abort();
}
int main()
{
x.a = 30216;
x.b.c.d = 1;
x.b.c.e = 32766;
foo(x);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #10 from ray at ultramarine dot com 2005-11-21 13:52 ---
(In reply to comment #9)
(In reply to comment #8)
Tried yesterday's snapshot of 4.1 and it still does not work.
OK, I'm on it. Looks like someone forgot about CRLF systems :)
I'll try to submit a first patch tomorrow...
The following changes in transfer.c appear to fix the problem in Linux:
157c157
char *base, *p, *q;
---
char *base, *p, *q, last;
173a174
last= 0;
197c198
if (readlen 1 || *q == '\n' || *q == '\r')
---
if (readlen 1 || *q == '\n' )
215a217,219
if ( last == '\r') {
*length = n-1;
} else {
216a221
}
222a228
last = *q;
Ray
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #36 from ebotcazou at gcc dot gnu dot org 2005-11-21 13:59 --- Thanks. Looks fine to me. If Eric could test it on his Solaris machines it would be great (remember the svn copy! ;) ... Sure. Before finally committing it, probably we want to add a short comment before the undef in solaris/solaris2.8/os_defines.h Yes, please *heavily* comment. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at libertysurf dot|ebotcazou at gcc dot gnu dot |fr |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug c++/24970] New: Error in header file: ctime:69: error: �::tm� has not been declared
When trying to compile the attached source file with $ ~/gcc/bin/g++ --version g++ (GCC) 4.2.0 20051121 (experimental) with the options /Users/eschnett/gcc/bin/g++ -DCARPET_INT -DCARPET_REAL -DCARPET_COMPLEX -mlongcall -ftrapv -fwrapv -fbounds-check -g3 -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Woverloaded-virtual -c -o $current_wd/patch_system.cc.o $current_wd/patch_system.cc -I/sw/include -I/sw/include -I/Users/eschnett/petsc-2.1.6/include -I/Users/eschnett/petsc-2.1.6/bmake/macx -I/Users/eschnett/Cvanilla/arrangements/AEIThorns/AHFinderDirect/src -I/Users/eschnett/Cvanilla/arrangements/AEIThorns/AHFinderDirect/src/include -I/Users/eschnett/Cvanilla/configs/einstein-orange-gcc-debug/config-data -I/Users/eschnett/Cvanilla/configs/einstein-orange-gcc-debug/bindings/include -I/Users/eschnett/Cvanilla/src/include -I/Users/eschnett/Cvanilla/arrangements -I/Users/eschnett/Cvanilla/configs/einstein-orange-gcc-debug/bindings/Configuration/Thorns -I/Users/eschnett/Cvanilla/arrangements/AEIThorns/AHFinderDirect/src/patch -I/Users/eschnett/Cvanilla/arrangements/AEIThorns/AHFinderDirect/src/patch/include -DTHORN_IS_AHFinderDirect -DCCODE then I receive errors beginning with /Users/eschnett/gcc/lib/gcc/powerpc-apple-darwin8.3.0/4.2.0/../../../../include/c++/4.2.0/ctime:69: error: ::tm has not been declared /Users/eschnett/gcc/lib/gcc/powerpc-apple-darwin8.3.0/4.2.0/../../../../include/c++/4.2.0/ctime:71: error: ::clock has not been declared /Users/eschnett/gcc/lib/gcc/powerpc-apple-darwin8.3.0/4.2.0/../../../../include/c++/4.2.0/ctime:72: error: ::difftime has not been declared -- Summary: Error in header file: ctime:69: error: ::tm has not been declared Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: powerpc-apple-darwin8.3.0 GCC host triplet: powerpc-apple-darwin8.3.0 GCC target triplet: powerpc-apple-darwin8.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970
[Bug c++/24970] Error in header file: ctime:69: error: �::tm� has not been declared
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-21 14:01 --- Created an attachment (id=10309) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10309action=view) Failing source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2005-11-21 14:02 --- (In reply to comment #10) The following changes in transfer.c appear to fix the problem in Linux: Confirming this patch, I have something similar in my own tree. But there are some other problems with CRLF and I'll try to submit a full patch soon (a few days at most) to fix them all. Forcing HAVE_CRLF in config.h and running the testsuite appears to be a very good way to find those :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug c++/24970] Error in header file: ctime:69: error: �::tm� has not been declared
--- Comment #2 from schnetter at aei dot mpg dot de 2005-11-21 14:03 --- Created an attachment (id=10310) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10310action=view) Failing preprocessed sourc code (gzipped) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970
[Bug libfortran/24432] [4.1 regression] Missing symbols
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2005-11-21 14:06 --- Fine with me. Consider approved after testing on some C99-aware platform (like solaris2.10) Thanks. My main machine is actually x86-64/Linux so I've verified there that the large real tests are still reported as executed in testsuite/gfortran.log. Same on the Solaris 10 machine. Please commit on 4.1 as well as mainline. Will do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24432
[Bug middle-end/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-21 14:06 --- Disassembly with the first two checks removed (only the third aborts): foo: .LFB2: subq$24, %rsp #, .LCFI0: movlx+8(%rip), %eax #, tmp62 movl16(%rsp), %edx #, tmp60 movq%rdi, 8(%rsp) # a, a andl$2147483647, %eax #, tmp62 andl$2147483647, %edx #, tmp60 cmpl%eax, %edx # tmp62, tmp60 jne .L6 #, addq$24, %rsp #, ret .L6: callabort # main: .LFB3: subq$8, %rsp#, .LCFI1: movlx+8(%rip), %eax #, tmp62 movw$30216, x(%rip) #, x.a movb$1, x+4(%rip) #, x.b.c.d movqx(%rip), %rdi # x, x andl$-2147483648, %eax #, tmp62 orl $32766, %eax#, tmp62 movl%eax, x+8(%rip) # tmp62, callfoo # xorl%eax, %eax # result addq$8, %rsp#, ret it looks like we are confused on where we passed the structure by value. It's in %rdi and %eax, while we think it got passed on stack(!?) in foo. Someone with more x86_64 ABI knowledge has to look into this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #12 from jvdelisle at verizon dot net 2005-11-21 14:21 --- Subject: Re: GFORTRAN input and carriage returns fxcoudert at gcc dot gnu dot org wrote: --- Comment #11 from fxcoudert at gcc dot gnu dot org 2005-11-21 14:02 --- (In reply to comment #10) The following changes in transfer.c appear to fix the problem in Linux: Confirming this patch, I have something similar in my own tree. But there are some other problems with CRLF and I'll try to submit a full patch soon (a few days at most) to fix them all. Forcing HAVE_CRLF in config.h and running the testsuite appears to be a very good way to find those :) Tres bien! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug middle-end/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- Comment #6 from matz at suse dot de 2005-11-21 14:25 --- Something is fishy. Iff registers are used for passing then it would have to be %rdi and %rsi (not %rax)! So the high part of this struct (where the bitfield lies) is not passed at all here. Per ABI this whole struct should be passed in registers (it's not larger than two eightbytes, and both eightbytes have class INTEGER (they contain no unaligned fields or other fancy stuff)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug target/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target Keywords||ABI Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug target/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-21 14:35 ---
More reduced/simplified:
void abort(void);
struct S2495 {
int a;
struct{
int d;
int e:31;
} c;
};
struct S2495 x;
void foo(struct S2495 a) __attribute__((noinline));
void foo(struct S2495 a)
{
if (a.c.e != x.c.e)
abort();
}
int main()
{
x.c.e = 32766;
foo(x);
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-11-21 14:35:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug ada/24946] [4.1/4.2 Regression] make[7]: rc: Command not found
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-21 14:36 --- Subject: Re: [4.1/4.2 Regression] make[7]: rc: Command not found Apparently the libada Makefile is not passing some variables to ada/Makefile properly, so this patch might address the problem you are seeing. Not clear why we are not seeing this problem on other platforms so far though. I'm not sure either. I did notice that the build that had a problem was using an old version of make (3.79.1). I removed this and now this system appears to be behaving similarly to the other hppa-linux system that I build on. On the otherhand, I've been building with this version of make for years. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24946
[Bug tree-optimization/24653] [4.1 regression] EON regressed seriously on x86-64
--- Comment #9 from hubicka at ucw dot cz 2005-11-21 14:44 --- Subject: Re: [4.1 regression] EON regressed seriously on x86-64 --- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 13:30 --- Fixed at least on the mainline for 4.2.0. I am going to fix it on 4.1 branch too once testing converge. However I would still like to see DCE after DOM or reordered DCE and DOM. Even if the CCP patch fixes the EON regression one way, this problem seem pretty common to C++ code (see my tramp3d results I posted). Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24653
[Bug libstdc++/24970] Error in header file: ctime:69: error: �::tm� has not been declared
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 14:55 --- # 1 /Users/eschnett/Cvanilla/configs/einstein-orange-gcc-debug/bindings/Configuration/Thorns/time.h 1 3 4 Hmm, it is including the wrong time.h for some reason. Could you add -v and provide the output, I am mainly looking for the include patch order. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970
[Bug target/21578] ICE in reload_cse_simplify_operands for Coldfire.
--- Comment #7 from joel at gcc dot gnu dot org 2005-11-21 14:56 --- (In reply to comment #6) Shall we close this as WORKSFORME? Looks like it. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21578
[Bug ada/24946] [4.1/4.2 Regression] make[7]: rc: Command not found
--- Comment #3 from charlet at adacore dot com 2005-11-21 14:59 --- Subject: Re: [4.1/4.2 Regression] make[7]: rc: Command not found I'm not sure either. I did notice that the build that had a problem was using an old version of make (3.79.1). I removed this and now this system appears to be behaving similarly to the other hppa-linux system that I build on. On the otherhand, I've been building with this version of make for years. Interesting. This might be a bug in the handling of the export directive then, latent up to now, but showing explicitely now that more variables are used by the Ada Makefile. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24946
[Bug other/24970] Error in header file: ctime:69: error: �::tm� has not been declared
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-21 15:01 --- We have in libstdc++: #include time.h So this is invalid. -I does: -I dir Add the directory dir to the list of directories to be searched for header files. Directories named by -I are searched before the standard system include directories. If the directory dir is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the spe- cial treatment of system headers are not defeated . either use -iquote which is new for 4.0.0 or use -idirafter -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|libstdc++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970
[Bug other/24970] Error in header file: ctime:69: error: �::tm� has not been declared
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-21 15:02 --- As I said this is invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #18 from pluto at agmk dot net 2005-11-21 15:05 --- gcc-3.3.6 produces better code: test: movqw, %mm1 psllw $1, %mm1 movq%mm1, w movqw, %mm1 movq%mm1, dw ret .comm dw,8,8 .comm w,8,8 can we classify this as a code size regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #3 from msharov at hotmail dot com 2005-11-21 15:07 --- By its very nature, demonstrating the problem requires a large example, so I am unable to provide a sufficiently compact one to post here. You can, however, download the project I'm having problems with from SourceForge http://sourceforge.net/projects/ustl. In it I'm using a custom configure script to set --param values and do what else I can to avoid these errors, so after running it you'll need to edit Config.mk to comment out INLINE_OPTS, add -Winline to CXXFLAGS, and change the default -O3 to -Os a little further down. The location of the resulting errors varies on different machines, but I always get them. Doing a test build now, I'm getting: Compiling cmemlink.cc ... Compiling fdostream.cc ... cc1plus: warnings being treated as errors memlink.h: In member function 'char* ustl::ostream::ipos()': memlink.h:74: warning: inlining failed in call to 'char* ustl::memlink::begin()': --param max-inline-insns-single limit reached mostream.h:62: warning: called from here make: *** [cmemlink.o] Error 1 make: *** Waiting for unfinished jobs cc1plus: warnings being treated as errors mistream.h: In member function 'virtual size_t ustl::istream::underflow(size_t)': mistream.h:84: warning: inlining failed in call to 'size_t ustl::istream::remaining() const': --param max-inline-insns-single limit reached mistream.h:81: warning: called from here make: *** [fdostream.o] Error 1 Both begin() and remaining() are as simple as functions get, the former returning a member pointer, the latter subtracting two values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-21 15:09 --- (In reply to comment #18) can we classify this as a code size regression? No because 3.3.x was also wrong in the sense it did not emit an emms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #37 from pedro dot lamarao at mndfck dot org 2005-11-21 15:11 --- Yes, please *heavily* comment. If this is approved, someone could do the copy on the relevant branches, then I'd send a patch with better comments and changelog to the gcc-patches list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug c/24971] New: missing prototype causes strange effect at a distance with float.
(972) uname -a
FreeBSD gadoid.ices.cmu.edu 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23
20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
(973) cat a.c
#include stdlib.h
#include stdio.h
int main(int argc,char *argv[])
{
float n = 40;
int i;
for (i = 0;i 10;i++)
foo();
printf(%g\n,n + 2.0);
return 0;
}
float foo()
{
return 1.0;
}
(974) gcc a.c -o a
a.c:17: warning: type mismatch with previous implicit declaration
a.c:10: warning: previous implicit declaration of `foo'
a.c:17: warning: `foo' was previously implicitly declared to return `int'
(975) ./a
nan
(976)
The above program is missing a prototype for the foo function. This
correctly causes a warning, but the missing prototype causes problems for
completely unrelated code. In the above example, the foo() function is called
10 times, then an unrelated floating point operation is peformed which
incorrectly results in a nan. Note that if the number of loop iterations is
reduced to 6 or fewer times, the program will print the correct result.
--
Summary: missing prototype causes strange effect at a distance
with float.
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hansen at cmu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
[Bug c/24971] missing prototype causes strange effect at a distance with float.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:16 --- This code should have been rejected as it is for 3.4.0 and above. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||accepts-invalid Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
[Bug c/24971] missing prototype causes strange effect at a distance with float.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-21 15:16 --- Note the error is: t.c:17: error: conflicting types for foo t.c:10: error: previous implicit declaration of foo was here -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-21 15:16 --- (In reply to comment #11) Could somebody with an Intel 64bit system try to bootstrap this? I don't have an Intel 64bit machine, but I can do a bootstrap on a x86_64 machine with this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug c/24972] New: missing prototype causes strange effect at a distance with float.
(972) uname -a
FreeBSD gadoid.ices.cmu.edu 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23
20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
(973) cat a.c
#include stdlib.h
#include stdio.h
int main(int argc,char *argv[])
{
float n = 40;
int i;
for (i = 0;i 10;i++)
foo();
printf(%g\n,n + 2.0);
return 0;
}
float foo()
{
return 1.0;
}
(974) gcc a.c -o a
a.c:17: warning: type mismatch with previous implicit declaration
a.c:10: warning: previous implicit declaration of `foo'
a.c:17: warning: `foo' was previously implicitly declared to return `int'
(975) ./a
nan
(976)
The above program is missing a prototype for the foo function. This
correctly causes a warning, but the missing prototype causes problems for
completely unrelated code. In the above example, the foo() function is called
10 times, then an unrelated floating point operation is peformed which
incorrectly results in a nan. Note that if the number of loop iterations is
reduced to 6 or fewer times, the program will print the correct result.
--
Summary: missing prototype causes strange effect at a distance
with float.
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hansen at cmu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24972
[Bug c/24973] New: missing prototype causes strange effect at a distance with float.
(972) uname -a
FreeBSD gadoid.ices.cmu.edu 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23
20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
(973) cat a.c
#include stdlib.h
#include stdio.h
int main(int argc,char *argv[])
{
float n = 40;
int i;
for (i = 0;i 10;i++)
foo();
printf(%g\n,n + 2.0);
return 0;
}
float foo()
{
return 1.0;
}
(974) gcc a.c -o a
a.c:17: warning: type mismatch with previous implicit declaration
a.c:10: warning: previous implicit declaration of `foo'
a.c:17: warning: `foo' was previously implicitly declared to return `int'
(975) ./a
nan
(976)
The above program is missing a prototype for the foo function. This
correctly causes a warning, but the missing prototype causes problems for
completely unrelated code. In the above example, the foo() function is called
10 times, then an unrelated floating point operation is peformed which
incorrectly results in a nan. Note that if the number of loop iterations is
reduced to 6 or fewer times, the program will print the correct result.
--
Summary: missing prototype causes strange effect at a distance
with float.
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hansen at cmu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24973
[Bug c/24972] missing prototype causes strange effect at a distance with float.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 --- *** This bug has been marked as a duplicate of 24971 *** -- 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=24972
[Bug c/24971] missing prototype causes strange effect at a distance with float.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 --- *** Bug 24972 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
[Bug c/24973] missing prototype causes strange effect at a distance with float.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 --- *** This bug has been marked as a duplicate of 24971 *** -- 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=24973
[Bug c/24971] missing prototype causes strange effect at a distance with float.
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 --- *** Bug 24973 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-21 15:19 --- It seems to me that the problem here is that a 'warning' is too strong here, particularly with -Werror. We really need a diagnostic that is non-fatal to the compilation, since there's nothing really wrong with the user's code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #38 from pcarlini at suse dot de 2005-11-21 15:22 --- (In reply to comment #37) Yes, please *heavily* comment. If this is approved, someone could do the copy on the relevant branches, then I'd send a patch with better comments and changelog to the gcc-patches list. Don't worry about that, as soon as Eric reports, I'll take care of the rest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug c/24971] missing prototype causes strange effect at a distance with float.
--- Comment #5 from hansen at cmu dot edu 2005-11-21 15:28 --- (In reply to comment #2) Note the error is: t.c:17: error: conflicting types for foo t.c:10: error: previous implicit declaration of foo was here I only get warnings in 3.3.0. Even with warnings, I still do not think that there should be an effect in code unrelated to the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
[Bug target/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 15:29 --- 3.2.3 also gets this wrong the same way. The callee side says the struct comes on the stack. The caller side says the struct goes in via %rdi. Which one is correct? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.3.3 4.0.2 4.1.0 4.2.0 |3.3.3 4.0.2 4.1.0 4.2.0 ||3.2.3 Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug c++/24907] [3.4/4.0/4.1/4.2 Regression] int x, ; accepted
--- Comment #3 from machata at post dot cz 2005-11-21 15:31 --- Created an attachment (id=10311) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10311action=view) Allow comma only on second and further passes of declarator processing loop. The patch addresses the problem by eating comma at the beginning of loop which processes declarators, and only eating it when it's second or later pass. Testcase is in patch, make check-g++ passed on i686-pc-linux-gnu. I'll do bootstrap and more thorough test tomorrow, and send the patch to gcc-patches then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24907
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #5 from msharov at hotmail dot com 2005-11-21 15:34 --- I would disagree. If the compiler ends up creating a function call where I expect a simple movl, that _is_ something I want to hear about as a warning. I have some code that uses inlines in really tight loops and having such a thing happen without any sign of what is going wrong would be a very bad thing indeed. At least now I know which --param to increase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug target/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-21 15:35 --- Here is the rtl which is produced by expanding foo(x): (insn 15 13 16 (set (reg/f:DI 63) (symbol_ref:DI (x) var_decl 0x2b15eb00 x)) -1 (nil) (nil)) (insn 16 15 17 (set (reg:DI 62) (mem/s/c:DI (reg/f:DI 63) [4 x+0 S8 A32])) -1 (nil) (nil)) (insn 17 16 18 (set (reg:DI 5 di) (reg:DI 62)) -1 (nil) (nil)) (call_insn 18 17 0 (call (mem:QI (symbol_ref:DI (foo) [flags 0x3] function_decl 0x2b15fb00 foo) [0 S1 A8]) (const_int 0 [0x0])) -1 (nil) (expr_list:REG_EH_REGION (const_int 0 [0x0]) (nil)) (expr_list:REG_DEP_TRUE (use (reg:DI 5 di)) (nil))) Obviously this is wrong as it only passes one half of the struct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug libstdc++/24975] New: Aliasing problems inside libstdc++
We currently miscompile DLV with -fstrict-aliasing, and the only aliasing issues that are visible are inside libstdc++: /usr/include/c++/4.1.0/bits/basic_string.h:180: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/include/c++/4.1.0/bits/stl_set.h:348: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/include/c++/4.1.0/bits/stl_set.h:409: warning: dereferencing type-punned pointer will break strict-aliasing rules this is with a patch to enable aliasing warnings for C++ -- Summary: Aliasing problems inside libstdc++ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
[Bug libstdc++/24975] Aliasing problems inside libstdc++
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-21 15:44 --- Created an attachment (id=10312) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10312action=view) patch to enable aliasing warnings for C++ Apply to see the warnings (even during a libstdc++ build). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #6 from rearnsha at gcc dot gnu dot org 2005-11-21 15:49 --- Subject: Re: -Os should maximize inlining --param values. I didn't say the compiler shouldn't say anything, I said it shouldn't be fatal. Regardless of whether or not you think the limits are too low, others may disagree and not want to change them. That doesn't mean that the compiler should reject their code because the limit has been exceeded. This is not something that should cause -Werror to refuse compilation.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug libstdc++/24975] Aliasing problems inside libstdc++
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-21 15:51 ---
(In reply to comment #1)
Created an attachment (id=10312)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10312action=view) [edit]
patch to enable aliasing warnings for C++
Note I think this patch is slightly incorrect as the function
build_reinterpret_cast_1 is called during parsing so you get the warning for
template cases where actually the warning would be incorrect.
An example is:
int b;
template typename a a *f(void) { return (a*)(b); }
This should not warn if a is int.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
[Bug fortran/15809] ICE Using Pointer Functions
--- Comment #14 from pault at gcc dot gnu dot org 2005-11-21 15:53 --- I have become more than a little bit concerned that this PR is a wild goose chase. Applying a similar patch to Erik's, I can persuade some bits of code to do something. Furthermore, they are even the same things that ifort9.0 does; right down to segfaulting in the same places... mostly! However, getting anything useful out of such subroutines, even with ifort, is defeating me. From 12.4.1.1 If the dummy argument is a pointer, the actual argument shall be a pointer and the types, type parameters and ranks shall agree. Does this not make an automatic, character-length, pointer dummy incorrect code? At the invocation of the procedure, the dummy argument pointer receives the pointer association status of the actual argument. If the actual argument is currently associated, the the dummy argument becomes associated with the same target... Thus encouraged, I wrote this: SUBROUTINE A(p,l) CHARACTER(8), DIMENSION(:), pointer :: p if (associated (p)) then print *, p else print *, not associated end if END SUBROUTINE A character(8), dimension (:), pointer :: ptr character(8), dimension (2), target :: tar tar = def ptr = tar call a (ptr) if (associated (ptr)) print *, in MAIN, ptr = , ptr end ifort decides that p is not associated, whilst gfortran finds p to be associated but fails to recognise that p is a character and produces a bad real message at the print statement. It seems to me that, in gfortran, the dummy needs to be declared in the procedure and its data pointer set to that of the actual argument. Whether an automatic character length should work or not seems to be moot to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
[Bug c++/24967] ICE with misplaced typename
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:56 --- This is a dup of bug 19253 which is fixed in 3.4.5, and 4.0.3. That might be why you did not find the bug. *** This bug has been marked as a duplicate of 19253 *** -- 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=24967
[Bug c++/19253] [3.4/4.0/4.1 regression] bad error message / ICE for invalid template parameter
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-21 15:56 --- *** Bug 24967 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||christoph dot pesch at ||siemens dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19253
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #7 from msharov at hotmail dot com 2005-11-21 16:01 --- (In reply to comment #6) This is not something that should cause -Werror to refuse compilation. Well, according to the manpage, -Werror treats _all_ warnings as fatal, no matter what they are about. Since -Winline is an optional parameter that most normal people don't use, and one that is not enabled by either -Wall or -Wextra, I have no problem with the current behaviour. Regardless of whether or not you think the limits are too low, others may disagree and not want to change them. Speaking of that, can anyone give me an example of when the limits would be considered too high? Or at all necessary? I can understand the need for them once the -finline-functions has been enabled, since it may end up inlining everything I own, but I don't think it is unreasonable to expect everything explicitly declared inline to be inlined in an optimized build. I did actually file a bug about that before, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21587, which was resolved WONTFIX, saying that inline is always been just a hint to the compiler. It seems that this is the root of the problem right there: the refusal to distinguish explicitly inline functions from those that become inline due to -finline-functions. I'm pretty sure that if you run a poll of all the C++ programmers, they'll tell you that they expect the former to always be inlined in an optimized build, while the latter ought to depend on some specific command-line parameters. Perhaps it would be prudent to rethink 21587? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug fortran/24546] [meta-bug] gfortran debugging problems
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-21 16:01 --- Just as a general note, the deadline for dwarf3 comments is Dec 1, 2005. So if anyone with some clue about how to improve support for debugging fortran has some good suggestions that would require changes in the debug format, now is the time to send them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
[Bug libstdc++/24975] Aliasing problems inside libstdc++
--- Comment #3 from chris at bubblescope dot net 2005-11-21 16:03 --- While it does look like there might be an error in this warning code, I also have a feeling we are doing something bad here. I looked at the examples in stl_set.h and we are doing reference casting from a _Rb_tree_const_iterator to a _Rb_tree_iterator. Now these both have identical elements and no virtual functions, which is why I suspect this code works. However I sure this isn't valid C++? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
[Bug libstdc++/24975] Aliasing problems inside libstdc++
--- Comment #4 from pcarlini at suse dot de 2005-11-21 16:05 --- Thanks. I'm looking into the issue. The part involving set seems to me much more critical and hopefully solvable without breaking the ABI, because we are not exporting anything from the library involving set/multiset. I suppose you can confirm that DLV heavily uses set?!? -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-21 16:05:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
[Bug fortran/24223] Gfortran crashes in two places
--- Comment #6 from pault at gcc dot gnu dot org 2005-11-21 16:06 ---
Subject: Bug 24223
Author: pault
Date: Mon Nov 21 16:05:58 2005
New Revision: 107310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107310
Log:
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR fortran/24223
* resolve.c (resolve_contained_fntype) Error if an internal
function is assumed character length.
PR fortran/24705
* trans-decl.c (gfc_create_module_variable) Skip ICE in
when backend decl has been built and the symbol is marked
as being in an equivalence statement.
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR fortran/24223
* gfortran.dg/substring_equivalence.f90: New test.
PR fortran/24705
* gfortran.dg/auto_internal_assumed.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90 (with props)
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
Added: trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90?root=gccview=autorev=107310
==
--- trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90 Mon Nov 21
16:05:58 2005
@@ -1,0 +1,13 @@
+! { dg-do compile }
+! Test fix of PR24705 - ICE on assumed character length
+! internal function.
+!
+character (6) :: c
+ c = f1 ()! { dg-error must not be assumed length }
+ if (c .ne. 'abcdef') call abort
+contains
+ function f1 ()
+character (*) :: f1
+f1 = 'abcdef'
+ end function f1
+end
Propchange: trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90
('svn:executable' added)
Added: trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90?root=gccview=autorev=107310
==
--- trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90 Mon Nov 21
16:05:58 2005
@@ -1,0 +1,8 @@
+! { dg-do compile }
+! Tests fix for PR24223 - ICE on equivalence staement.
+!
+module FLAGS
+ character(len=5) :: Encodings
+ character :: at, dev
+ equivalence ( encodings(1:1),at ), ( encodings(2:2),dev)
+end module FLAGS
Propchange: trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24223
[Bug fortran/24705] ICE on assumed length character result
--- Comment #3 from pault at gcc dot gnu dot org 2005-11-21 16:06 ---
Subject: Bug 24705
Author: pault
Date: Mon Nov 21 16:05:58 2005
New Revision: 107310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107310
Log:
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR fortran/24223
* resolve.c (resolve_contained_fntype) Error if an internal
function is assumed character length.
PR fortran/24705
* trans-decl.c (gfc_create_module_variable) Skip ICE in
when backend decl has been built and the symbol is marked
as being in an equivalence statement.
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR fortran/24223
* gfortran.dg/substring_equivalence.f90: New test.
PR fortran/24705
* gfortran.dg/auto_internal_assumed.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90 (with props)
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
Added: trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90?root=gccview=autorev=107310
==
--- trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90 Mon Nov 21
16:05:58 2005
@@ -1,0 +1,13 @@
+! { dg-do compile }
+! Test fix of PR24705 - ICE on assumed character length
+! internal function.
+!
+character (6) :: c
+ c = f1 ()! { dg-error must not be assumed length }
+ if (c .ne. 'abcdef') call abort
+contains
+ function f1 ()
+character (*) :: f1
+f1 = 'abcdef'
+ end function f1
+end
Propchange: trunk/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90
('svn:executable' added)
Added: trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90?root=gccview=autorev=107310
==
--- trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90 Mon Nov 21
16:05:58 2005
@@ -1,0 +1,8 @@
+! { dg-do compile }
+! Tests fix for PR24223 - ICE on equivalence staement.
+!
+module FLAGS
+ character(len=5) :: Encodings
+ character :: at, dev
+ equivalence ( encodings(1:1),at ), ( encodings(2:2),dev)
+end module FLAGS
Propchange: trunk/gcc/testsuite/gfortran.dg/substring_equivalence.f90
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24705
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 16:06 --- (In reply to comment #7) I'm pretty sure that if you run a poll of all the C++ programmers, they'll tell you that they expect the former to always be inlined in an optimized build, while the latter ought to depend on some specific command-line parameters. Depends on which C++ developers and if they have really thought about all their uses of inline (most have not even though they say they want functions declared as inline to be inlined)? Also there are examples of where respecting inline will just cause the compiler to use so much memory/compile time is not funny. An example is PR 8361. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #13 from krebbel at gcc dot gnu dot org 2005-11-21 16:07 --- I don't have an Intel 64bit machine, but I can do a bootstrap on a x86_64 machine with this patch. Ups. That's what I was trying to suggest - an unusual typo isn't it? ;-) Thanks for taking care of this! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug c++/20416] Incorrect lifetime for temporary with static const reference
--- Comment #1 from rsandifo at gcc dot gnu dot org 2005-11-21 16:09
---
Confirmed. Here's a dejagnu-style testcase:
// PR c++/20416. We correctly constructed the temporary S in foo(),
// but incorrectly destroyed it every time foo() was called.
// { dg-do run }
extern C void abort (void);
namespace { int counter; }
struct S {
S() { counter++; }
S(const S ) { counter++; }
~S() { counter--; }
};
void
foo (void)
{
static const S s = S();
if (counter != 1)
abort ();
}
int main ()
{
if (counter != 0)
abort ();
foo ();
foo ();
}
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||3.4.5 4.1.0
Last reconfirmed|-00-00 00:00:00 |2005-11-21 16:09:00
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20416
[Bug libstdc++/24975] Aliasing problems inside libstdc++
--- Comment #5 from pcarlini at suse dot de 2005-11-21 16:09 --- One more bit of info (meant for Chris too): I think the cast has been added when set was changed to have both iterator and const_iterator as const iterator types. Since we are not exporting anything, I suppose we can fix the code at the level of the underlying _Rb_tree functions... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
[Bug c++/20416] Incorrect lifetime for temporary with static const reference
--- Comment #2 from rsandifo at gcc dot gnu dot org 2005-11-21 16:09 --- BTW, this is 12.2/5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20416
[Bug target/24953] RTL check: access of elt 1 of vector with last elt 0 in vrsave_operation_1, at config/rs6000/predicates.md:1041
--- Comment #3 from dje at gcc dot gnu dot org 2005-11-21 16:12 --- Subject: Bug 24953 Author: dje Date: Mon Nov 21 16:12:32 2005 New Revision: 107311 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107311 Log: PR target/24953 * config/rs6000/predicates.md (vrsave_operation): Check UNSPEC_VOLATILE value. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24953
[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-21 16:19
---
(In reply to comment #13)
Ups. That's what I was trying to suggest - an unusual typo isn't it? ;-)
Thanks for taking care of this!
Actually I was wrong in saying that only complex modes can show up here. It
can also show up in the mixed 64/32 bit of PPC for 64bit ints (powerpc-darwin
is the target).
(call_insn 8 6 9 (parallel [
(set (parallel:DI [
(expr_list:REG_DEP_TRUE (reg:SI 3 r3)
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:SI 4 r4)
(const_int 4 [0x4]))
])
(call (mem:SI (symbol_ref:SI (f) [flags 0x41] function_decl
0x2b0a6e00 f) [0 S4 A8])
(const_int 32 [0x20])))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
]) -1 (nil)
(nil)
(nil))
You most likely can construct an ICE for that testcase too but I don't really
know how.
The testcase to get that construct is:
long long f(void);
int g(void)
{
return f();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-21 16:22 --- (In reply to comment #14) The testcase to get that construct is: Compiling with -mpowerpc64 to get the mixed mode. I would not doubt that the arm failure is a similar issue but not with complex types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #9 from msharov at hotmail dot com 2005-11-21 16:25 --- (In reply to comment #8) Depends on which C++ developers and if they have really thought about all their uses of inline (most have not even though they say they want functions declared as inline to be inlined)? Since when does developer ignorance require workarounds in the compiler? If I don't really think about how I write my iterator loops, I fully deserve to have buffer overflows (although, if the compiler can be smart enough to generate a warning, that would be great!). Likewise, if I declare all my functions inline, then I deserve to get an incredibly bloated compiled executable. That's the spirit of C - do what I say, not what you think is good for me. If I wanted the latter, I'd be using Java. Also there are examples of where respecting inline will just cause the compiler to use so much memory/compile time is not funny. An example is PR 8361. Looking at that gave me the shivers :) Whoever wrote that code definitely didn't think about what should be inlined and what shouldn't be. They have inline functions a hundred lines long! I would say they got exactly what they deserved - slow compilation and a lot of bloat. If you write bad code, the bad code should be fixed, not the compiler, which is even in this case doing just what it is told to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug libstdc++/24975] Aliasing problems inside libstdc++
--- Comment #6 from pcarlini at suse dot de 2005-11-21 16:28 --- Actually, to be 100% safe wrt binary compatibility (addresses, etc.) we can also overload for _Rb_tree::const_iterator the involved _Rb_tree functions, I'm preparing a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
[Bug target/24951] [4.1/4.2 Regression] ICE: RTL check: expected code 'const_int', have 'const_double' in output_vec_const_move, at config/rs6000/rs6000.c
--- Comment #4 from bonzini at gcc dot gnu dot org 2005-11-21 16:38 --- Subject: Bug 24951 Author: bonzini Date: Mon Nov 21 16:38:13 2005 New Revision: 107312 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107312 Log: 2005-11-21 Paolo Bonzini [EMAIL PROTECTED] PR target/24951 * config/rs6000/rs6000.c (output_vec_const_move): Load cst and cst2 only for SPE vectors. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951
[Bug rtl-optimization/20583] [4.0 regression] ICE in output_operand: invalid expression as operand
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-21 16:50 --- Fixed in 4.1.0 and above for now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |rtl-optimization Known to fail||4.0.2 Known to work||4.1.0 4.2.0 Summary|[4.0/4.1/4.2 regression] ICE|[4.0 regression] ICE in |in output_operand: invalid |output_operand: invalid |expression as operand |expression as operand Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug target/24951] [4.1/4.2 Regression] ICE: RTL check: expected code 'const_int', have 'const_double' in output_vec_const_move, at config/rs6000/rs6000.c
--- Comment #5 from bonzini at gcc dot gnu dot org 2005-11-21 17:04 --- Subject: Bug 24951 Author: bonzini Date: Mon Nov 21 17:04:11 2005 New Revision: 107313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107313 Log: 2005-11-21 Paolo Bonzini [EMAIL PROTECTED] PR target/24951 * config/rs6000/rs6000.c (output_vec_const_move): Load cst and cst2 only for SPE vectors. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951
[Bug target/24951] [4.1/4.2 Regression] ICE: RTL check: expected code 'const_int', have 'const_double' in output_vec_const_move, at config/rs6000/rs6000.c
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-11-21 17:05 --- Andreas, can you confirm it is fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951
[Bug c/24976] New: simple hexadecimal number parsed as C99 hex float
This testcase: int a = 0xe+100; Produces a diagnostic message that would surprise most users: foo.c:1:9: error: invalid suffix +100 on integer constant I'm not sure what the standard says about ambiguity between the hex float notation and the regular + operator, but many users are going to think of this behavior as a parser bug. -- Summary: simple hexadecimal number parsed as C99 hex float Product: gcc Version: 4.0.3 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bernie at develer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24976
[Bug preprocessor/24976] simple hexadecimal number parsed as C99 hex float
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 17:28 --- (In reply to comment #0) but many users are going to think of this behavior as a parser bug. This is more of a tokenizer error rather than a parser error. Anyways 2.95.3 gives: t.c:1: missing white space after number `0xe' I wonder if we should accept this code for -std=c89. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |preprocessor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24976
