[Bug tree-optimization/24963] [4.1/4.2 Regression] gcc.dg/vect/vect-62.c scan-tree-dump-times not vectorized: redundant loop. no profit to vectorize. 1 fails
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2005-12-05 07:59 --- Present on SPARC too. Dorit, is it only a matter of changing the expected error message? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||dorit at il dot ibm dot com, ||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24963
[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #18 from krebbel at gcc dot gnu dot org 2005-12-05 07:57 --- (In reply to comment #17) > Oh, and another case where we can get the parallel is for returning 128bit > structs on x86_64. > I've posted a patch on Nov 28th which should handle these cases correctly: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01933.html Richard Guenther tested the patch on x86_64 and I did on s390, s390x and i686. The patch is waiting for approval. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug middle-end/25206] for loop with comma operator problem
--- Comment #4 from efim at lipowsky dot de 2005-12-05 07:34 --- Subject: Re: for loop with comma operator problem pinskia at gcc dot gnu dot org schrieb: >--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-01 16:00 >--- >(In reply to comment #2) > > >>in the file you can see a snapshort with two arrows to read and store >>addresses. >>It is very simple source. >> >> > >This source does not show anything, it is not a full source. If you can read >asm, could you point out what is wrong and also could attach a source which >will compile? > > > > It needed a bit more time to found a problem. It is NOT a problem of GCC, it is an interrupt which is from a programm stopped by GDB before load the new one. The CPU Reset was deaktivated in my GDB .ini file. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25206
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
--- Comment #12 from zac at zacbowling dot com 2005-12-05 05:38 --- I'm not sure, but I'm getting this bug as well, but it maybe out of date. On the last part about the mozilla bail out, if you add this to your mozconfig it might get it to build correctly. ac_cv_visibility_pragma=no -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug c++/25235] byte swapping unreliable in optimized builds
--- Comment #4 from cdfrey at netdirect dot ca 2005-12-05 04:00 --- Just adding a link to a comp.lang.c++.moderated discussion on this, for future reference, when other folks run into this again. Subject line: alias rules and optimization http://groups.google.ca/group/comp.lang.c++.moderated/browse_thread/thread/e7bf096832526f8e/5714701b02a2a3cc?hl=en#5714701b02a2a3cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25235
[Bug target/25166] [4.2 Regression] FAIL: gcc.c-torture/execute/conversion.c compilation
--- Comment #8 from danglin at gcc dot gnu dot org 2005-12-05 03:44 --- Fixed by patch. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25166
[Bug target/25166] [4.2 Regression] FAIL: gcc.c-torture/execute/conversion.c compilation
--- Comment #7 from danglin at gcc dot gnu dot org 2005-12-05 03:23 --- Subject: Bug 25166 Author: danglin Date: Mon Dec 5 03:23:37 2005 New Revision: 108039 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108039 Log: PR target/25166 * pa/pa.c (pa_hpux_init_libfuncs): Add _U_Qfcnvxf_usgl_to_quad and _U_Qfcnvxf_udbl_to_quad to set of initialized libfuncs. * pa/quadlib.c (_U_Qfcnvxf_usgl_to_quad, _U_Qfcnvxf_udbl_to_quad): New functions. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/quadlib.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25166
[Bug libmudflap/24830] Duplicate constructors with -fmudflap
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-05 03:03 --- Confirmed: .size _GLOBAL__I_0_main, .-_GLOBAL__I_0_main .section.ctors,"aw",@progbits .align 4 .long _GLOBAL__I_0_main .section.ctors.65436,"aw",@progbits .align 4 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |libmudflap Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-05 03:03:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24830
[Bug debug/25258] New: [4.0 regression/hpux] gcc generates incorrect stabs debug output
Programs compiled with gcc-4.x on 32-bit hpux targets cannot be debugged. When
loaded into gdb, the programs behave as if no debugging information is present.
For example, given:
int foo(int x)
{
return x;
}
int main(int argc, char **argv)
{
return foo(argc);
}
Placing a breakpoint on foo gives:
(gdb) b foo
During symbol reading, unknown symbol type 0x2e.
During symbol reading, block end address less than block start address in main
(patched it).
During symbol reading, inner block (0x2960-0x2960) not inside outer block
(0x2920-0x2920).
Breakpoint 1 at 0x292c
The "unknown symbol type" warning is for the new BNSYM stab entry that was
added to gcc but not yet updated in gdb.
this problem seems to only occur on the 32-bit HPUX port. On 64-bit HPUX and
32-bit Linux there does not appear to be any problems with slabs debugging.
--
Summary: [4.0 regression/hpux] gcc generates incorrect stabs
debug output
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
GCC build triplet: hppa2.0w-hp-hpux11.11
GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25258
[Bug c++/25010] [4.1/4.2 regression] Segmentation fault (infinite recursion in cgraph_clone_inlined_nodes)
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-05 00:01 --- For me, the testcase does not fail without optimzation, but does fail with -O2. I'm investigating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25010
[Bug middle-end/25248] [4.1/4.2 Regression] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled
--- Comment #7 from giovannibajo at libero dot it 2005-12-04 23:17 --- Further bonus points if you can spot which function is miscompiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
[Bug libfortran/24459] gfortran namelist problem
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2005-12-04 23:11 --- We just had a discussion regarding another similar problem. The maintainers need to come to some concensus on the behavior of some compiler flags such as -std=f95 and -pedantic. Once that is settled then we can address this problem. The reason triplets fail with some f77 compilers is because that notation was not introduced until f90. I think rather than seek compatibility across all compilers, you should seek standard conformance and encourage users to get standard conforming compilers. BTW Gfortran is pretty affordable. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug libfortran/24945] calling two open statements (same unit) without close fails
--- Comment #7 from jb at gcc dot gnu dot org 2005-12-04 22:39 --- No problems have been reported with the patch, closing the bug as fixed. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24945
[Bug target/25255] packed structure: pointers to self result in "error: initializer for integer value is too complicated"
--- Comment #2 from jason dot mcmullan at gmail dot com 2005-12-04 22:34 --- I have attached a patch that fixes the bug by defining 'TARGET_ASM_UNALIGNED_??_OP' in gcc/config/h8300/h8300.c I have confirmed through assembly dumps and object code dumps that this patch works with GNU assembler version 2.16.1 for the h8300. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25255
[Bug target/25255] packed structure: pointers to self result in "error: initializer for integer value is too complicated"
--- Comment #1 from jason dot mcmullan at gmail dot com 2005-12-04 22:32 --- Created an attachment (id=10405) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10405&action=view) Patch to fix the reported issue This patch fixes the reported h8300-specific bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25255
[Bug target/24188] [4.1/4.2 Regression] WRITE(6,*) causes an ICE with -mcmodel=medium
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24188
[Bug target/25254] ICE with -mcmodel=medium -mlarge-data-threshold=1
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-04 21:33 --- Confirmed, this looks related to PR 24188. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||24188 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-04 21:33:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25254
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #54 from pcarlini at suse dot de 2005-12-04 21:33 --- (In reply to comment #53) > > Gosh! Thanks Eric for noticing and further testing. > > Hum... no changes on Solaris 9 and 10. Indeed, should still give problems. > On Solaris 8 I now get: I see what's going wrong: is not included before , which needs it, needs __cplusplus == 1. Ok, Eric, I will ASAP do an audit, check that is everywhere included correctly, sufficiently early, fix all those issues, and only then bother you again for Sol. For now would be the same approach also for Sol 9 and newer. We can figure out something better for recent Sol later, by way of fixincludes or whatelse... Thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug testsuite/25253] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-04 21:29 --- Subject: Re: FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0 > Can you attach the result of -fdump-tree-sra-all for your system? Here it is. Dave --- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-04 21:29 --- Created an attachment (id=10404) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10404&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #53 from ebotcazou at gcc dot gnu dot org 2005-12-04 21:22 --- > Gosh! Thanks Eric for noticing and further testing. Hum... no changes on Solaris 9 and 10. On Solaris 8 I now get: /opt/build/eric/gcc/./gcc/xgcc -shared-libgcc -B/opt/build/eric/gcc/./gcc -nostdinc++ -L/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src -L/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/opt/build/eric/local/gcc/sparc-sun-solaris2.8/bin/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.8/lib/-isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.8/include -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.8/sys-include -I/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8 -I/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include -I/home/eric/svn/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c /home/eric/svn/gcc/libstdc++-v3/src/locale.cc -fPIC -DPIC -o .libs/locale.o /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'void* std::memchr(void*, int, std::size_t)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:101: error: redefinition of 'void* std::memchr(void*, int, std::size_t)' /usr/include/iso/string_iso.h:106: error: 'void* std::memchr(void*, int, std::size_t)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:102: error: invalid conversion from 'const void*' to 'void*' /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'char* std::strchr(char*, int)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:107: error: redefinition of 'char* std::strchr(char*, int)' /usr/include/iso/string_iso.h:80: error: 'char* std::strchr(char*, int)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'char* std::strpbrk(char*, const char*)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:113: error: redefinition of 'char* std::strpbrk(char*, const char*)' /usr/include/iso/string_iso.h:86: error: 'char* std::strpbrk(char*, const char*)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'char* std::strrchr(char*, int)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:119: error: redefinition of 'char* std::strrchr(char*, int)' /usr/include/iso/string_iso.h:92: error: 'char* std::strrchr(char*, int)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'char* std::strstr(char*, const char*)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:125: error: redefinition of 'char* std::strstr(char*, const char*)' /usr/include/iso/string_iso.h:98: error: 'char* std::strstr(char*, const char*)' previously defined here /home/eric/svn/gcc/libstdc++-v3/src/locale.cc: At global scope: /home/eric/svn/gcc/libstdc++-v3/src/locale.cc:62: warning: missing braces around initializer for 'upad64_t [4]' /home/eric/svn/gcc/libstdc++-v3/src/locale.cc:181: warning: missing braces around initializer for 'upad64_t [4]' gmake[4]: *** [locale.lo] Error 1 gmake[4]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug ada/25245] Discriminant is left uninitialized.
--- Comment #3 from laurent at guerby dot net 2005-12-04 21:11 --- The problem is that you are using "Unbounded_String" in your record, and this brings in lots of dope information for Finalization purposes. You can see it with: gcc -c -gnatR3 uninitialized_field.adb ... for Unified_Encoding_Record'Object_Size use 384; for Unified_Encoding_Record'Value_Size use (if (#1 != 1) then (if (#2 == 2) then 384 else 208 end) else 200 end) ; for Unified_Encoding_Record'Alignment use 4; for Unified_Encoding_Record use record _Controller at 4 range 0 .. 159; Known at 0 range 0 .. 7; Os at 1 range 0 .. 7; Which at 24 range 0 .. 7; Nameat 24 range 0 .. 191; Number at 24 range 0 .. 15; end record; ... If you replace Unbounded_String with Character (or any other non controlled like a subtype String5 is string (1..5)) your program does work without problem (4.2.0 20051202). I assume you used 'address and stuff in your test case but not in your original program. Could you provide a test case without 'address that has a suspicious behaviour (even if not all the times)? Laurent -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25245
[Bug testsuite/25253] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-12-04 21:09 --- Can you attach the result of -fdump-tree-sra-all for your system? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #52 from pcarlini at suse dot de 2005-12-04 21:04 --- (In reply to comment #51) > +#define __cpluplus 1 ^ Gosh! Thanks Eric for noticing and further testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #51 from ebotcazou at gcc dot gnu dot org 2005-12-04 21:01 --- > But there is something I don't understand at all: after a recent patch from > Benjamin, eh_globals.cc now does include *first*! Therefore > the problem seems different. At the beginning of eh_globals.cc __cplusplus is > used but should not be seen different before/after the patch on Sol 8, always > == 1 !?! Humpf... +#ifdef __cplusplus +# undef __cplusplus +#endif +#define __cpluplus 1 I'm going to fix the typo and retest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug middle-end/25248] [4.1/4.2 Regression] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled
--- Comment #6 from olh at suse dot de 2005-12-04 20:58 --- Created an attachment (id=10403) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10403&action=view) PR25248-3.tar.bz2 If someone can spot the bug, I cant. Unified all asm labels to reduce diff noise. The object file prevents booting also in a gcc 4.0 compiled kernel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #50 from pcarlini at suse dot de 2005-12-04 20:52 --- But there is something I don't understand at all: after a recent patch from Benjamin, eh_globals.cc now does include *first*! Therefore the problem seems different. At the beginning of eh_globals.cc __cplusplus is used but should not be seen different before/after the patch on Sol 8, always == 1 !?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug testsuite/25253] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-04 20:46 --- Subject: Re: FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0 > /home/dave/gnu/gcc-4.0 (!) > > can it be you run the mainline testsuite with a 4.0 compiler? Nope: [EMAIL PROTECTED]:~/gnu/gcc-4.0/objdir/gcc$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa-linux Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --prefix=/home/dave/opt/gnu/gcc/gcc-4.1.0 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --host=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++,objc,fortran,java,ada Thread model: posix gcc version 4.2.0 20051203 (experimental) > so, no temp_struct. I am confused. I just reran the command and got the same result as reported. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug testsuite/25253] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-12-04 20:41 --- Well, I'll take care of it somehow. Still trying to reproduce it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-04 19:52:21 |2005-12-04 20:41:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug testsuite/25253] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-12-04 20:35 --- It passes for me on i686 and x86_64 (it should be really target independent). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug testsuite/25237] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-04 20:34 --- Subject: Re: FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0 > gcc-3.3!?? it's getting scary. Yah, too many gcc versions to maintain... Don't believe the directory name. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25237
[Bug testsuite/25253] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-04 20:34 --- (In reply to comment #3) > /home/dave/gnu/gcc-4.0 (!) > can it be you run the mainline testsuite with a 4.0 compiler? directory names don't matter. As I said I could reproduce this on x86_64-linux-gnu also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug testsuite/25237] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-12-04 20:31 --- gcc-3.3!?? it's getting scary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25237
[Bug testsuite/25253] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-12-04 20:29 ---
/home/dave/gnu/gcc-4.0 (!)
can it be you run the mainline testsuite with a 4.0 compiler?
I get for
/space/rguenther/obj/obj1/gcc/xgcc -B/space/rguenther/obj/obj1/gcc/
/space/rguenther/src/svn/gcc/gcc/testsuite/gcc.dg/tree-ssa/20031106-6.c -O1
-fdump-tree-optimized -fno-show-column -S -o 20031106-6.s
;; Function foo (foo)
Analyzing Edge Insertions.
foo (r)
{
int r$b;
int r$a;
char r$d;
:
r$b = r.b;
r$a = r.a;
r$d = r.d;
.m = r.m;
.b = r$b;
.a = r$a;
.d = r$d;
return ;
}
so, no temp_struct. I am confused.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #49 from pcarlini at suse dot de 2005-12-04 20:29 --- (In reply to comment #48) > (In reply to comment #47) > > Any reason why libsupc++ can't include the stuff in config/ ? > > I'm interested in seeing this bug go, I'd work on it. > > I'm also interested, of course. In principle, libspuc++ can certainly do that, > but you have to investigate a bit the best way to do that, consistently with > the rest of the library. In fact, the libsupc++ files are *already* including , which is all we need. The problem in eh_globals.cc (also elsewhere? An audit is in order) seems only that it's included too late. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug c/25255] New: packed structure: pointers to self result in "error: initializer for integer value is too complicated"
If a structure has a pointer to itself, and is packed, on the h8300
architecture, I get a compiler error of 'error: initializer for integer
value is too complicated'. This does not occur on the x86 architecture,
nor does it occur on un-packed structures.
Also, the compiler argument '-fpack-struct=1' will cause the same error
to arise on un-packed structures. Curiously, this does not occur with
any of '-fpack-struct=2', '-fpack-stuct=4', nor '-fpack-struct=8'
$ h8300-linux-hms-gcc -c testcase.c
testcase.c:18: error: initializer for integer value is too complicated
(Line 18 is the last line of the 'bad_example' initializer)
$ h8300-linux-hms-gcc -v
Using built-in specs.
Target: h8300-linux-hms
Configured with: ../configure --target=h8300-linux-hms --prefix=/opt/renesas :
(reconfigured) ../configure --target=h8300-linux-hms --prefix=/opt/renesas
--enable-language=c : (reconfigured) ../configure --target=h8300-linux-hms
--prefix=/opt/renesas --enable-languages=c
Thread model: single
gcc version 4.0.2
-- START EXAMPLE CODE testcase.c -
struct good {
struct good *self;
};
struct good good_example =
{
.self = &good_example
};
struct bad {
struct bad *self;
} __attribute__((packed));
struct bad bad_example =
{
.self = &bad_example
};
-- END EXAMPLE CODE testcase.c -
--
Summary: packed structure: pointers to self result in "error:
initializer for integer value is too complicated"
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason dot mcmullan at gmail dot com
GCC build triplet: i586-mandriva-linux-gnu
GCC host triplet: i586-mandriva-linux-gnu
GCC target triplet: h8300-linux-hms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25255
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #48 from pcarlini at suse dot de 2005-12-04 20:20 --- (In reply to comment #47) > Any reason why libsupc++ can't include the stuff in config/ ? > I'm interested in seeing this bug go, I'd work on it. I'm also interested, of course. In principle, libspuc++ can certainly do that, but you have to investigate a bit the best way to do that, consistently with the rest of the library. About Sol 9 and Sol 10, I'm rather surprised to see that the problems are still present. Personally, I would be in favor to just have __cplusplus == 1 on Sol >= 8, would be a progress for all the other targets, but it's a pity, isn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #47 from pedro dot lamarao at mndfck dot org 2005-12-04 20:11 --- Any reason why libsupc++ can't include the stuff in config/ ? I'm interested in seeing this bug go, I'd work on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug target/25254] New: ICE with -mcmodel=medium -mlarge-data-threshold=1
/* { dg-options "-mcmodel=medium -mlarge-data-threshold=1" { target x86_64-*-*
} } */
typedef int FILE;
extern FILE *stdout;
extern int fprintf (FILE *, const char *, ...);
void bar (void)
{
fprintf (stdout, "OK");
}
ICEs in named_section.
--
Summary: ICE with -mcmodel=medium -mlarge-data-threshold=1
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25254
[Bug testsuite/25253] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-04 20:01 --- *** Bug 25237 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug testsuite/25237] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-04 20:01 --- *** This bug has been marked as a duplicate of 25253 *** -- 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=25237
[Bug c/7776] const char* p = "foo"; if (p == "foo") ... is compiled without warning!
--- Comment #13 from sayle at gcc dot gnu dot org 2005-12-04 19:58 --- Subject: Bug 7776 Author: sayle Date: Sun Dec 4 19:58:37 2005 New Revision: 108019 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108019 Log: PR c/7776 * doc/invoke.texi: Document new -Wstring-literal-comparison option. Modified: trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7776
[Bug c/7776] const char* p = "foo"; if (p == "foo") ... is compiled without warning!
--- Comment #12 from sayle at gcc dot gnu dot org 2005-12-04 19:56 --- Subject: Bug 7776 Author: sayle Date: Sun Dec 4 19:56:47 2005 New Revision: 108018 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108018 Log: PR c/7776 * common.opt (Wstring-literal-comparison): New command line option. * c-opts.c (c_common_handle_option): Set it with -Wall. * c-typeck.c (parser_build_binary_op): Issue warning if either operand of a comparison operator is a string literal, except for testing equality or inequality against NULL. * doc/invoke.texi: Document new -Wstring-literal-comparison option. * gcc.dg/Wstring-literal-comparison-1.c: New test case. * gcc.dg/Wstring-literal-comparison-2.c: Likewise. * gcc.dg/Wstring-literal-comparison-3.c: Likewise. * gcc.dg/Wstring-literal-comparison-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/Wstring-literal-comparison-1.c trunk/gcc/testsuite/gcc.dg/Wstring-literal-comparison-2.c trunk/gcc/testsuite/gcc.dg/Wstring-literal-comparison-3.c trunk/gcc/testsuite/gcc.dg/Wstring-literal-comparison-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/c-typeck.c trunk/gcc/common.opt trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7776
[Bug libfortran/24459] gfortran namelist problem
--- Comment #11 from ed at eh3 dot com 2005-12-04 19:54 --- Thank you for re-opening this bug! In an attempt to make our model (http://mitgcm.org) as portable as possible, we tried switching the namelist syntax from the older Fortran77 to F90 "triplets" and discovered the following: "old style" Fortran77: eg.: astring(1,1) = 'name1 ', 'name2 ', 'name3 ' This syntax works with basically *EVERY* Fortran77 compiler that we can get our hands on including g77, Sun, IBM xlf, PGI (pgif77), and Intel. But it fails with gfortran. "new-style F90 triplets": eg.: astring(1:3,1) = 'name1 ', 'name2 ', 'name3 ' This works with some Fortran77 compilers including g77 and Intel but it fails with others including PGI (pgf77). So I would again like to humbly request (or is it beg?!) that this long-standing g77 feature be included with gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug testsuite/25253] FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-04 19:52 --- Confirmed on x86_64-pc-linux-gnu also, looks like Richard removed the wrong xfail from the testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|middle-end |testsuite Ever Confirmed|0 |1 GCC build triplet|hppa-unknown-linux-gnu | GCC host triplet|hppa-unknown-linux-gnu | GCC target triplet|hppa-unknown-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2005-12-04 19:52:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug middle-end/25253] New: FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
Executing on host: /home/dave/gnu/gcc-4.0/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4
.0/objdir/gcc/
/home/dave/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/tree-ssa/20031106
-6.c -O1 -fdump-tree-optimized -fno-show-column -S -o 20031106-6.s
(timeou
t = 300)
PASS: gcc.dg/tree-ssa/20031106-6.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times temp_struct 0
$ cat 20031106-6.c.t93.optimized
;; Function foo (foo)
Analyzing Edge Insertions.
foo (r)
{
struct s temp_struct3;
struct s temp_struct2;
struct s temp_struct1;
struct s r___0;
:
r___0 = r;
temp_struct1 = r___0;
temp_struct2 = temp_struct1;
temp_struct3 = temp_struct2;
= temp_struct3;
return ;
}
2005-12-02 Richard Guenther <[EMAIL PROTECTED]>
* gcc.dg/tree-ssa/20031106-6.c: Remove XFAIL.
--
Summary: FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times
temp_struct 0
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa-unknown-linux-gnu
GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25253
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #46 from pcarlini at suse dot de 2005-12-04 19:46 --- (In reply to comment #45) > > Eric, as regards Solaris, 8, I think you forgot to do the svn copy, as per > > Comment #34 (and # 35 ;) > > Ah, sure, thanks. Now I get: [snip] > /home/eric/svn/gcc/libstdc++-v3/libsupc++/eh_globals.cc -fPIC -DPIC -o > eh_globals.o > /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:66: error: > '__cxa_cdtor_type' has not been declared Thanks. Sigh, double sigh. This makes sense and means that (irrespective of the issues with Sol 9 and 10) the suggested approach doesn't work, because the problems start already inside libsupc++, *not* only in libstdc++ proper, where we can easily put back __cplusplus to 1 in os_defines.h... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #45 from ebotcazou at gcc dot gnu dot org 2005-12-04 19:31 --- > Eric, as regards Solaris, 8, I think you forgot to do the svn copy, as per > Comment #34 (and # 35 ;) Ah, sure, thanks. Now I get: /opt/build/eric/gcc/./gcc/xgcc -shared-libgcc -B/opt/build/eric/gcc/./gcc -nostdinc++ -L/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src -L/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/opt/build/eric/local/gcc/sparc-sun-solaris2.8/bin/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.8/lib/-isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.8/include -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.8/sys-include -I/home/eric/svn/gcc/libstdc++-v3/../gcc -I/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8 -I/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include -I/home/eric/svn/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c /home/eric/svn/gcc/libstdc++-v3/libsupc++/eh_globals.cc -fPIC -DPIC -o eh_globals.o /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:66: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:67: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:71: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:72: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:77: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:78: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:84: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:85: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:91: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:96: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:100: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:105: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:109: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:114: error: '__cxa_cdtor_type' has not been declared gmake[3]: *** [eh_globals.lo] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/libsupc++' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake: *** [all-target-libstdc++-v3] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug regression/25252] New: ICE on invalid code
Hi,
Following invalid code (association stmt sint=>sreal) causes an ICE.
$ cat test.f90
MODULE gswap
TYPE points
REAL :: x, y
END TYPE points
INTERFACE swap
MODULE PROCEDURE sreal, schar, sint => sreal
END INTERFACE swap
CONTAINS
SUBROUTINE sreal(a,b)
real, intent(inout) :: a,b
real :: temp
temp=a
a=b
b=temp
END SUBROUTINE sreal
END MODULE gswap
program test_swap
USE gswap
integer :: i = 2, j=3
call swap(i,j)
end program test_swap
$ gfortran test.f90
In file test.f90:6
MODULE PROCEDURE sreal, schar, sint => sreal
1
Error: Syntax error in MODULE PROCEDURE statement at (1)
test.f90:0: 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.
gdb output
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
0x1001c2d8 in show_locus (offset=0, loc=0x10773018)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:137
137 error_printf ("In file %s:%d\n", f->filename,
(gdb) bt
#0 0x1001c2d8 in show_locus (offset=0, loc=0x10773018)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:137
#1 0x1001c4c4 in show_loci (l1=Variable "l1" is not available.
)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:270
#2 0x22000442 in ?? ()
#3 0x1001b9a4 in error_print (type=0x1054d4b4 "Error:",
format0=0x1054e254 "Procedure '%s' in %s at %L is neither function nor
subroutine", argp=Variable "argp" is not available.
)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:381
#4 0x1001bd30 in gfc_error (
nocmsgid=0x1054e254 "Procedure '%s' in %s at %L is neither function nor
subroutine") at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:595
#5 0x1001fd88 in check_interface0 (p=Variable "p" is not available.
)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/interface.c:880
#6 0x10022134 in check_sym_interfaces (sym=0x10772bb8)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/interface.c:960
#7 0x1005ba50 in traverse_ns (st=0x10772b98,
func=0x100220b0 )
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/symbol.c:2416
#8 0x10021c20 in gfc_check_interfaces (ns=0x107726c0)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/interface.c:1015
#9 0x28000422 in ?? ()
#10 0x10050af4 in gfc_resolve (ns=0x107726c0)
---Type to continue, or q to quit---
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/resolve.c:5436
#11 0x24000482 in ?? ()
#12 0x10046aa4 in gfc_parse_file ()
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/parse.c:2659
#13 0x10066c04 in gfc_be_parse_file (set_yydebug=Variable "set_yydebug" is not
available.
)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/f95-lang.c:286
#14 0x1034584c in toplev_main (argc=Variable "argc" is not available.
)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/toplev.c:990
#15 0x10093900 in main (argc=Variable "argc" is not available.
)
at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/main.c:35
(gdb)
--
Summary: ICE on invalid code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug middle-end/25248] [4.1/4.2 Regression] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-04 19:24 --- (In reply to comment #4) > Created an attachment (id=10402) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10402&action=view) [edit] > PR25248-2.tar.bz2 > this change breaks it. I replaced only arch/powerpc/mm/hash_utils_64.o in my > tests. That would mean there is a latent bug somewhere. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|2.6.15-rc4 |[4.1/4.2 Regression] 2.6.15- |arch/powerpc/mm/hash_utils_6|rc4 |4.c miscompiled |arch/powerpc/mm/hash_utils_6 ||4.c miscompiled Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
[Bug middle-end/25248] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled
--- Comment #4 from olh at suse dot de 2005-12-04 18:17 --- Created an attachment (id=10402) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10402&action=view) PR25248-2.tar.bz2 this change breaks it. I replaced only arch/powerpc/mm/hash_utils_64.o in my tests. r99558 | dnovillo | 2005-05-11 04:24:44 +0200 (Wed, 11 May 2005) | 16 lines * tree-optimize.c (init_tree_optimization_passes): Re-organize optimization passes to do an initial batch of scalar cleanups. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
[Bug libgcj/24154] Make requires too much memory building libjava
--- Comment #2 from mark at gcc dot gnu dot org 2005-12-04 18:08 --- Found something strange. We seem to be generated identical .list files for packages that exist under the gnu.java. hierarchy, but not under the java. hierarchy. For example: classpath/lib/lists/gnu-javax-swing-text-html-parser-models.list and classpath/lib/lists/javax-swing-text-html-parser-models.list are identical, but only the package gnu.javax.swing.text.html.parser.models exists. I have not yet grokked the sed magic that makes this happen in split-for-gcj.sh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
[Bug middle-end/5169] paradoxical subreg problem
--- Comment #13 from roger at eyesopen dot com 2005-12-04 18:06 --- This bug has been fixed, and not just hidden. Jeff Law's proposed solution to this problem http://gcc.gnu.org/ml/gcc/2002-01/msg01872.html which was proposed in January 2002, was contained as part of Jeff/HP's patch of April 2004 (which is subversion revision 51785). 2002-04-03 Jeffrey A Law ([EMAIL PROTECTED]) Hans-Peter Nilsson <[EMAIL PROTECTED]> * combine.c (simplify_comparison): Avoid narrowing a comparison with a paradoxical subreg when doing so would drop signficant bits. This explains why no-one was has been able to reproduce the problem since that date, and assumed that it was hidden (had gone latent) by an unrelated change. Since then that solution has been corrected/improved further by Ulrich in revision 70785. 2003-08-25 Ulrich Weigand <[EMAIL PROTECTED]> * combine.c (simplify_comparison): Re-enable widening of comparisons with non-paradoxical subregs of non-REG expressions. Alan Modra's (self-described) "band-aid" patch was never ideal. It's not unreasonable for combine to eliminate an AND expression with a read from memory, if the paradoxical subreg semantics for the target imply zero extension. It's the later "unsafe" simplification of the comparison that was at fault. Hence the current situation where simplify_comparison has been fixed, and we don't have to needlessly disable a useful optimization with Alan's patch is the most appropriate outcome. Alan's work-around would have been suitable for a release branch, if we didn't yet have the correct fix or such a fix was too intrusive. -- roger at eyesopen dot com changed: What|Removed |Added CC||roger at eyesopen dot com Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5169
[Bug middle-end/25251] NIST Failure - FM013.f at -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-04 17:23 --- Hmm, we are removing a reference to a local label, this could either be a tree level problem (which I thought I fixed) or a rtl level issue which is much harder to fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|fortran |middle-end Keywords||assemble-failure, link- ||failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
[Bug fortran/25251] NIST Failure - FM013.f at -O2
--- Comment #1 from steven at gcc dot gnu dot org 2005-12-04 17:14 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-04 17:14:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #44 from pcarlini at suse dot de 2005-12-04 17:11 --- Eric, as regards Solaris, 8, I think you forgot to do the svn copy, as per Comment #34 (and # 35 ;) Still, Solaris 9 and 10 are not fine, sigh, I'll try to look a bit more into that. Thanks, anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug fortran/25251] New: NIST Failure - FM013.f at -O2
Well now that I have the test suite working easy I decided to explore a little. At higher levels of optimization everything works good except: $ gfc -w -O2 FM013.f /tmp/ccm7knWJ.o(.text+0x4a3): In function `MAIN__': FM013.f: undefined reference to `.L3' /tmp/ccm7knWJ.o(.text+0x598):FM013.f: undefined reference to `.L15' /tmp/ccm7knWJ.o(.text+0x5c4):FM013.f: undefined reference to `.L15' /tmp/ccm7knWJ.o(.text+0x68a):FM013.f: undefined reference to `.L27' collect2: ld returned 1 exit status This is not really a Fortran issue. -- Summary: NIST Failure - FM013.f at -O2 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #12 from gdr at integrable-solutions dot net 2005-12-04 17:07 --- Subject: Re: builtin *printf handlers are confused by -fexec-charset "ghazi at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Backporting this fix to 3.4 requires also backporting the infrastructure patch | for the lang hook to_target_charset posted here: | http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00780.html Hmm, I'm tempted to leave it is as wontix on 3.4.x. Thoughts? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/25248] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled
--- Comment #3 from olh at suse dot de 2005-12-04 16:43 --- an object file compiled with r102096 doesnt work either. Will try older ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #43 from pcarlini at suse dot de 2005-12-04 16:43 --- Hummm, probably there is something fundamentally wrong in the approach, because Solaris 8, at least, is supposed to not change at all, i.e., __cplusplus == 1... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #42 from ebotcazou at gcc dot gnu dot org 2005-12-04 16:34 --- Solaris 8 (32-bit compiler): gmake[3]: Entering directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' Making all in include gmake[4]: Entering directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include' gmake[4]: *** No rule to make target `/home/eric/svn/gcc/libstdc++-v3/config/os/solaris/solaris2.8/ctype_base.h', needed by `stamp-host'. Stop. gmake[4]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2 Solaris 9 (64-bit compiler): /opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/include/cstdlib: In function 'long int std::abs(long int)': /opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/include/cstdlib:131: error: redefinition of 'long int std::abs(long int)' /usr/include/iso/stdlib_iso.h:123: error: 'long int std::abs(long int)' previously defined here /opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/include/cstdlib: In function 'std::ldiv_t std::div(long int, long int)': /opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/include/cstdlib:134: error: redefinition of 'std::ldiv_t std::div(long int, long int)' /usr/include/iso/stdlib_iso.h:124: error: 'std::ldiv_t std::div(long int, long int)' previously defined here gmake[4]: *** [del_op.lo] Error 1 gmake[4]: Leaving directory `/opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/libsupc++' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2 Solaris 10 (biarch compiler): /usr/include/iso/stdlib_iso.h:114: error: previous declaration of 'void* std::bsearch(const void*, const void*, std::size_t, std::size_t, int (*)(const void*, const void*))' with 'C' linkage /usr/include/iso/stdlib_iso.h:118: error: conflicts with new declaration with 'C++' linkage /usr/include/iso/stdlib_iso.h:134: error: previous declaration of 'void std::qsort(void*, std::size_t, std::size_t, int (*)(const void*, const void*))' with 'C' linkage /usr/include/iso/stdlib_iso.h:137: error: conflicts with new declaration with 'C++' linkage /opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/include/cstdlib: In function 'long int std::abs(long int)': /opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/include/cstdlib:131: error: redefinition of 'long int std::abs(long int)' /usr/include/iso/stdlib_iso.h:154: error: 'long int std::abs(long int)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/include/cstdlib: In function 'std::ldiv_t std::div(long int, long int)': /opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/include/cstdlib:134: error: redefinition of 'std::ldiv_t std::div(long int, long int)' /usr/include/iso/stdlib_iso.h:155: error: 'std::ldiv_t std::div(long int, long int)' previously defined here gmake[4]: *** [del_op.lo] Error 1 gmake[4]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/libsupc++' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #11 from ghazi at gcc dot gnu dot org 2005-12-04 16:23 --- Backporting this fix to 3.4 requires also backporting the infrastructure patch for the lang hook to_target_charset posted here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00780.html We'd also need to backport the dg-require-iconv testsuite support, but that's not hard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #18 from hhinnant at apple dot com 2005-12-04 15:55 --- (In reply to comment #15) > Subject: Re: exception_defines.h #defines try/catch > It is also a simple fact > that GCC documents what happens with -fno-exceptions. I'm trying to find this documentation. So far all I've found is: http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options -fexceptions Enable exception handling Is there more? Thanks, Howard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug target/20036] gcc.dg/compat/vector-[12]_y.c fails to compile
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-12-04 15:15 --- > gdb shows that we enter i386.c:classify_argument() with a parameter "mode" of > V2HImode which flows into the default case of a switch statement that aborts. > > The vector-2 testcase dies in the same place, but the unhandled parameter > "mode" is V16SFmode instead. Vector support is flaky in 3.x and has been overhauled in 4.x. I wouldn't spend any significant time on fixing it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20036
[Bug target/20036] gcc.dg/compat/vector-[12]_y.c fails to compile
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-12-04 15:09 --- With current 3.4 branch, the logfile error for vector-1 says: gcc.dg/compat/vector-1_x.c: In function `pass_v2hi': gcc.dg/compat/vector-1_x.c:10: internal compiler error: in classify_argument, at config/i386/i386.c:2291 gdb shows that we enter i386.c:classify_argument() with a parameter "mode" of V2HImode which flows into the default case of a switch statement that aborts. The vector-2 testcase dies in the same place, but the unhandled parameter "mode" is V16SFmode instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20036
[Bug target/20036] gcc.dg/compat/vector-[12]_y.c fails to compile
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-12-04 15:07 --- This one was closed for 3.4 without any investigation. Perhaps the fix in 4.0 can be backported if we identify what it was. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Status|RESOLVED|REOPENED Known to fail||3.4.6 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20036
[Bug libgcj/25250] New: Turn off lib-foo-bar class loading mechanism by default
The gcj-dbtool managed class loading mechanism for native code has mostly replaced the old lib-foo-bar "magic name" mechanism. The magic name mechanism has a serious performance impact on application startup (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174929) , so we should turn it off. Apparently we still use it to load the AWT peer code. We should find some other way to load the peers so we can disable the magic name mechanism by default. -- Summary: Turn off lib-foo-bar class loading mechanism by default Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25250
[Bug c++/25249] inconsistent code for template function calls
--- Comment #1 from a dot kaiser at gmx dot net 2005-12-04 13:35 --- Not seen in CodeSourcery 2005q3, which uses .text section comdats instead of .gnu.linkonce weaks for template instances. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25249
[Bug c++/25249] New: inconsistent code for template function calls
When a function template instance is called, it is called indirectly, likely
due to being "weak" function (arm.c:arm_encode_section_info).
However when the same call is subject of a tail call optimization, it is called
directly.
The function is also called directly when there is no function template
definition visible in the source, e.g. when old style template organization
makes template definitions visible in a single source file only.
What is the reasoning behind the distinction between between weak and normal
functions made in arm.c:arm_encode_section_info? It falls a bit short because
it treats function calls inconsistently, depending on the visibility of their
definition. And while it could simply be treated as a bug in the tail call
optimization, I'd rather suggest to not treat "weak" functions differently,
because (1) efficiency of template based code is greatly affected and (2) I can
see little reason to use long-calls for known "weak" functions but short-calls
for all other external functions including those which are not yet known to be
"weak".
Invocation:
arm-elf-gcc -O2 -S source.cpp
Sample code:
template class Q {
public:
Q();
void f ();
};
// called directly if this definition is removed.
template void Q::f() { }
class U {
public:
int g();
Q& rx;
};
int U::g()
{
rx.f(); // indirect call is used
rx.f(); // turned into direct call by tail call optimization
}
--
Summary: inconsistent code for template function calls
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot kaiser at gmx dot net
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25249
