[Bug c++/25836] [3.4 Regression] G++ does not allow a conversion of templated types
--- Comment #9 from gdr at gcc dot gnu dot org 2006-01-19 07:48 --- Fixed in 4.0.3 and higher. Won't fix in 3.4.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25836
[Bug c/25805] [3.4/4.0 Regression] Incorrect handling of zero-initialized flexible arrays
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-01-19 07:48 --- I've checked in the fix for 4.1 and 4.2. It doesn't apply directly to earlier branches because they used TREE_LISTs for CONSTRUCTORs. A straight-forward conversion would introduce a linear walk over the list, which is probably not acceptable. I'm leaving this is a 3.4 and 4.0 regression for now. (The original commit wasn't added to bugzilla because I used -m rather than -F to specify the log message. Ooops. Now fixed with svn propset.) -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org AssignedTo|rsandifo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to fail|4.1.0 4.0.0 3.3.3 3.4.0 |4.0.0 3.3.3 3.4.0 |4.2.0 | Known to work|3.2.3 |3.2.3 4.1.0 4.2.0 Summary|[3.4/4.0/4.1/4.2 Regression]|[3.4/4.0 Regression] |Incorrect handling of zero- |Incorrect handling of zero- |initialized flexible arrays |initialized flexible arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805
[Bug c/25805] [3.4/4.0/4.1/4.2 Regression] Incorrect handling of zero-initialized flexible arrays
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-01-19 07:46 --- Subject: Bug 25805 Author: rsandifo Revision: 109946 Modified property: svn:log Modified: svn:log at Thu Jan 19 07:46:15 2006 -- --- svn:log (original) +++ svn:log Thu Jan 19 07:46:15 2006 @@ -1,1 +1,7 @@ -/home/richard/patches/wip/flex-array-init-size.clog + PR c/25805 + * c-decl.c (add_flexible_array_elts_to_size): New function. + (finish_decl): Use it. + +testsuite/ + PR c/25805 + * gcc.dg/pr25805.c: New file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #20 from dick_guertin at yahoo dot com 2006-01-19 07:45 --- Created an attachment (id=10672) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10672&action=view) Contains a testcase in source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug c/25805] [3.4/4.0/4.1/4.2 Regression] Incorrect handling of zero-initialized flexible arrays
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-01-19 07:45 --- Subject: Bug 25805 Author: rsandifo Revision: 109947 Modified property: svn:log Modified: svn:log at Thu Jan 19 07:45:28 2006 -- --- svn:log (original) +++ svn:log Thu Jan 19 07:45:28 2006 @@ -1,1 +1,7 @@ -/home/richard/patches/wip/flex-array-init-size.clog + PR c/25805 + * c-decl.c (add_flexible_array_elts_to_size): New function. + (finish_decl): Use it. + +testsuite/ + PR c/25805 + * gcc.dg/pr25805.c: New file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805
[Bug target/25853] Cannot compile WindowMaker--0.92.0 in FC4: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #2 from backes at rhrk dot uni-kl dot de 2006-01-19 07:36 --- Created an attachment (id=10671) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10671&action=view) faulty source It seems to be an error in the source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25853
[Bug c++/25836] [3.4 Regression] G++ does not allow a conversion of templated types
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-01-19 06:59 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1/4.2 Regression]|[3.4 Regression] G++ does |G++ does not allow a|not allow a conversion of |conversion of templated |templated types |types | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25836
[Bug c++/25836] [3.4/4.0/4.1/4.2 Regression] G++ does not allow a conversion of templated types
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-01-19 06:55 --- Subject: Bug 25836 Author: mmitchel Date: Thu Jan 19 06:55:53 2006 New Revision: 109945 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109945 Log: PR c++/25836 * cp-tree.h (push_class_stack): New function. (pop_class_stack): Likewise. * class.c (class_stack_node): Add hidden field. (pushclass): Clear it. (push_class_stack): New function. (pop_class_stack): Likewise. (currently_open_class): Ignore hidden classes. (currently_open_derived_class): Likewise. * name-lookup.c (push_to_top_level): Call push_class_stack. (pop_from_top_level): Call pop_class_stack. PR c++/25836 * g++.dg/template/init6.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/init6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25836
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-01-19 06:55
---
> Good news, I think I found the problem. Bad news, I can't think of any
> solution. Please read my comments at the end of this information:
Thanks for your efforts.
> What I've discovered is that the -O2 option causes these sckw static objects
> to be placed randomly in memory, NOT in the order they are declared. In all
> previous instances of the gcc compiler, input order was preserved for static
> objects. This is the 'problem'. With -O2 in gcc 3.4.4, order is not
> preserved. So the scan falls off the end when the ending sckw is misplaced.
OK, that makes sense. See http://gcc.gnu.org/gcc-3.4/changes.html, Caveats
section, bullet #13. Note that this reordering is permitted by ISO C (or more
precisely, it is not forbidden by ISO C).
> My question is this: Is there some option that can be used with -O2 that will
> preserve the input-order of static and/or global objects? It would be handy
> if global objects were also kept in order, such as:
>
> long r1;
> long r2;
> long r3;
> etc.
Yes, the workaround is given on the aforementioned page.
> Alternatively, is there some way I can force the input-order of sckw objects?
Yes, by using an array of such structures.
> By the way, I placed a 'break' at the if-test for flg2, but it never sprung.
> Another 'break' at the increment statement {kwp += 1;} was sprung. That's how
> I found these sckw objects were in random order. 'gdb' has problems with -O2
> and -g combined.
Yes, debugging code compiled with -O2 -g is not for the fainthearted. :-) GDB
is primarily aimed at debugging user code so generally used on code compiled
with -O0 -g. It is indeed not really tuned for debugging the compiler itself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug c++/25836] [3.4/4.0/4.1/4.2 Regression] G++ does not allow a conversion of templated types
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-01-19 06:53 --- Subject: Bug 25836 Author: mmitchel Date: Thu Jan 19 06:53:34 2006 New Revision: 109944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109944 Log: PR c++/25836 * cp-tree.h (push_class_stack): New function. (pop_class_stack): Likewise. * class.c (class_stack_node): Add hidden field. (pushclass): Clear it. (push_class_stack): New function. (pop_class_stack): Likewise. (currently_open_class): Ignore hidden classes. (currently_open_derived_class): Likewise. * name-lookup.c (push_to_top_level): Call push_class_stack. (pop_from_top_level): Call pop_class_stack. PR c++/25836 * g++.dg/template/init6.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/init6.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/class.c branches/gcc-4_0-branch/gcc/cp/cp-tree.h branches/gcc-4_0-branch/gcc/cp/name-lookup.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25836
[Bug c++/25836] [3.4/4.0/4.1/4.2 Regression] G++ does not allow a conversion of templated types
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-19 06:53 --- Subject: Bug 25836 Author: mmitchel Date: Thu Jan 19 06:52:56 2006 New Revision: 109943 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109943 Log: PR c++/25836 * cp-tree.h (push_class_stack): New function. (pop_class_stack): Likewise. * class.c (class_stack_node): Add hidden field. (pushclass): Clear it. (push_class_stack): New function. (pop_class_stack): Likewise. (currently_open_class): Ignore hidden classes. (currently_open_derived_class): Likewise. * name-lookup.c (push_to_top_level): Call push_class_stack. (pop_from_top_level): Call pop_class_stack. PR c++/25836 * g++.dg/template/init6.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/init6.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/cp-tree.h branches/gcc-4_1-branch/gcc/cp/name-lookup.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25836
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-19 06:51 --- Oh, you are depending on the order of the static/global variables. That is undefined C. Try -O2 -fno-unit-at-a-time. If that works this is NOT, I will repeat NOT a GCC bug as you are depending on undefined code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug target/25853] Cannot compile WindowMaker--0.92.0 in FC4: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-19 06:50 --- This is an error but not always a bug in GCC. It is most likely a bug in the WindowMaker source. Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25853
[Bug c/25853] New: Cannot compile WindowMaker--0.92.0 in FC4: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
I downloaded the WindowMaker-0.92.0.tar.gz and tried to compile it under FedoraCore4, AMD XP 3200+. The compilation breaks with the following error message: gmake[1]: Entering directory `/tmp/WindowMaker-0.92.0/wrlib' Making all in . gmake[2]: Entering directory `/tmp/WindowMaker-0.92.0/wrlib' `echo /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../src -I/usr/local/include -I/usr/X11R6/include-g -O2 | sed -e s/-fomit-frame-pointer//` -O0 -c x86_specific.c gcc -DHAVE_CONFIG_H -I. -I. -I../src -I/usr/local/include -I/usr/X11R6/include -g -O2 -O0 -c x86_specific.c -fPIC -DPIC -o .libs/x86_specific.o x86_specific.c: In function 'x86_mmx_TrueColor_32_to_16': x86_specific.c:107: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' gmake[2]: *** [x86_specific.lo] Error 1 gmake[2]: Leaving directory `/tmp/WindowMaker-0.92.0/wrlib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/tmp/WindowMaker-0.92.0/wrlib' gmake: *** [all-recursive] Error 1 ... -- Summary: Cannot compile WindowMaker--0.92.0 in FC4: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: backes at rhrk dot uni-kl dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25853
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #17 from dick_guertin at yahoo dot com 2006-01-19 06:41 --- I went back and recompiled all modules with -O -g to see what effect this has on the order of static data. What I found was that all static data occurred in memory in the order declared in the source code. This was NOT true with -O2, where static data was moved around in some unknown order. I read through the 'man gcc' pages very carefully, and could NOT see any -option that would control static data placement. Therefore, -O2 is a show-stopper for this program because static data is NOT laid out in memory in the order declared in the program source. Given this fact, it should be possible for me to create a testcase that shows static data moves around with -O2, and stays in declared order with -O. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug libgomp/25852] New: libgomp testing does not work for multilib (-m32 on x86_64-linux-gnu)
On x86_64, with -m32 I get: FAIL: libgomp.c/appendix-a/a.15.1.c (test for excess errors) Excess errors: /usr/bin/ld: skipping incompatible /home/pinskia/src/checkin/trunk/objdir.c/x86_64-unknown-linux-gnu/./libgomp/.libs/libgomp.so when searching for -lgomp /usr/bin/ld: skipping incompatible /home/pinskia/src/checkin/trunk/objdir.c/x86_64-unknown-linux-gnu/./libgomp/.libs/libgomp.a when searching for -lgomp /usr/bin/ld: skipping incompatible /home/pinskia/src/checkin/trunk/objdir.c/x86_64-unknown-linux-gnu/./libgomp/.libs/libgomp.so when searching for -lgomp /usr/bin/ld: skipping incompatible /home/pinskia/src/checkin/trunk/objdir.c/x86_64-unknown-linux-gnu/./libgomp/.libs/libgomp.a when searching for -lgomp Though libgomp exists in 32/libgomp/.libs for the 32bit library. -- Summary: libgomp testing does not work for multilib (-m32 on x86_64-linux-gnu) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25852
[Bug tree-optimization/24287] pure functions cause things to be call clobbered still
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-19 04:58 --- Confirmed fixed by: 2006-01-16 Daniel Berlin <[EMAIL PROTECTED]> -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24287
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #16 from dick_guertin at yahoo dot com 2006-01-19 04:50 --- I recompiled with -O2 -fno-gcse and got this: Breakpoint 4, rlookup (scancb=0x341da8, keyword_table=0x0, stack_ptr=0xffbef3d8, routine_result=0xffbef35c) at scan.c:1452 1452kwp += 1; (gdb) Continuing. Breakpoint 4, rlookup (scancb=0x341da8, keyword_table=0x0, stack_ptr=0xffbef3d8, routine_result=0xffbef35c) at scan.c:1452 1452kwp += 1; (gdb) Continuing. Breakpoint 4, rlookup (scancb=0x341da8, keyword_table=0x0, stack_ptr=0xffbef3d8, routine_result=0xffbef35c) at scan.c:1452 1452kwp += 1; (gdb) Continuing. Breakpoint 4, rlookup (scancb=0x341da8, keyword_table=0x0, stack_ptr=0xffbef3d8, routine_result=0xffbef35c) at scan.c:1452 1452kwp += 1; (gdb) Continuing. Program received signal SIGILL, Illegal instruction. 0x002b7884 in hex_to_character () Problem persists! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug rtl-optimization/25683] Error while running `make`
--- Comment #13 from gccbugzilla at multiwebinc dot com 2006-01-19 04:38 --- Please help so I can get this fixed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25683
[Bug c++/25836] [3.4/4.0/4.1/4.2 Regression] G++ does not allow a conversion of templated types
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25836
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-19 04:04 --- I wonder if this is at all related to PR 25654 and PR 25130. Can you try "-O2 -fno-gcse"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #14 from dick_guertin at yahoo dot com 2006-01-19 04:00 ---
Good news, I think I found the problem. Bad news, I can't think of any
solution. Please read my comments at the end of this information:
typedef struct nkw
{
char tok[16];/* TOKEN, BLANK PADDED */
short tokl; /* TOKEN LENGTH */
unsigned char flg1; /* FIELD FLAGS */
#define NKWFP1 0x80 /* PARM1 */
#define NKWFP2 0x40 /* PARM2 */
#define NKWFMAT 0x20 /* MATCH ROUTINE */
#define NKWFRTN 0x10 /* PROCESSING ROUTINE */
unsigned char flg2; /* MISC FLAGS */
#define NKWFPUSH 0x80 /* PUSH */
#define NKWFEND 0x40 /* LAST KEYWORD ENTRY IN LIST */
unsigned char flg3; /* MATCH SPECS,SPECIAL ACTIONS */
#define NKWFABBV 0x80 /* ABBREVIATE (3 CHAR MIN) */
#define NKWFAB1 0x40 /* ABBREVIATE (1 CHAR MIN) */
#define NKWFSET 0x20 /* SAVE KEYWORD IN CP */
#define NKWFNOBK 0x10 /* DO NOT BLANK */
#define NKWFCRTN 0x04 /* rtn is in C */
#define NKWFINIT 0x02 /* Convert string to EBCDIC */
unsigned char flg4; /* INTEGER MATCH SPECS */
unsigned char flg5;
unsigned char flg6;
long parm1; /* MATCH PARM 1 */
long parm2; /* MATCH PARM 2 */
void (*mat)();
long (*rtn)(NSCNCB *,
REG,
REG);
unsigned char stuffing[24];
} NKW;
struct sckw {
unsigned char stuff[32];
void (*nkwmat)();
void (*nkwrtn)();
unsigned char more_stuff[24];
};
==
static struct sckw CDEFPRT = {
0xE2,0xC5,0xE3,0x40,0x40,0x40,0x40,0x40,/* SET */
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,3,48,0,
128,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MTOKEN, CDEFSET };
static struct sckw sckw1 = {
0xE2,0xC8,0xD6,0xE6,0x40,0x40,0x40,0x40,/* SHOW */
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,4,48,0,
128,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MTOKEN, CDEFSHOW };
static struct sckw sckw2 = {
0xC4,0xE4,0xD4,0xD7,0x40,0x40,0x40,0x40,/* DUMP */
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,4,48,0,
128,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MTOKEN, CDEFDUMP };
/* - - - - - - - - - - */
static struct sckw sckw268 = {
0xD6,0xD3,0xC4,0xE6,0xE8,0xD3,0x40,0x40,/* OLDWYL */
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,6,48,64,
32,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MTOKEN, XCTL };
==
As you can see from the numbering of these items, there are 269 of them, all
layed out in sequence within the C-source. It is possible to start with any
entry, and scanning is then supposed to go until the last is encountered,
signified by the '64' in the '0,6,48,64' line. That is 0x40 in flg2. The
scan.c code for rlookup looks something like this:
==
NKW *rlookup(NSCNCB *scancb,
NKW keyword_table[],
long stack_ptr[],
long *routine_result)
{
if (keyword_table)
{
NKW *kwp = keyword_table;
long match_result;
REG r[2];
while (kwp)
{
if (kwp->flg3 & NKWFINIT)/* Convert to EBCDIC */
{
memset(kwp->tok + ntohs(kwp->tokl),
' ',
sizeof kwp->tok - ntohs(kwp->tokl));
ascii_to_ebcdic(kwp->tok, sizeof kwp->tok);
kwp->flg3 &= ~NKWFINIT;
}
if (kwp->flg2 & NKWFPUSH)
{
if (kwp->flg3 & NKWFCRTN)
{
long saved_regs[2];
r[0].as_long = R0;
r[1].as_long = R1;
saved_regs[0] = R2;
saved_regs[1] = R3;
R2 = (long) scancb;
R3 = (long) stack_ptr;
R15 = (*(kwp->rtn))(scancb, r[0], r[1]);
R2 = saved_regs[0];
R3 = saved_regs[1];
}
else
{
struct sckw *sckwp = (struct sckw *) kwp;
long saved_regs[2];
saved_regs[0] = R2;
saved_regs[1] = R3;
R2 = (long) scancb;
R3 = (long) stack_ptr;
(*(sckwp->nkwrtn))();
R2 = saved_reg
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-01-19 01:00 --- Closing as won't fix based on GDR's comments. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug libobjc/25762] All objc.dg-struct-layout-encoding-1 fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-19 00:59 --- Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-19 00:59:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25762
[Bug tree-optimization/23282] [4.0 Regression] wrong results at -O on x86
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-19 00:55 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23282
[Bug libgcj/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-19 00:53 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #12 from hubicka at gcc dot gnu dot org 2006-01-19 00:38 --- Right, forgot about that... At the moment I can't think of testcase that would break the transitivity without use of unions... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-19 00:19 --- (In reply to comment #10) > My understanding of C type based aliasing rules always was that char, as an > exception, might alias with everything. Perhaps I lived in false belief for a > while, but at least -Wstrict-aliasing seems to think so: The aliasing rules are asymmetrical. See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00980.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug other/1] Test of new GCC GNATS db.
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-19 00:15 --- (In reply to comment #7) > I am trying to build a cross compiler for host i686-pc-cygwin and target > h8300-hms. I built binutils, bootstrap GCC and newlib successfully. ( using > binutils-2.16, newlib-1.14.0 and gcc-3.4.4. When I build the final gcc using > this configure command This is PR 21745: http://gcc.gnu.org/PR21745 Next time please don't comment in PR1 or anyother unrelated bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #10 from hubicka at gcc dot gnu dot org 2006-01-19 00:14
---
My understanding of C type based aliasing rules always was that char, as an
exception, might alias with everything. Perhaps I lived in false belief for a
while, but at least -Wstrict-aliasing seems to think so:
ibm:~ # more t.c
char a[10];
short b[10];
main()
{
*(int *)a=5;
*(int *)b=5;
}
ibm:~ # gcc -O2 -Wstrict-aliasing t.c
t.c: In function main:
t.c:6: warning: dereferencing type-punned pointer will break strict-aliasing
rules
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #18 from gdr at cs dot tamu dot edu 2006-01-19 00:09 --- Subject: Re: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | There is some good advice at that precisely prooves my point: it is a coding style issue best served by a deicated tool. We plenty of coding stule rules out there. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug other/1] Test of new GCC GNATS db.
--- Comment #7 from dharinih at yahoo dot com 2006-01-18 23:53 --- I am trying to build a cross compiler for host i686-pc-cygwin and target h8300-hms. I built binutils, bootstrap GCC and newlib successfully. ( using binutils-2.16, newlib-1.14.0 and gcc-3.4.4. When I build the final gcc using this configure command configure target=h8300-hms prefix=/usr/local --enable-languages=c,c++ --with-newlib --with-headers=../newlib-1.14.0/newlib/libc/include I get an internal compile error after about half hour of compiling in build_gcc/h8300-hms/h8300s/normal/libstdc++-v3/include/bits/locale_facets.tcc:702:internal compile error: in extract_inst, at recog.c:2083. I have tried to do the config without the --with-headers option and it always gets internal compile error at the same place. Can someone help me get past this. I have tried different versions of gcc code but always have some internal compile error at the last step. Thanks Dharini -- dharinih at yahoo dot com changed: What|Removed |Added CC||dharinih at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug tree-optimization/23282] [4.0 Regression] wrong results at -O on x86
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-01-18 23:31 --- Subject: Bug 23282 Author: rakdver Date: Wed Jan 18 23:31:16 2006 New Revision: 109920 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109920 Log: PR tree-optimization/23282 * tree-chrec.c (chrec_fold_multiply_poly_poly): Associate chrecs correctly. PR tree-optimization/23282 * gcc.c-torture/execute/pr23282.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/pr23282.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/tree-chrec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23282
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #31 from mark at codesourcery dot com 2006-01-18 23:28 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) steven at gcc dot gnu dot org wrote: > --- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08 > --- > We should at least avoid introducing a third variant of how we lay out these > nasty zero-sized friends. People actually use them. For example Wine uses > them to enforce compatible alignment and data layout with MS Windows > datastructure. Wine has a bunch of #ifdefs spread around in its sources to > make it work with the pre- and post-GCC 3.4 layout. Adding a third would > drive > those poor people nuts. I agree -- but I don't think we're talking about a third variant. Michael's patch looks to me like it will restore the pre-3.4 behavior, which everyone agrees makes more sense. My issue with respect to maximum_field_alignment doesn't really apply to pre-4.0 toolchains, since they didn't have default structure packing for targets, AFAICT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #17 from sigra at home dot se 2006-01-18 23:23 --- There is some good advice at http://www.gotw.ca/publications/advice98.htm which says that one should be const-correct and use const whenever possible. (But I do not suggest using const for return values.) This feature request is intended to help in that task. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08 --- We should at least avoid introducing a third variant of how we lay out these nasty zero-sized friends. People actually use them. For example Wine uses them to enforce compatible alignment and data layout with MS Windows datastructure. Wine has a bunch of #ifdefs spread around in its sources to make it work with the pre- and post-GCC 3.4 layout. Adding a third would drive those poor people nuts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #29 from mark at codesourcery dot com 2006-01-18 23:00 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) I think that we should do as follows. Preserve the original value of maximum_field_alignment when doing #pragma pack. Then, for zero-width bitfields, we should align to the minimum of the original maximum_field_alignment and the otherwise natural alignment. The difference between this and the last proposed patch is that I don't think we should entirely ignore maximum_field_alignment for zero-width bitfields; if "long long" as a field will only have (say) 2-byte alignment on some embedded target where structure-packing is the default, then a "long long : 0;" bitfield should only force 4-byte alignment. However, that's an abstract argument; I'm not actually sure what existing practice was with older versions of GCC. Again, in the abstract, I think the example in Comment #12 ought to have size 8 on both IA32 and AMD64 architectures. I can't see any good justification for size 12, with a PCC_BITFIELD_TYPES_MATTER ABI. And, I think that the size of the structure with #pragma pack(1) ought to be the same as with __attribute__((packed)). So, my concern with the patch in Comment #12 is that it would ignore the pre-set maximum_field_alignment on targets with default structure packing; other than that, I think it looks fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #16 from gdr at cs dot tamu dot edu 2006-01-18 22:37 --- Subject: Re: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | > Isn't this a task for lint-like tool? GCC isn't such thing. | | Are you sure? yes, there many lint stuff best handled in dedicated tools. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #15 from gdr at cs dot tamu dot edu 2006-01-18 22:35 --- Subject: Re: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | > It does not make any sense to require the compiler to give a warning | > in that case. | | Read the subject again: "optional" That is beside the point. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-01-18 22:25
---
In retrospect, I wonder if we should be complaining about a using-declaration
in a template in the first place.
For example, is:
struct X { void f(); };
template
struct S : public T {
using X::f;
};
actually invalid?
Both EDG and G++ complain about this (saying that X is not a base class of
S), but should that matter at this stage?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
[Bug target/23504] 22_locale/money_get/get/char/5.cc fails on ppc-darwin7. because libstdc++ believes long double returns works
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-18 21:55 --- I am going to mark this as depending on PR 25477 for now. I am almost ready to submit the patch for PR 25477 again. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25477 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23504
[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration
--- Comment #16 from mmitchel at gcc dot gnu dot org 2006-01-18 21:55
---
I'm still wrestling with this PR.
As I suggested earlier, I turned off the caching of nested-name-specifiers
unless we're in the check_dependency_p case. However, that causes
g++.dg/parse/operator2.C to fail, for essentially the opposite reason.
On:
template B::C::operator typename B::Y::X() const { return
0;\
}
we cache the check_dependency_p lookup for B::C, which is "typename
B::C". As a result, we don't enter the scope of B::C when looking up
names in the type-specifier following the operator.
I think that we could fix that in cp_paser_conversion_function_id (by using
resolve_typename_type), but I'm afraid that it's not really safe to cache
either version of the nested-name-specifier lookup, and then return it for the
other case of check_dependency_p.
Still thinking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
[Bug fortran/25850] gfortran - 8 testsuite failures on darwin
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-18 21:52 --- Part of this will be fixed by the patch for PR 25477. The other parts I submitted but I need to reply to the comments. There is two Fortran front-end parts so I am going to keep this as the fortran front-end bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25477 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug fortran/25850] gfortran - 8 testsuite failures on darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 21:51 --- Mine. All mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 GCC host triplet|powerpc-apple-darwin8.4.0 | GCC target triplet||powerpc-apple-darwin8.4.0 Last reconfirmed|-00-00 00:00:00 |2006-01-18 21:51:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug fortran/25850] New: gfortran - 8 testsuite failures on darwin
I cannot find were anyone else has submitted this as a bug - Test Run By dir on Wed Jan 18 13:21:27 2006 Native configuration is powerpc-apple-darwin8.4.0 === gfortran tests === Schedule of variations: unix Running target unix Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target. Using /Users/dir/gfortran/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/vect/vect.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ... === gfortran Summary === # of expected passes11299 # of unexpected failures8 # of expected failures 7 # of unsupported tests 42 /Users/dir/gfortran/ibin/gcc/testsuite/gfortran/../../gfortran version 4.2.0 20060118 (experimental) make: [check-gfortran] Error 1 (ignored) [dranta:~/gfortran/ibin/gcc] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.4.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060118 (experimental) -- Summary: gfortran - 8 testsuite failures on darwin Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug target/24547] Branch cost of -Os is ignored
--- Comment #2 from hjl at lucon dot org 2006-01-18 21:45 --- 4.2 is fixed by http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01029.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24547
[Bug libstdc++/25849] 8 byte memory leak using cerr with libpthread linked in
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-18 21:30 --- Also looking at the code: void* v = std::malloc(sizeof(__cxa_eh_globals)); if (v == 0 || __gthread_setspecific(init._M_key, v) != 0) std::terminate(); This is a false postive as we do free it in eh_globals_dtor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25849
[Bug libstdc++/25849] 8 byte memory leak using cerr with libpthread linked in
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 21:26 --- Can you first read: http://gcc.gnu.org/onlinedocs/libstdc++/debug.html#mem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25849
[Bug c++/25836] [3.4/4.0/4.1/4.2 Regression] G++ does not allow a conversion of templated types
--- Comment #4 from janis at gcc dot gnu dot org 2006-01-18 21:24 --- A regression hunt on powerpc-linux using the submitter's testcase identified the following very large patch: http://gcc.gnu.org/viewcvs?view=rev&rev=69130 r69130 | mmitchel | 2003-07-09 08:48:08 + (Wed, 09 Jul 2003) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25836
[Bug c++/25849] New: 8 byte memory leak using cerr with libpthread linked in
If you link in libpthread with a program that uses cerr, you leak 8 bytes of
memory (determined through Purify). I discovered this using a RHEL 3 WS box
and also had the same occur on a RHEL 4 AS box. This will not occur when you
use cout or clog in place of cerr, or if libpthread is not linked in.
Granted, 8 bytes is a small leak, but it still is a memory leak.
> cat test.cpp
#include
int main( int argc, char* argv[] )
{
std::cerr << "This is a message" << std::endl;
return 0;
}
> which purify
/usr/local/rational/releases/PurifyPlus.2003a.06.13.FixPack.0177/i386_linux2/bin/purify
> purify --version
Version 2003a.06.13 FixPack 0177 050331 Linux (32-bit)
> which g++
/app/gnu/gcc-4.0.1/bin/g++
> g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /gnu/gcc-4.0.1-src/configure --prefix=/gnu/gcc-4.0.1
Thread model: posix
gcc version 4.0.1
> uname -a
Linux testbox 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT 2005 i686 i686 i386
GNU/Linux
> purify g++ -o test test.cpp -lpthread
Purify 2003a.06.13 FixPack 0177 050331 Linux (32-bit) (c) Copyright IBM Corp.
1992, 2005 All rights reserved.
Instrumenting: crtbegin.o cctQmZeb.o
libgcc.a
crtend.o Linking
> test
[from PurifyPlus window]
Purify: Searching for all memory leaks...
Memory leaked: 8 bytes (100%); potentially leaked: 0 bytes (0%)
MLK: 8 bytes leaked at 0x80b4c10
* This memory was allocated from:
malloc [rtlib.o]
__cxa_get_globals [eh_globals.cc:115]
std::uncaught_exception( void) [eh_catch.cc:138]
std::basic_ostream< char,std::char_traights< char>> & std::operator
<<>(std::basic_ostream< char,std::char_traits< char>>
&, char const *) [ostream:405]
main [ccz2Vq3m.o]
__libc_start_main [libc.so.6]
Purify Heap Analysis (combining supressed and unsupressed blocks)
BlocksBytes
Leaked 18
Potentially Leaked 00
In-Use 00
-
Total Allocated 18
Along with the memory leak, Purify reported two categories of uninitialized
memory reads (UMR) that are normally suppressed. I wouldn't usually report
these, but they seem to be related (I performed some mild editing).
UMR: Uninitialized memory read (2 times):
* This is occurring while in thread -1224099488:
__pthread_initialize_minimal [libpthread.so.0]
call_initialize_minimal [libpthread.so.0]
_init [libpthread.so.0]
_dl_init []
_dl_start_user []
* Reading 4 bytes from 0xbfffdaac on the stack of thread -1224099488.
* Address 0xbfffdaac is 168 bytes below frame pointer in function
__pthread_initialize_minimal.
* Command-line: test
UMR: Uninitialized memory read (128 times):
* This is occurring while in thread -1224099488:
__gconv_transform_internal_ascii [libc.so.6]
wctob [libc.so.6]
std::ctype< wchar_t>::_M_initialize_ctype( void)
[ctype_members.cc:246]
std::ctype< wchar_t>::ctype( unsigned) [ctype.cc:91]
std::locale::_Impl::_Impl( unsigned) [locale_init.cc:304]
std::locale::_S_initialize_once( void) [locale_init.cc:143]
* Reading 4 bytes from 0xbfffd904 on the stack of thread -1224099488.
* Address 0xbfffd904 is 84 bytes below frame pointer in function
wctob.
--
Summary: 8 byte memory leak using cerr with libpthread linked in
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: loizeaux1 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25849
[Bug fortran/18540] Jumping into blocks gives error rather than warning
--- Comment #19 from tobi at gcc dot gnu dot org 2006-01-18 21:08 --- Fixed on the mainline. I will backport the cross-jumping part to 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
[Bug fortran/18937] quadratic behaviour with many label "spaghetti" code
--- Comment #9 from tobi at gcc dot gnu dot org 2006-01-18 21:07 --- The committed patch fixes only part of the problem, this is still a quadratic bottleneck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug fortran/18937] quadratic behaviour with many label "spaghetti" code
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-18 20:54 --- Subject: Bug 18937 Author: tobi Date: Wed Jan 18 20:54:49 2006 New Revision: 109914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109914 Log: PR fortran/18540 PR fortran/18937 * gfortran.h (BBT_HEADER): Move definition up. (gfc_st_label): Add BBT_HEADER, remove 'prev' and 'next'. * io.c (format_asterisk): Adapt initializer. * resolve.c (resolve_branch): Allow FORTRAN 66 cross-block GOTOs as extension. * symbol.c (compare_st_labels): New function. (gfc_free_st_label, free_st_labels, gfc_get_st_label): Convert to using balanced binary tree. * decl.c (match_char_length, gfc_match_old_kind_spec): Do away with 'cnt'. (warn_unused_label): Adapt to binary tree. * match.c (gfc_match_small_literal_int): Only set cnt if non-NULL. * primary.c (match_kind_param): Do away with cnt. Also converted the ChangeLog to use latin1 characters. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug fortran/18540] Jumping into blocks gives error rather than warning
--- Comment #18 from tobi at gcc dot gnu dot org 2006-01-18 20:54 --- Subject: Bug 18540 Author: tobi Date: Wed Jan 18 20:54:49 2006 New Revision: 109914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109914 Log: PR fortran/18540 PR fortran/18937 * gfortran.h (BBT_HEADER): Move definition up. (gfc_st_label): Add BBT_HEADER, remove 'prev' and 'next'. * io.c (format_asterisk): Adapt initializer. * resolve.c (resolve_branch): Allow FORTRAN 66 cross-block GOTOs as extension. * symbol.c (compare_st_labels): New function. (gfc_free_st_label, free_st_labels, gfc_get_st_label): Convert to using balanced binary tree. * decl.c (match_char_length, gfc_match_old_kind_spec): Do away with 'cnt'. (warn_unused_label): Adapt to binary tree. * match.c (gfc_match_small_literal_int): Only set cnt if non-NULL. * primary.c (match_kind_param): Do away with cnt. Also converted the ChangeLog to use latin1 characters. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #14 from sigra at home dot se 2006-01-18 20:49 --- > Isn't this a task for lint-like tool? GCC isn't such thing. Are you sure? http://directory.fsf.org/GNU/gcc.html says: "GCC provides many levels of source code error checking traditionally provided by other tools (such as lint)" Since GCC is the tool that is best at reading and understanding the sourcecode, I assume that it is best suited for source code diagnosis. What tool are you thinking of for C++? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #13 from sigra at home dot se 2006-01-18 20:41 --- > It does not make any sense to require the compiler to give a warning > in that case. Read the subject again: "optional" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #12 from gdr at cs dot tamu dot edu 2006-01-18 20:33 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| --- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
| > On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
| >
| > > --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
| > > ---
| > > (In reply to comment #3)
| > >> const does nothing when it comes to local variables except for not
| > >> letting you
| > >> touch it in other expressions. It does nothing for optimizations or
| > >> anything
| > >> else.
| > >
| > > This last point is not obvious at all, in my opinion. Why not? In
| > > principle,
| > > certainly const-ness *can* help optimizers one way or the other. Is
| > > this just a
| > > current limitation? A design choice? Anything in the standard making
| > > that
| > > tricky? I would like to know more.
| >
| >
| > int f(const int *a, int *b)
| > {
| >*b = 1;
| >return *a;
| > }
| >
| > a and b can alias and there is no way around that at all because that is
| > what the C++ standard says.
|
| In this case the compiler should warn because a could be declared "const int
*
| const" and b could be declared "int * const".
It does not make any sense to require the compiler to give a warning
in that case.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| --- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
| > On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
| >
| > > --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
| > > ---
| > > (In reply to comment #3)
| > >> const does nothing when it comes to local variables except for not
| > >> letting you
| > >> touch it in other expressions. It does nothing for optimizations or
| > >> anything
| > >> else.
| > >
| > > This last point is not obvious at all, in my opinion. Why not? In
| > > principle,
| > > certainly const-ness *can* help optimizers one way or the other. Is
| > > this just a
| > > current limitation? A design choice? Anything in the standard making
| > > that
| > > tricky? I would like to know more.
| >
| >
| > int f(const int *a, int *b)
| > {
| >*b = 1;
| >return *a;
| > }
| >
| > a and b can alias and there is no way around that at all because that is
| > what the C++ standard says.
|
| In this case the compiler should warn because a could be declared "const int *
| const" and b could be declared "int * const".
It does not make any sense to require the compiler to give a warning
in that case.
-- Gaby
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #11 from gdr at cs dot tamu dot edu 2006-01-18 20:30 --- Subject: Re: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | std::cout << static_cast(t) << std::endl; | } | | If "static_cast" would work, the compiler should warn. given call-by-value, you must be joking. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes: | std::cout << static_cast(t) << std::endl; | } | | If "static_cast" would work, the compiler should warn. given call-by-value, you must be joking. -- Gaby
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #10 from gdr at cs dot tamu dot edu 2006-01-18 20:29 --- Subject: Re: New: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | Declaring variables and parameters as constants is a very useful feature that | should be used as much as possible. Therefore it would be very useful to have | an option to warn when something is not declared as constant eventhough it | could be, at least in C++ and probably in other languages as well. Isn't this a task for lint-like tool? GCC isn't such thing. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug middle-end/23488] [4.1/4.2 Regression] GCSE load PRE does not work with non sets
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-18 20:26 --- Hmm, we actually produce better code on the mainline for my example in comment #2: _xtermEnvEncoding1: movl_result.1525, %edx movl$2, %eax pushl %ebp movl%esp, %ebp popl%ebp testl %edx, %edx cmovne _result.1525, %eax movl%eax, _result.1525 ret But that is does not fix the problem in comment #0. Load PRE on the tree level is not working because this is not an indirect reference to the variable. That is a known issue too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end GCC target triplet|i686-pc-linux.-gnu |i686-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug bootstrap/25842] Error in building libiberty
--- Comment #2 from dj at redhat dot com 2006-01-18 20:23 --- Subject: Re: New: Error in building libiberty Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
[Bug rtl-optimization/25848] missed-rtl-optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 20:08 --- Hmm, I don't think so as slwi only acts on the lower 32bits so the upper 32bits have the same sign as before which might be invalid if the b+a overflows. Actually optimial is: _f1: slwi r0,r3,1 add r0,r0,r3 extsw r3,r0 blr No extra move. The extsw is to extend the return value to 64bits as required by the ABI. In fact I can think of different cases where this would cause issues. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.5 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25848
[Bug libgcj/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #12 from hjl at gcc dot gnu dot org 2006-01-18 20:04 --- Subject: Bug 25840 Author: hjl Date: Wed Jan 18 20:04:50 2006 New Revision: 109909 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109909 Log: 2006-01-18 H.J. Lu <[EMAIL PROTECTED]> PR libgcj/25840 * include/x86_64-signal.h (RESTORE2): Add ".text\n". Modified: trunk/libjava/ChangeLog trunk/libjava/include/x86_64-signal.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug rtl-optimization/25848] New: missed-rtl-optimization
This C example:
int f1(int a)
{
int b = a*2;
return b+a;
}
---
Currently we produce:
_f1:
mr 0,3
slwi 3,3,1
add 3,3,0
extsw 3,0
blr
-
We should be able to produce:
_f1:
mr 0,3
slwi 3,3,1
add 3,0,3
blr
,so the "extsw" instruction should go out.
--
Summary: missed-rtl-optimization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dtemirbulatov at gmail dot com
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25848
[Bug libgcj/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #11 from hjl at lucon dot org 2006-01-18 19:48 --- I am testing this patch now: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01192.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug libgcj/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-18 19:39 --- (In reply to comment #9) > Looks at interpret.s This is a bug in java-signal.h: # 61 "./include/java-signal.h" asm ( ".byte 0 # Yes, this really is necessary\n" ".align 16\n" "__" "restore_rt" ":\n" " movq $" "15" ", %rax\n" " syscall\n" ); There is no .text in the source in the first place so we were just getting lucky before. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #9 from hjl at lucon dot org 2006-01-18 19:34 --- Looks at interpret.s .Ldebug_line0: .text .Ltext0: .section.ctors,"aw",@progbits .align 8 .quad _GLOBAL__I__Jv_soleInterpreterEngine #APP .byte 0 # Yes, this really is necessary .text is missing here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-18 19:33 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
> > int f(const int *a, int *b)
> > {
> >*b = 1;
> >return *a;
> > }
> >
> > a and b can alias and there is no way around that at all because that is
> > what the C++ standard says.
>
> In this case the compiler should warn because a could be declared "const int *
> const" and b could be declared "int * const".
That still does not change the fact that a could point to the same location as
b is pointing too.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
> > int f(const int *a, int *b)
> > {
> >*b = 1;
> >return *a;
> > }
> >
> > a and b can alias and there is no way around that at all because that is
> > what the C++ standard says.
>
> In this case the compiler should warn because a could be declared "const int *
> const" and b could be declared "int * const".
That still does not change the fact that a could point to the same location as
b is pointing too.
-- Pinski
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-18 19:31 --- Both prims.o and interpret.o are created from C++ code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-18 19:30 ---
Hmm:
interpret.o: file format elf64-x86-64
Contents of section .ctors:
0010 48c7c00f 000f 05 H
prims.o: file format elf64-x86-64
Contents of section .ctors:
0010 48c7c00f 000f 05 H
Those are the two ctors might have caused this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
> On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
>
> > --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
> > ---
> > (In reply to comment #3)
> >> const does nothing when it comes to local variables except for not
> >> letting you
> >> touch it in other expressions. It does nothing for optimizations or
> >> anything
> >> else.
> >
> > This last point is not obvious at all, in my opinion. Why not? In
> > principle,
> > certainly const-ness *can* help optimizers one way or the other. Is
> > this just a
> > current limitation? A design choice? Anything in the standard making
> > that
> > tricky? I would like to know more.
>
>
> int f(const int *a, int *b)
> {
>*b = 1;
>return *a;
> }
>
> a and b can alias and there is no way around that at all because that is
> what the C++ standard says.
In this case the compiler should warn because a could be declared "const int *
const" and b could be declared "int * const".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug target/25281] [3.4/4.0 only] Request fix for Bug #23150 (aka Bug #24675) in gcc 3.4.x and gcc 4.0.x for arm arch.
--- Comment #3 from armcc2000 at yahoo dot com 2006-01-18 19:28 --- (In reply to comment #2) > > Kazu, does your patch for PR 23150 apply to 4.0? If so, would you please > test that change? I think we've tried that already. Patch applies to 4.0.2 without problems, but is doesn't seem to alter the bug. See comment #5 in bug #24675 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25281
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #6 from hjl at lucon dot org 2006-01-18 19:23 --- It looks like gcc puts some junks in .ctors section: [EMAIL PROTECTED] .libs]$ objdump -s -j .ctors libgcj.so.7 libgcj.so.7: file format elf64-x86-64 Contents of section .ctors: 190c000 190c010 60cdfe00 `... 190c020 48c7c00f 000f 0500 H... 190c030 0021 . .. 190c040 48c7c00f 000f 0500 H... 190c050 d03f0101 10605101 .?...`Q. 190c060 20605101 30605101 `Q.0`Q. 190c070 40605101 50605101 @`Q.P`Q. 190c080 60605101 70605101 ``Q.p`Q. 190c090 80605101 90605101 .`Q..`Q. 190c0a0 a0605101 .`Q. The "0500" entry is bogus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug java/25847] libjava build doesn't stop when there is a fatal error
--- Comment #2 from hjl at lucon dot org 2006-01-18 19:14 --- It depends on what kind of failure. This "Segmentation fault" is due to a broken libgcj.so. It makes no senses to continue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25847
[Bug java/25847] libjava build doesn't stop when there is a fatal error
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 19:00 --- Lets look: ## We don't actually care if it fails -- if it does, just make an ## empty file. This is simpler than trying to discover when mmap is ## not available. so what is the problem here? This is not really a major failure really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25847
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #13 from pault at gcc dot gnu dot org 2006-01-18 18:59 --- Fixed on trunk and 4.1 Thanks and sorry Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug fortran/25024] ICE with external declaration inside same procedure
--- Comment #4 from pault at gcc dot gnu dot org 2006-01-18 18:59 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25024
[Bug fortran/20875] elemental function may not be pointer valued
--- Comment #3 from pault at gcc dot gnu dot org 2006-01-18 18:58 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20875
[Bug fortran/20869] EXTERNAL and INTRINSIC cannot be used together
--- Comment #7 from pault at gcc dot gnu dot org 2006-01-18 18:57 --- Fixed on trunk and 4.1 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20869
[Bug java/25847] New: libjava build doesn't stop when there is a fatal error
While investigating PR 25840, I notice that when there is a fatal error during libjava build, build doesn't stop. I found this in my build log: creating gcj-dbtool ./gcj-dbtool -n classmap.db || touch classmap.db creating gij /bin/sh: line 1: 17842 Segmentation fault ./gcj-dbtool -n classmap.db make[5]: Leaving directory `/export/build/gnu/gcc-next/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava' The problem is in libjava/Makefile.am: ## The .db file. This rule is only used for native builds, so it is ## safe to invoke gcj-dbtool. $(db_name): gcj-dbtool$(EXEEXT) ## In case it exists already. @rm -f $(db_name) ## We don't actually care if it fails -- if it does, just make an ## empty file. This is simpler than trying to discover when mmap is ## not available. ./gcj-dbtool -n $(db_name) || touch $(db_name) -- Summary: libjava build doesn't stop when there is a fatal error Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25847
[Bug fortran/25024] ICE with external declaration inside same procedure
--- Comment #3 from pault at gcc dot gnu dot org 2006-01-18 18:56 --- Subject: Bug 25024 Author: pault Date: Wed Jan 18 18:56:43 2006 New Revision: 109900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_present.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/external_procedures_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25024
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #12 from pault at gcc dot gnu dot org 2006-01-18 18:56 --- Subject: Bug 25785 Author: pault Date: Wed Jan 18 18:56:43 2006 New Revision: 109900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_present.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/external_procedures_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug fortran/20875] elemental function may not be pointer valued
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-18 18:56 --- Subject: Bug 20875 Author: pault Date: Wed Jan 18 18:56:43 2006 New Revision: 109900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_present.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/external_procedures_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20875
[Bug fortran/20869] EXTERNAL and INTRINSIC cannot be used together
--- Comment #6 from pault at gcc dot gnu dot org 2006-01-18 18:56 --- Subject: Bug 20869 Author: pault Date: Wed Jan 18 18:56:43 2006 New Revision: 109900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_present.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/external_procedures_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20869
[Bug fortran/20875] elemental function may not be pointer valued
--- Comment #1 from pault at gcc dot gnu dot org 2006-01-18 18:55 --- Subject: Bug 20875 Author: pault Date: Wed Jan 18 18:55:01 2006 New Revision: 109899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_present.f90 trunk/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20875
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #11 from pault at gcc dot gnu dot org 2006-01-18 18:55 --- Subject: Bug 25785 Author: pault Date: Wed Jan 18 18:55:01 2006 New Revision: 109899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_present.f90 trunk/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug fortran/25024] ICE with external declaration inside same procedure
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-18 18:55 --- Subject: Bug 25024 Author: pault Date: Wed Jan 18 18:55:01 2006 New Revision: 109899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_present.f90 trunk/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25024
[Bug fortran/20869] EXTERNAL and INTRINSIC cannot be used together
--- Comment #5 from pault at gcc dot gnu dot org 2006-01-18 18:55 --- Subject: Bug 20869 Author: pault Date: Wed Jan 18 18:55:01 2006 New Revision: 109899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_present.f90 trunk/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20869
[Bug ada/25844] [4.1/4.2 regression] Ada ICE (Regression) on overloaded renames
--- Comment #2 from laurent at guerby dot net 2006-01-18 18:49 --- With 4.0.2: $ gcc -c x-toolkit.adb x-toolkit.ads:590:04: this instantiation requires "Tgx.Lists (body)" x-toolkit.ads:590:04: but file "tgx-lists.adb" was not found With 4.1: $ gcc -c x-toolkit.adb +===GNAT BUG DETECTED==+ | 4.1.0 20060116 (prerelease) (i686-pc-linux-gnu) Assert_Failure atree.adb:812| | Error detected at x-toolkit.ads:1369:7 | With 4.2: $ gcc -c x-toolkit.adb +===GNAT BUG DETECTED==+ | 4.2.0 20060112 (experimental) (i686-pc-linux-gnu) Assert_Failure atree.adb:812| | Error detected at x-toolkit.ads:1369:7 | -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-01-18 18:49:05 date|| Summary|ICE (Regression) on |[4.1/4.2 regression] Ada ICE |overloaded renames |(Regression) on overloaded ||renames http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25844
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #5 from hjl at lucon dot org 2006-01-18 18:48 --- I found this in my build log creating gcj-dbtool ./gcj-dbtool -n classmap.db || touch classmap.db creating gij /bin/sh: line 1: 17842 Segmentation fault ./gcj-dbtool -n classmap.db make[5]: Leaving directory `/export/build/gnu/gcc-next/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava' Why doesn't libjava stop? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #4 from hjl at lucon dot org 2006-01-18 17:47 --- I rebuilt crt*.o* with -fno-toplevel-reorder -fno-unit-at-a-time and recreated lib*.so. I still have the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #3 from ian at airs dot com 2006-01-18 17:39 --- Building a cross-compiler did not shed any light on the problem. Can anybody provide more information about what is going wrong? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #2 from ian at airs dot com 2006-01-18 17:04 --- I just reconfirmed that I don't see any problems running the libjava testsuite on i686-pc-linux-gnu. And I don't have access to any x86_64 systems. So I can't recreate this problem myself. The backtrace suggests that there is some problem in the crt0 file. Can you please try building crtbegin.o and crtend.o with -fno-unit-at-a-time and with -fno-toplevel-reorder. I changed the default from the former to the latter. There shouldn't be any significant differences between the two. If there are, please let me know. I'll try building a cross-compiler to x86_64-linux to try this myself. I may run into header file problems; I'll see. -- ian at airs dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ian at airs dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-18 14:40:59 |2006-01-18 17:04:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug target/25731] Complex values passed in wrong registers
--- Comment #3 from danglin at gcc dot gnu dot org 2006-01-18 17:02 --- Fixed in 4.1. -- 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=25731
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #10 from paulthomas2 at wanadoo dot fr 2006-01-18 16:45 --- Subject: Re: [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length Dale, > >I am sorry that I upset you. It was completely unintentional. > > > I upset myself; you were just the trigger! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
--- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
---
(In reply to comment #3)
const does nothing when it comes to local variables except for not
letting you
touch it in other expressions. It does nothing for optimizations or
anything
else.
This last point is not obvious at all, in my opinion. Why not? In
principle,
certainly const-ness *can* help optimizers one way or the other. Is
this just a
current limitation? A design choice? Anything in the standard making
that
tricky? I would like to know more.
int f(const int *a, int *b)
{
*b = 1;
return *a;
}
a and b can alias and there is no way around that at all because that is
what the C++ standard says.
-- Pinski
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-18 16:29 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
> --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
> ---
> (In reply to comment #3)
>> const does nothing when it comes to local variables except for not
>> letting you
>> touch it in other expressions. It does nothing for optimizations or
>> anything
>> else.
>
> This last point is not obvious at all, in my opinion. Why not? In
> principle,
> certainly const-ness *can* help optimizers one way or the other. Is
> this just a
> current limitation? A design choice? Anything in the standard making
> that
> tricky? I would like to know more.
int f(const int *a, int *b)
{
*b = 1;
return *a;
}
a and b can alias and there is no way around that at all because that is
what the C++ standard says.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
