[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #7 from dick_guertin at yahoo dot com 2006-01-17 08:33 --- Response to: ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] Program received signal SIGILL, Illegal instruction. 0x00297064 in hex_to_character () Could you post an excerpt of the assembly code around 0x00297064? It really doesn't do any good. You're assuming hex_to_chararacter is 'entered' normally. It is NOT. The corrupt stack causes a branch into the middle of that routine, which is why the system reports an illegal instruction. Below is a NEXT-by-NEXT trace leading to the failure. This was accomplished with a -O2 and -g combination when compiling the source. Note several 'backups' and 'repeated' statements, ending in the failure. Starting program: /afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge Breakpoint 1, EDTBASE () at comm.c:3613 3613 NSCAN (); (gdb) next 3614 L_00ECA: I_L(R14,(R11+0x08C)); (gdb) next 3615 L_00ECE: I_SH(R13,(DATA+0x020A)); (gdb) next 3614 L_00ECA: I_L(R14,(R11+0x08C)); (gdb) next 3615 L_00ECE: I_SH(R13,(DATA+0x020A)); (gdb) next 3616 L_00ED2: I_MVC(4,(R14+0x028),(R13)); (gdb) next 3615 L_00ECE: I_SH(R13,(DATA+0x020A)); (gdb) next 3616 L_00ED2: I_MVC(4,(R14+0x028),(R13)); (gdb) next 3615 L_00ECE: I_SH(R13,(DATA+0x020A)); (gdb) next 3616 L_00ED2: I_MVC(4,(R14+0x028),(R13)); (gdb) next 3616 L_00ED2: I_MVC(4,(R14+0x028),(R13)); (gdb) next 3616 L_00ED2: I_MVC(4,(R14+0x028),(R13)); (gdb) next 3616 L_00ED2: I_MVC(4,(R14+0x028),(R13)); (gdb) next 3617 L_00ED8: I_MVC(4,(R14+0x024),(R13+0x04)); (gdb) next 3618 L_00EDE: I_MVC(4,(R14+0x020),(R13+0x08)); (gdb) next 3619 L_00EE4: I_LTR(R15,R15); (gdb) next 3620 L_00EE6: I_L(R14,(R11+0x08C)); (gdb) next 3619 L_00EE4: I_LTR(R15,R15); (gdb) next 3620 L_00EE6: I_L(R14,(R11+0x08C)); (gdb) next 3621 L_00EEA: I_L(R1,(R14)); (gdb) next 3622 L_00EEE: I_L(R0,(R14+0x04)); (gdb) next 3623 L_00EF2: I_SR(R14,R14); (gdb) next 3625 SCINIT (); (gdb) next 3626 L_00EF6: I_L(R14,(R11+0x08C)); (gdb) next 3627 L_00EFA: I_SH(R13,(DATA+0x020C)); (gdb) next 3626 L_00EF6: I_L(R14,(R11+0x08C)); (gdb) next 3627 L_00EFA: I_SH(R13,(DATA+0x020C)); (gdb) next 3628 L_00EFE: I_MVC(176,(R14),(R13)); (gdb) next 3627 L_00EFA: I_SH(R13,(DATA+0x020C)); (gdb) next 3628 L_00EFE: I_MVC(176,(R14),(R13)); (gdb) next 3627 L_00EFA: I_SH(R13,(DATA+0x020C)); (gdb) next 3628 L_00EFE: I_MVC(176,(R14),(R13)); (gdb) next 3627 L_00EFA: I_SH(R13,(DATA+0x020C)); (gdb) next 3628 L_00EFE: I_MVC(176,(R14),(R13)); (gdb) next 3629 L_00F04: I_L(R14,(R11+0x08C)); (gdb) next 3630 L_00F08: I_XC(176,(R14),(R14)); (gdb) next 3631 L_00F0E: I_SR(R14,R14); (gdb) next 3632 L_00F10: I_LA(R1,(R11+0x0242)); (gdb) next 3633 L_00F14: I_LH(R0,(R11+0x0240)); (gdb) next 3631 L_00F0E: I_SR(R14,R14); (gdb) next 3633 L_00F14: I_LH(R0,(R11+0x0240)); (gdb) next 3631 L_00F0E: I_SR(R14,R14); (gdb) next 3632 L_00F10: I_LA(R1,(R11+0x0242)); (gdb) next 3633 L_00F14: I_LH(R0,(R11+0x0240)); (gdb) next 3634 L_00F18: I_L(R14,(R11+0x08C)); (gdb) next 3635 L_00F1C: I_ST(R1,(R14)); (gdb) next 3636 L_00F20: I_ST(R0,(R14+0x04)); (gdb) next 3637 L_00F24: I_SR(R14,R14); (gdb) next 3638 L_00F26: I_L(R1,(R11+0x08C)); (gdb) next 3637 L_00F24: I_SR(R14,R14); (gdb) next 3638 L_00F26: I_L(R1,(R11+0x08C)); (gdb) next 3639 L_00F2A: I_SR(R0,R0); (gdb) next 3640 L_00F2C: I_L(R14,(R11+0x08C)); (gdb) next 3639 L_00F2A: I_SR(R0,R0); (gdb) next 3640 L_00F2C: I_L(R14,(R11+0x08C)); (gdb) next 3641 L_00F30: I_MVC(4,(R13),(R14+0x028)); (gdb) next 3642 L_00F36: I_MVC(4,(R13+0x04),(R14+0x024)); (gdb) next 3643 L_00F3C: I_MVC(4,(R13+0x08),(R14+0x020)); (gdb) next 3644 L_00F42: I_LA(R13,(R13+0x0C)); (gdb) next 3645 L_00F46: I_ST(R0,(R1+0x024)); (gdb) next 3646 L_00F4A: I_ST(R0,(R1+0x020)); (gdb) next 3647 R14 = (long int)((char *)( PRT )); (gdb) next 3646 L_00F4A: I_ST(R0,(R1+0x020)); (gdb) next 3647 R14 = (long int)((char *)( PRT )); (gdb) next 3648 L_00F4E: I_ST(R14,(R1+0x028)); (gdb) next 3650 NSCAN (); (gdb) next Program received signal SIGILL, Illegal instruction. 0x00296fec in hex_to_character () (gdb) === We need a preprocessed testcase, preferably a runnable testcase but a compilable one is sufficient if you can pinpoint the miscompilation. This program is too big for me to create a testcase. I have no idea where execution is going, only the final failure, which doesn't even allow 'gdb' to know 'where' we are. The stack is corrupted. I was able to determine EDTBASE was the last function in control, but have no idea what clobbers the stack. As you can see from the code, it is pseudo-assembler from an IBM/360 being done in C using macros that create
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-01-17 08:47 --- You're assuming hex_to_chararacter is 'entered' normally. It is NOT. The corrupt stack causes a branch into the middle of that routine, which is why the system reports an illegal instruction. Ah, thanks for the clarification. Looks pretty nasty indeed. Below is a NEXT-by-NEXT trace leading to the failure. I think a real, native backtrace would be more useful, on SPARC for example. This program is too big for me to create a testcase. I have no idea where execution is going, only the final failure, which doesn't even allow 'gdb' to know 'where' we are. Then we are in a dead end because if you, developer/hacker/user of the program, cannot pinpoint the source of the ill-execution, we cannot either. We have neither the time nor the resources to debug every miscompiled program; you have to do half of the work, we'll do the other half. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
Re: [Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
OK? Assuming you add a proper ??? comment explaining why we use an alignment of 8 in this file (basically summarizing this PR), this is OK. 2006-01-16 John David Anglin [EMAIL PROTECTED] PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Index: s-osinte-linux-hppa.ads === --- s-osinte-linux-hppa.ads (revision 109788) +++ s-osinte-linux-hppa.ads (working copy) @@ -508,7 +508,7 @@ lock : lock_array; end record; pragma Convention (C, atomic_lock_t); - for atomic_lock_t'Alignment use 16; + for atomic_lock_t'Alignment use 8; type struct_pthread_fast_lock is record spinlock : atomic_lock_t;
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #16 from charlet at adacore dot com 2006-01-17 08:56 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** OK? Assuming you add a proper ??? comment explaining why we use an alignment of 8 in this file (basically summarizing this PR), this is OK. 2006-01-16 John David Anglin [EMAIL PROTECTED] PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Index: s-osinte-linux-hppa.ads === --- s-osinte-linux-hppa.ads (revision 109788) +++ s-osinte-linux-hppa.ads (working copy) @@ -508,7 +508,7 @@ lock : lock_array; end record; pragma Convention (C, atomic_lock_t); - for atomic_lock_t'Alignment use 16; + for atomic_lock_t'Alignment use 8; type struct_pthread_fast_lock is record spinlock : atomic_lock_t; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
Problem with Trampolines initialization
Hello everyone, I have a doubt reagarding these trampolines, When i was going through the details in an atricle named GCC-INTERNALS, It said that we have a macro with the following name TRAMPOLINE_ADJUST_ADDRESS (addr). The explaination to it said that this is used mainly to perform any machine-specific adjustment in the address of the trampoline. addr holds the address that was passed to INITIALIZE_TRAMPOLINE. In case the address to be used for a function call should be different from the address in which the template was stored, the different address should be assigned to addr. If this macro is not defined, addr will be used for function calls. If this macro is not defined, by default the trampoline is allocated as a stack slot. This default is right for most machines. The exceptions are machines where it is impossible to execute instructions in the stack area. On such machines, you may have to implement a separate stack, using this macro in conjunction with TARGET_ASM_FUNCTION_PROLOGUE and TARGET_ASM_FUNCTION_EPILOGUE. Now, the problem is with the lines in bold , that when TRAMPOLINE_INITIALIZE is used then at that time, where is the trampoline allocated. From whatever i understood, i First the initialisation macro is used ii then the tramp..._adjust_addr... is used. What if we dont define ii then in that case during initialisation where would it be by default ? Also, these trampolines are doing two jobs, loading of the static chain regs jump to real addr of nested funcs This code is present on the stack by default. Can I have the pleasure to have a look at that piece of code at run time, ya this code is generated by gcc, any suggestions for getting to the code which is responsible for generating the code for these trampolines. -- Regards, Sandeep A candle loses nothing if it is used to light another one!
[Bug c/25682] [4.0/4.1/4.2 Regression] ICE when using old sytle offsetof (with non zero start) as array size
--- Comment #6 from jakub at gcc dot gnu dot org 2006-01-17 09:58 --- Subject: Bug 25682 Author: jakub Date: Tue Jan 17 09:57:56 2006 New Revision: 109812 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109812 Log: PR c/25682 * c-typeck.c (build_unary_op): Fold offsetof-like expressions even when the pointer is not NULL. cp/ * decl.c (compute_array_index_type): After issuing not an integral constant-expression error, set size to 1 to avoid ICEs later on. testsuite/ * gcc.dg/pr25682.c: New test. * g++.dg/parse/array-size2.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/array-size2.C trunk/gcc/testsuite/gcc.dg/pr25682.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25682
[Bug c/25682] [4.0/4.1/4.2 Regression] ICE when using old sytle offsetof (with non zero start) as array size
--- Comment #7 from jakub at gcc dot gnu dot org 2006-01-17 10:00 --- Subject: Bug 25682 Author: jakub Date: Tue Jan 17 10:00:05 2006 New Revision: 109813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109813 Log: PR c/25682 * c-typeck.c (build_unary_op): Fold offsetof-like expressions even when the pointer is not NULL. cp/ * decl.c (compute_array_index_type): After issuing not an integral constant-expression error, set size to 1 to avoid ICEs later on. testsuite/ * gcc.dg/pr25682.c: New test. * g++.dg/parse/array-size2.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/array-size2.C branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr25682.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/c-typeck.c branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25682
[Bug fortran/25219] [GOMP] ICE with SAVE attribute and (FIRST|LAST)PRIVATE
--- Comment #6 from jakub at gcc dot gnu dot org 2006-01-17 10:56 --- Subject: Bug 25219 Author: jakub Date: Tue Jan 17 10:56:29 2006 New Revision: 109816 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109816 Log: PR fortran/25219 * testsuite/libgomp.fortran/pr25219.f90: New test. Added: branches/gomp-20050608-branch/libgomp/testsuite/libgomp.fortran/pr25219.f90 Modified: branches/gomp-20050608-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25219
[Bug tree-optimization/25809] missed PRE optimization - move invariant casts out of loops
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-17 11:47 --- Confirmed. LIM could do it also, and it looks like its a full redundancy even. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-17 11:47:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25809
[Bug c++/25808] constant on rhs of conditional assignment
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-01-17 11:51 --- I agree with Pinskia here - also the detection of a constant RHS is difficult and will cause followup PRs that we do not catch all cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25808
[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations
--- Comment #3 from Raimund dot Merkert at baesystems dot com 2006-01-17 12:32 --- I would not consider myself a beginner, but I'm no c++ language laywer either. Usually the problem will get caught as soon as you try to invoke a method, but if it's something like a guard object, without methods, then it can be a problem. This is such an infrequent event (I think it happened to me before, years ago) it's easy to forget about this rule and no amount of teaching about it in books will help ( and I do use the Stroustrup book ). I agree that it is probably hard to fix because it's a grammar problem, but might it be possible to warn about a locally unused declaration? Maybe it makes sense to warn about any local declaration (I've never really seen those)? Or maybe it's a statement that has no effect? Priority-wise, it's probably low considering the rare occurrence. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814
[Bug tree-optimization/25623] DOM messes up incoming frequencies for some BBs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 12:35 ---
Here is another testcase:
void rs6000_emit_move (int mode, int t, int tt)
{
if (t == 1)
if (mode != 2)
t = ();
if (t == 1)
if (mode != 2)
__builtin_abort ();
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||law at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25623
[Bug libstdc++/25815] [4.1 regression] libstdc++ testsuite: ext/pb_assoc/example/erase_if.cc execution test
--- Comment #3 from pcarlini at suse dot de 2006-01-17 12:53 --- Created an attachment (id=10657) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10657action=view) Draft for an aliasing issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug libstdc++/25815] [4.1 regression] libstdc++ testsuite: ext/pb_assoc/example/erase_if.cc execution test
--- Comment #4 from pcarlini at suse dot de 2006-01-17 12:55 --- Can you check whether this patch helps you in any way? Is the only pending issue I'm aware of in the involved code and we are going to have something similar anyway. -fno-strict-aliasing should also tell you something. -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug libstdc++/25815] [4.1 regression] libstdc++ testsuite: ext/pb_assoc/example/erase_if.cc execution test
--- Comment #5 from pcarlini at suse dot de 2006-01-17 13:00 --- By the way, no need to run the entire testsuite: example/erase_if.cc can be compiled and run standalone as-is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug libgcj/25816] [4.1/4.2 Regression] Configure detects TLS, but glibc does not support it.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 13:24 --- Oh, this is a regression because the more use of TLS in the libraries. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|java|libgcj Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-17 13:24:17 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25816
[Bug tree-optimization/25809] missed PRE optimization - move invariant casts out of loops
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-01-17 14:27 --- Subject: Re: missed PRE optimization - move invariant casts out of loops rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-17 11:47 --- Confirmed. LIM could do it also, and it looks like its a full redundancy even. Well, PRE certainly can't sink the one assignment out the bottom, but it should be able to move the one to the top :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25809
[Bug rtl-optimization/25799] [4.2 Regression] cc1 stalled with -O1 -fmodulo-sched
--- Comment #5 from zadeck at gcc dot gnu dot org 2006-01-17 14:34 --- Subject: Bug 25799 Author: zadeck Date: Tue Jan 17 14:34:50 2006 New Revision: 109818 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109818 Log: 2005-01-17 Kenneth Zadeck [EMAIL PROTECTED] PR dataflow/25799 * df-problems.c (df_ru_confluence_n, df_rd_confluence_n): Corrected confluence operator to remove bits from op2 before oring with op1 rather than removing bits from op1. * (df_ru_transfer_function): Corrected test on wrong bitmap which caused infinite loop. Modified: branches/dataflow-branch/gcc/ChangeLog.dataflow branches/dataflow-branch/gcc/df-problems.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25799
[Bug fortran/25818] New: Problem with handling optional and entry master arguments
PROGRAM TSBVSL CALL NRANIN(54321.) END SUBROUTINE NRAN(VECTOR,N) DIMENSION VECTOR(N) DO I=1,N VECTOR(I) = RNDM(I) END DO RETURN ENTRY NRANIN (V) CALL RDMIN(V) RETURN END SUBROUTINE RDMIN(V) END REAL FUNCTION RNDM(I) RNDM=I END is miscompiled on x86_64-linux at -O and higher. The problem is that gfc_trans_deferred_vars emits some code e.g. to compute array argument's ubound and this happens before the entry master switch, so the the N argument pointer might be NULL. I think we should: a) in gfc_sym_type try harder for !sym-attr.optional sym-ns-proc_name-attr.entry_master to see whether build_reference_type (type) could be used by walking all entries and see if the argument is present in all the entries and not optional, then it can be reference_type b) probably use some flag set for all code emitted before the entry master switch which would cause all parameters to expand to p != NULL ? *p : 0 rather than just *p if p is POINTER_TYPE. -- Summary: Problem with handling optional and entry master arguments Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #7 from ssen at opendarwin dot org 2006-01-17 15:15 --- I think this should be done for both PowerPC and x86 targets for Darwin. The vendor compiler rejects nested functions for both targets presumably because of this, and so trampolines should enable stack execution for both targets -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #8 from gcc at microbizz dot nl 2006-01-17 15:30 --- Subject: Re: Trampolines fail on i686-apple-darwin because stack is not executable Currently it is not necessary for powerpc, but Apple may indeed change this in a future version of powerpc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug libfortran/25577] gfortran routine mvbits returns wrong answer.
--- Comment #4 from dir at lanl dot gov 2006-01-17 15:30 --- Opps, I think that the change suggested in Comment #1 actually does fix the problem on the LINUX version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25577
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
--- Comment #3 from meklund at cisco dot com 2006-01-17 15:36 ---
Subject: Re: feature request: generate a warning for sizeof on a pointer
Using the FreeBSD latest CVS pull on 10-Jan-06 (5.4 based), a build world
was run with the below modifications to GCC. The output was then evaluated
giving the following results.
22991 normal sizeof operations.
16564 sizeof(typedef) operations.
803 fu **x; sizeof(*x) operations.
396 fu *x; sizeof(x) operations.
40754 total
The 396 fu *x; sizeof(x) type operations were then examined. Note
that I am only concerning myself with the fu *x; sizeof(x)
operations. I'm no longer suggesting issuing warning for fu **x;
sizeof(*x), which are commonly used in the sizeof(m)/sizeof(*m)
mentioned in my previous reply. The fu *x; sizeof(x) operations are
broken down into the following categories:
1. (229) Calls within auto-generated files (mostly from cc_tools/gt*.[ch])
2. (74) Calls involving DEPRECATED_REGISTER_GDBARCH_SWAP macro
3. (59) Calls like read(n, i, sizeof(i)) or bcopy(x, i, sizeof(i))
4. (8) Misc seemingly correct calls.
5. (26) Likely bugs.
The likely bugs are listed after the below patch.
This means that 6.6% of what I want to display as optional warnings in well
established code is actually bugs. If the auto-generated files are ignored,
15.6% were bugs.
--- c-common.c 2006/01/10 15:42:38 1.2
+++ c-common.c 2006/01/11 15:43:06
@@ -5905,4 +5905,17 @@
error (%s, string);
}
+FILE *
+create_sizeof_stats_file(void)
+{
+ static FILE *sizeof_stats = NULL;
+ if (!sizeof_stats) {
+char *sizeof_stats_fname = alloca(strlen(dump_base_name + 2 +
+ sizeof(.sizeof)));
+sprintf(sizeof_stats_fname, %s.sizeof, dump_base_name);
+sizeof_stats = fopen(sizeof_stats_fname, w);
+ }
+ return sizeof_stats;
+}
+
#include gt-c-common.h
--- c-common.h 2006/01/10 15:42:38 1.2
+++ c-common.h 2006/01/11 15:43:07
@@ -1330,4 +1330,6 @@
extern void pp_file_change (const struct line_map *);
extern void pp_dir_change (cpp_reader *, const char *);
+extern FILE * create_sizeof_stats_file(void);
+
#endif /* ! GCC_C_COMMON_H */
--- c-parse.in 2006/01/10 15:42:38 1.2
+++ c-parse.in 2006/01/11 16:43:30
@@ -518,9 +518,30 @@
if (TREE_CODE ($2) == COMPONENT_REF
DECL_C_BIT_FIELD (TREE_OPERAND ($2, 1)))
error (`sizeof' applied to a bit-field);
+ static FILE *sizeof_stats = NULL;
+ sizeof_stats = create_sizeof_stats_file();
+ if (TREE_CODE (TREE_TYPE ($2)) == POINTER_TYPE) {
+ if (TREE_CODE($2) == VAR_DECL) {
+ fprintf(sizeof_stats,
+ %s: %d: MWE3:`sizeof' applied to a pointer
+ variable\n, input_filename, input_line);
+ } else {
+ fprintf(sizeof_stats,
+ %s: %d: MWE2:`sizeof' reference\n,
+ input_filename, input_line);
+ }
+ } else {
+ fprintf(sizeof_stats,
+ %s: %d: MWE0:`sizeof' reference\n,
+ input_filename, input_line);
+ }
$$ = c_sizeof (TREE_TYPE ($2)); }
| sizeof '(' typename ')' %prec HYPERUNARY
{ skip_evaluation--;
+ static FILE *sizeof_stats = NULL;
+ sizeof_stats = create_sizeof_stats_file();
+ fprintf(sizeof_stats, %s: %d: MWE1:`sizeof' reference\n,
+ input_filename, input_line);
$$ = c_sizeof (groktypename ($3)); }
| alignof unary_expr %prec UNARY
{ skip_evaluation--;
---
/usr/src/gnu/usr.bin/binutils/readelf/../../../../contrib/binutils/binutils/readelf.c:
9569
Allocates too much memory. (Also, never frees it.)
---
int cnt;
/* Find the section header so that we get the size. */
while (sect-sh_type != SHT_MIPS_OPTIONS)
++sect;
eopt = get_data (NULL, file, options_offset, sect-sh_size,
_(options));
if (eopt)
{
* iopt = malloc ((sect-sh_size / sizeof (eopt)) * sizeof (*iopt));
if (iopt == NULL)
{
error (_(Out of memory));
return 0;
}
offset = cnt = 0;
option = iopt;
while (offset sect-sh_size)
---
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/jv-valprint.c: 113
Assumes a 4 byte pointer. See FIXME.
---
char *buf;
buf = alloca (TARGET_PTR_BIT / HOST_CHAR_BIT);
fputs_filtered (, , stream);
wrap_here (n_spaces (2));
if (i 0)
element = next_element;
else
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 16:04 --- There are a couple of issues here, first there is a missed optimization to sink the load (there is a bug about that). In fact this is all related to that bug. Also there is a front-end bug having the load there in the first place so confirmed. If you look to see what causes the two loads to become one, that would be FRE and that is only because the front-end is saying the first load is not zero. I bet we could get into real trouble with real optional arguments if this is not done correctly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-01-17 16:04:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #17 from hainque at adacore dot com 2006-01-17 16:29 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** John David Anglin wrote: As I understand the situation, fixing the above problem is quite involved. Indeed. I have dug out the patches involved when this was first attempted, and look into them again. This was back in June 2004, so a lot has changed since then. The problem is that the alignment provided by malloc is less than that needed for atomic_lock_t objects. This causes the ada runtime to round the pointer that it receives from malloc; but it doesn't retain the adjustment and the free operation has a 50% chance of failing. Close :) The problem as it currently stands is that the alignment required for atomic_lock_t is larger than BIGGEST_ALIGNMENT, which causes the compiler to generate special code to handle an allocation request from the default storage pool (aka bare malloc). Indeed the generated code arranges for the user visible address (the Ada allocator value) to be a multiple of the requested alignment by rounding up the malloc returned address, and the rounded value is erroneously passed back to free on deallocation request. The enclosed change is a work-around for the above problem. The linux libc code can accomodate an unaligned atomic_lock_t object under most circumstances. The main issue is that ada may detemine an incorrect struct layout. I have tested the above change on hppa-unknown-linux-gnu, 4.0 through trunk. Without this change, ada is essentially unusable. Thus, I recommend installing the change as a work-around until a proper fix can be developed. OK? - for atomic_lock_t'Alignment use 16; + for atomic_lock_t'Alignment use 8; Since it definitely enhances the situation according to your testing (thanks), I'd go for it with a ??? accompaning comment. I'll let Arno state the definite approval. It is not easy to ensure it is really OK because of ripple effects. It appears fine from the local osinte perspective: type lock_array is array (1 .. 4) of int; type atomic_lock_t is record lock : lock_array; end record; The base size is 16 bytes, and wouldn't change from an alignment upgrade to 16. type struct_pthread_fast_lock is record spinlock : atomic_lock_t; The field is at beginning here so there is no offset rounding mistake to fear, and the size is right so following fields are laid out identically. Besides, in type pthread_mutex_t is record m_reserved : int; m_count: int; m_owner: System.Address; m_kind : int; m_lock : struct_pthread_fast_lock; end record; the m_lock offset is a multiple of 16 here by virtue of the preceeding components (4 all 4 bytes long). Now, I think a 16 bytes alignment for atomic_lock_t would force a 16 bytes alignment for struct_pthread_fast_lock + pthread_mutex_t, and double checking the potential effects of that is fairly involved. Thanks for your feedback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #18 from charlet at adacore dot com 2006-01-17 16:33 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** I'll let Arno state the definite approval. As discussed live, I gave my OK this morning already, with the same comment about ??? ;-) Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/25819] New: CXF3A01 core dump
-bash-2.05b$ cd tests/cxf/cxf3a01 -bash-2.05b$ less *.log ,.,. CXF3A01 ACATS 2.5 06-01-17 04:01:09 CXF3A01 Check that the Valid function from package Ada.Text_IO.Editing returns False for strings that fail to comply with the composition constraints defined for picture strings. Check that the Valid function returns True for strings that conform to the composition constraints defined for picture strings. /test/gnu/gcc-4.0/gcc/gcc/testsuite/ada/acats/run_all.sh: 25833 Illegal instruct ion(coredump) -bash-2.05b$ gdb -c run/core tests/cxf/cxf3a01/cxf3a01 GNU gdb 6.4.50.20051230-cvs Copyright (C) 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as hppa2.0w-hp-hpux11.11... Core was generated by `cxf3a01'. Program terminated with signal 4, Illegal instruction. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. Reading symbols from /usr/lib/libc.2...done. Loaded symbols for /usr/lib/libc.2 Reading symbols from /usr/lib/libdld.2...done. Loaded symbols for /usr/lib/libdld.2 Reading symbols from /opt/graphics/OpenGL/lib/libogltls.sl...done. Loaded symbols for /opt/graphics/OpenGL/lib/libogltls.sl #0 0xc0197d50 in _sigfillset () from /usr/lib/libc.2 (gdb) bt #0 0xc0197d50 in _sigfillset () from /usr/lib/libc.2 #1 0xc019584c in _sscanf () from /usr/lib/libc.2 #2 0xc019b01c in malloc () from /usr/lib/libc.2 #3 0xc019b01c in malloc () from /usr/lib/libc.2 Previous frame identical to this frame (corrupt stack?) (gdb) disass 0xc0197d30 0xc0197d70 Dump of assembler code from 0xc0197d30 to 0xc0197d70: 0xc0197d30 _sigfillset+1904: ldi 2,r26 0xc0197d34 _sigfillset+1908: ldw -20(sp),r19 0xc0197d38 _sigfillset+1912: movb,tr r0,ret0,0xc0198154 _sigfillset+2964 0xc0197d3c _sigfillset+1916: ldw -114(sp),rp 0xc0197d40 _sigfillset+1920: cmpb,,n r9,r23,0xc0197d54 _sigfillset+1940 0xc0197d44 _sigfillset+1924: ldo 0(r31),r8 0xc0197d48 _sigfillset+1928: ldw 4(r8),r31 0xc0197d4c _sigfillset+1932: cmpb,,n r0,r31,0xc0197d40 _sigfillset+1920 0xc0197d50 _sigfillset+1936: ldw c(r31),r23 0xc0197d54 _sigfillset+1940: ldw c(r8),r26 0xc0197d58 _sigfillset+1944: cmpb,,n r26,r9,0xc0197d94 _sigfillset+2004 0xc0197d5c _sigfillset+1948: b,l 0xc0197e78 _sigfillset+2232,r0 0xc0197d60 _sigfillset+1952: ldw 10(r8),r7 0xc0197d64 _sigfillset+1956: ldw 60(r5),r22 0xc0197d68 _sigfillset+1960: ldo 8(r7),r25 0xc0197d6c _sigfillset+1964: ldw 54(r5),r20 End of assembler dump. (gdb) p/x $r31 $1 = 0x28 The faulting instruction attempted a load from page 0 causing the core dump. The core dump causes the testsuite for ada to terminate: Running chapter cxf ... make[1]: *** [check-gnat] Error 132 -- Summary: CXF3A01 core dump Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu 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=25819
[Bug tree-optimization/15459] [meta-bug] there should be a tree combiner like the rtl one
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-17 16:48 --- I don't have time for this bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15459
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-17 16:48 --- I don't have time for this bug at least right now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug libobjc/18764] segfault in libobjc when sending a message to a conflicting class
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-17 16:49 --- I don't have time for this bug at least right now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18764
[Bug target/24598] Need to support odcctools and its ablity to use --prefix and libtool
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-17 16:50 --- I don't have time for this bug at least right now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24598
[Bug objc/18255] [GNU runtime] Protocols are not initialized correctly
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-17 16:53 --- I have no time to update the patch right now, I might try to get to next week but I am going to unassign it for now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18255
[Bug objc/25361] vectors are not encoded
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-17 16:55 --- I am just going to fail this test, I have a patch which I need to double check and the commit. Unassigning for now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25361
[Bug testsuite/25764] gcc.dg/const-compare.c fails on i686-darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 17:06 --- Subject: Bug 25764 Author: pinskia Date: Tue Jan 17 17:06:40 2006 New Revision: 109826 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109826 Log: 2006-01-17 Andrew Pinski [EMAIL PROTECTED] PR testsuite/25764 * gcc.dg/const-compare.c: Restrict compiling to powerpc*-*-darwin*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/const-compare.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25764
[Bug testsuite/25764] gcc.dg/const-compare.c fails on i686-darwin
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-17 17:06 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25764
[Bug libgcj/25816] [4.1/4.2 Regression] Configure detects TLS, but glibc does not support it.
--- Comment #2 from daney at gcc dot gnu dot org 2006-01-17 17:31 --- My current patch is here: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00950.html -- daney at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25816
[Bug libstdc++/25823] New: --disable-hosted-libstdcxx causes build break
While trying to build the libstdc++ library with --disable-hosted-libstdcxx specified in the configure step, eh_alloc.cc fals to compile with an error that the line: extern C int memset (void *, int, std::size_t); declares memset different than it has already been declared. Changing the line to extern C void *memset (void *, int, std::size_t); resolves the problem. -- Summary: --disable-hosted-libstdcxx causes build break Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pedz at easesoftware dot net GCC build triplet: powerpc-ibm-aix5.3.0.0 GCC host triplet: powerpc-ibm-aix5.3.0.0 GCC target triplet: powerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #1 from pedz at easesoftware dot net 2006-01-17 17:42 --- Created an attachment (id=10658) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10658action=view) How configure was called -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #2 from pedz at easesoftware dot net 2006-01-17 17:43 --- Created an attachment (id=10659) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10659action=view) My Patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #3 from chris at bubblescope dot net 2006-01-17 18:09 --- Does that patch break other systems? (linux-x86 would seem the obvious thing to try..) -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug libstdc++/25824] New: --disable-hosted-libstdcxx causes build break in eh_globals.cc
While trying to build the libstdc++ library with --disable-hosted-libstdcxx specified in the configure step, eh_globals.cc fals to compile. Calls to std::free and std::malloc have not been defined. I do not have the error log. I can recreate it if it is really necessary. -- Summary: --disable-hosted-libstdcxx causes build break in eh_globals.cc Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pedz at easesoftware dot net GCC build triplet: powerpc-ibm-aix5.3.0.0 GCC host triplet: powerpc-ibm-aix5.3.0.0 GCC target triplet: powerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25824
[Bug libstdc++/25824] --disable-hosted-libstdcxx causes build break in eh_globals.cc
--- Comment #1 from pedz at easesoftware dot net 2006-01-17 18:21 --- Created an attachment (id=10660) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10660action=view) How configure was called -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25824
[Bug libstdc++/25824] --disable-hosted-libstdcxx causes build break in eh_globals.cc
--- Comment #2 from pedz at easesoftware dot net 2006-01-17 18:23 --- Created an attachment (id=10661) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10661action=view) My Patch I used the same style that eh_alloc.cc used by adding an ifdef and changing the calls in the code to just be free or malloc rather than std::free. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25824
[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key
--- Comment #18 from bero at arklinux dot org 2006-01-17 18:25 --- If I compile without the compiler flag settings and make bootstrap instead of profiledbootstrap, it throws the exception as expected rather than causing a SIGABRT. The cause is probably somewhere else in gcc; 4.0.2 works with the CFLAGS etc. I normally use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug bootstrap/25825] New: Add soft float to list of libraries
On AIX, a device driver or kernel extension can not use floating point. I did not see a way via the configure options to get libstdc++ built with a -msoft-float option. But there is an option to remove libraries from the list. So I changed t-aix52 to create versions of libstdc++ to use soft float by default with the thought that if anyone does not want them, they can delete them when the configure gcc. My suggested patch to t-aix52 is attached. While getting this change to compile and link, I encountered which appears to me to be more of a bug than an enhancement. ppc64-fp.c is needed will not compile without modifications. I have attached my path to it as well. -- Summary: Add soft float to list of libraries Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pedz at easesoftware dot net GCC build triplet: powerpc-ibm-aix5.3.0.0 GCC host triplet: powerpc-ibm-aix5.3.0.0 GCC target triplet: powerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25825
[Bug bootstrap/25825] Add soft float to list of libraries
--- Comment #1 from pedz at easesoftware dot net 2006-01-17 18:37 --- Created an attachment (id=10662) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10662action=view) Suggested patch to t-aix52 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25825
[Bug bootstrap/25825] Add soft float to list of libraries
--- Comment #2 from pedz at easesoftware dot net 2006-01-17 18:38 --- Created an attachment (id=10663) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10663action=view) Suggested patch to ppc64-fp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25825
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #4 from pedz at easesoftware dot net 2006-01-17 18:40 --- I have not tried it and do not have the equipment to try it except on a Mac. I can do that if it would help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #5 from pcarlini at suse dot de 2006-01-17 18:50 --- I have just completed succesfully a build on linux with both patches applied. Look fine to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #9 from dick_guertin at yahoo dot com 2006-01-17 19:01 --- First, I inherited this code from a co-worker who left the University. My assignment was to keep this code working because the University relies on it. Everything was fine until we went from 3.3.1 to 3.4.4, and then -O2 compilations of this code created a module that got execution failures. I've been trying to debug, but even 'gdb' is having troubles. I don't know what proprocessed source is. All I have is true source. I don't know how to do a native backtrack on a sparc, but would be willing to learn. I do know how to use 'gdb' to disas, examine variables, etc. If you don't have the time to track this, then help me do it. By the way, did you notice the -O2 and -g caused next executing linear (non-looping) statements to go like this: 3615, 3616, 3615, 3616, 3616, 3616, 3617, ...?? What's with that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #13 from laurent at guerby dot net 2006-01-17 19:02 --- http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00663.html cdda01 fails on s390-linux on 4.1 with tree-sra disabled. ,.,. CDD2A01 ACATS 2.5 06-01-16 19:32:21 CDD2A01 Check that the Read and Write attributes for a type extension are created from the parent type's attribute (which may be user-defined) and those for the extension components; also check that the default input and output attributes are used for a type extension, even if the parent type's attribute is user-defined. raised CONSTRAINT_ERROR : fdd2a00.adb:29 range check failed FAIL: cdd2a01 ,.,. CDD2A02 ACATS 2.5 06-01-16 19:32:25 CDD2A02 Check that the Read, Write, Input, and Output attributes are inherited for untagged derived types. raised CONSTRAINT_ERROR : fdd2a00.adb:29 range check failed FAIL: cdd2a02 -- laurent at guerby dot net changed: What|Removed |Added Summary|[4.2 Regression] ACATS |[4.1/4.2 Regression] ACATS |cdd2a02 fails at runtime|cdd2a01 cdd2a02 fail at ||runtime http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #6 from pcarlini at suse dot de 2006-01-17 19:08 --- If it's not abvious already to everyone, the reason the issue didn't show up before on linux is that, when _GLIBCXX_HOSTED is not defined we are *not* including cstring an no declaration conflicts with the wrong one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug c++/25826] New: pure virtual destructors accepted by GCC, but cause link failure
The following code:
class A
{
public:
virtual ~A() = 0;
};
class B : public A
{
public:
~B() {}
};
int main()
{
B b;
}
compiles with GCC 4.0.2 (clean with -ansi -Wall -Wextra) but does not link due
to an undefined reference to ~A(). Herb Sutter claims this code is valid, for
whatever that might be worth (http://www.gotw.ca/gotw/031.htm), but in either
case this seems to be a bug; either it should be rejected with a diagnostic as
invalid code, or it should link (and ideally do something sensible).
--
Summary: pure virtual destructors accepted by GCC, but cause
link failure
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
[Bug c++/25826] pure virtual destructors accepted by GCC, but cause link failure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 19:27 ---
You still need to declare A::~A().
That is what the following passage from that doc means:
Of course, any derived class' destructor must call the base class' destructor,
and so the destructor must still be defined (even if it's empty):
// file b.cpp
B::~B() { /* possibly empty */ }
If this definition were not supplied, you could still derive classes from B but
they could never be instantiated, which isn't particularly useful.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
[Bug bootstrap/25825] Add soft float to list of libraries
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-17 19:31 --- Did you try LIBCXXFLAGS and LIBCFLAGS? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25825
[Bug c++/25826] pure virtual destructors accepted by GCC, but cause link failure
--- Comment #2 from lloyd at randombit dot net 2006-01-17 19:32 --- Ah, I misread it, but the bug should stay open IMO - the invalidity of the code reduces it to GCC doesn't reject invalid code, which is obviously a low priority, but still a bug, no? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
[Bug c++/25826] pure virtual destructors accepted by GCC, but cause link failure
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-17 19:33 --- (In reply to comment #2) Ah, I misread it, but the bug should stay open IMO - the invalidity of the code reduces it to GCC doesn't reject invalid code, which is obviously a low priority, but still a bug, no? No, this is not invalid code. Just useless code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
[Bug other/22313] [4.1/4.2 Regression] profiledbootstrap is broken on the mainline and 4.1 branch
--- Comment #27 from bero at arklinux dot org 2006-01-17 19:34 --- Still breaks for me on 4.1 branch too (4.1 branch SVN ID 109831). Linux x86, binutils 2.16.91.0.4 The error is related but slightly different and on a different file these days: c-errors.c -o c-errors.o stage1/xgcc -Bstage1/ -B/usr/i586-ark-linux/bin/ -c -g -O2 -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include ../../gcc/c-lex.c -o c-lex.o /tmp/ccMLYhJE.s: Assembler messages: /tmp/ccMLYhJE.s:2979: Error: invalid sections for operation on `.LCFI22' and `.LCFI21' /tmp/ccMLYhJE.s:3048: Error: invalid sections for operation on `.LCFI38' and `.LCFI37' /tmp/ccMLYhJE.s:3242: Error: invalid sections for operation on `.LCFI76' and `.LCFI75' /tmp/ccMLYhJE.s:3279: Error: invalid sections for operation on `.LCFI83' and `.LCFI82' -- bero at arklinux dot org changed: What|Removed |Added Known to fail|4.2.0 |4.1.0 4.2.0 Known to work|4.1.0 |4.0.2 Summary|[4.2 Regression]|[4.1/4.2 Regression] |profiledbootstrap is broken |profiledbootstrap is broken |on the mainline |on the mainline and 4.1 ||branch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug other/22313] [4.1/4.2 Regression] profiledbootstrap is broken on the mainline and 4.1 branch
--- Comment #28 from bero at arklinux dot org 2006-01-17 19:35 --- Created an attachment (id=10664) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10664action=view) Preprocessed source of code triggering this in current 4.1 SVN -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline and 4.1 branch
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-01-17 19:36 --- (In reply to comment #27) Still breaks for me on 4.1 branch too (4.1 branch SVN ID 109831). Linux x86, binutils 2.16.91.0.4 Can you file a different bug and attach the .s file? Because I don't see this at all. Also can you try with a FSF release of binutils and not some hacked up version? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.0 4.2.0 |4.2.0 Known to work|4.0.2 |4.0.2 4.1.0 Summary|[4.1/4.2 Regression]|[4.2 Regression] |profiledbootstrap is broken |profiledbootstrap is broken |on the mainline and 4.1 |on the mainline and 4.1 |branch |branch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline and 4.1 branch
--- Comment #30 from bero at arklinux dot org 2006-01-17 19:36 --- Created an attachment (id=10665) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10665action=view) asm code generated by current 4.1 SVN -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug classpath/20198] java.security.CodeSource.getLocation output is different than expected
--- Comment #7 from tromey at gcc dot gnu dot org 2006-01-17 19:59 --- Subject: Bug 20198 Author: tromey Date: Tue Jan 17 19:59:29 2006 New Revision: 109837 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109837 Log: PR classpath/20198: * java/net/URLClassLoader.java (FileURLLoader): Added argument. (JarURLLoader): Likewise. (addURLImpl): Canonicalize file URLs. Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/java/net/URLClassLoader.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20198
[Bug fortran/25785] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #5 from dir at lanl dot gov 2006-01-17 20:07 --- This bug has now migrated into the 4.1 tree. Sometime after the 20060104 version Would it not be easier to elminate the offending updates rather than debug them ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug testsuite/25777] acats_run doesn't include gcc base directory in LD_LIBRARY_PATH
--- Comment #6 from laurent at guerby dot net 2006-01-17 20:13 --- Dave reported the patch fixed the problem -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25777
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-17 20:14 --- (In reply to comment #5) This bug has now migrated into the 4.1 tree. Sometime after the 20060104 version Would it not be easier to elminate the offending updates rather than debug them ? It might but since I only looked at this a little I don't know fully. Let me add Paul T. to the CC because I feel that his change for PRs 25029,21256, etc. caused this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Summary|gfortran - incorrectly |[4.1/4.2 Regression] |issues an error on tests for|gfortran - incorrectly |optional arguments with |issues an error on tests for |assumed length |optional arguments with ||assumed length Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug c++/25787] [4.2 Regression] ext/pb_assoc/example/ds_traits.cc compilation failed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-17 20:15 --- Does this work now since the bug which I pointed to has beend fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25787
[Bug c++/25787] [4.2 Regression] ext/pb_assoc/example/ds_traits.cc compilation failed
--- Comment #3 from pcarlini at suse dot de 2006-01-17 20:18 --- (In reply to comment #2) Does this work now since the bug which I pointed to has beend fixed? I think so, everything is fine in all my tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25787
[Bug middle-end/11135] It ought to be possible to make PIC_OFFSET_TABLE_REGNUM a pseudo
--- Comment #3 from rearnsha at gcc dot gnu dot org 2006-01-17 20:22 --- Subject: Bug 11135 Author: rearnsha Date: Tue Jan 17 20:22:19 2006 New Revision: 109839 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109839 Log: PR target/592 PR middle-end/11135 * arm.h (struct machine_function): Add pic_reg. * arm.c (arm_pic_register): Make unsigned. (arm_override_options): Only set arm_pic_register if TARGET_SINGLE_PIC_BASE. (use_return_insn): Only test for a pic register if it is fixed. (arm_compute_save_reg0_reg12_mask): Likewise. (thumb_compute_save_reg_mask): Likewise. (legitimate_pic_operand): Factor out some known invariants. (legitimize_pic_address): If we don't have a fixed pic register, then set up a pseudo in the function entry sequence. Handle the pic base being in a pseudo. (arm_load_pic_register): Handle the pic register being in a pseudo. (arm_expand_prologue): Only set up the pic register if it is fixed. (thumb_expand_prologue): Likewise. * arm.md (pic_load_addr_based): Handle the pic base being a pseudo. (pic_load_addr_based_insn): Likewise. (builtin_setjmp_receiver): Don't restore the pic base if it isn't fixed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11135
[Bug target/592] [ARM/Thumb] Poor choice of PIC register
--- Comment #7 from rearnsha at gcc dot gnu dot org 2006-01-17 20:22 --- Subject: Bug 592 Author: rearnsha Date: Tue Jan 17 20:22:19 2006 New Revision: 109839 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109839 Log: PR target/592 PR middle-end/11135 * arm.h (struct machine_function): Add pic_reg. * arm.c (arm_pic_register): Make unsigned. (arm_override_options): Only set arm_pic_register if TARGET_SINGLE_PIC_BASE. (use_return_insn): Only test for a pic register if it is fixed. (arm_compute_save_reg0_reg12_mask): Likewise. (thumb_compute_save_reg_mask): Likewise. (legitimate_pic_operand): Factor out some known invariants. (legitimize_pic_address): If we don't have a fixed pic register, then set up a pseudo in the function entry sequence. Handle the pic base being in a pseudo. (arm_load_pic_register): Handle the pic register being in a pseudo. (arm_expand_prologue): Only set up the pic register if it is fixed. (thumb_expand_prologue): Likewise. * arm.md (pic_load_addr_based): Handle the pic base being a pseudo. (pic_load_addr_based_insn): Likewise. (builtin_setjmp_receiver): Don't restore the pic base if it isn't fixed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=592
[Bug debug/25793] dwarf2 debug info lacks linkage names for constructors destructors
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-17 20:23 --- (In reply to comment #2) i) The reason why you are able to set a breakpoint here is the consequence of the testclass having only one single (non-trivial) constructor and no base class. The problem becomes aparent as soon as you add a second (non-trivial) constructor and call the wrong one, i.e. one that gdb is not aware of. As far as I know, g++ generates more than one subroutine per constructor (is this correct?) and gdb does not know *where* to set the breakpoint. Unfortunately, the program where this happens here is a bit too large, and this also seems to some part a bug in gdb. That is fully a gdb bug as mentioned before in different places, I think there is a gdb bug about it too. The problem is that gdb does not know which constructor (the in charge or the out of charge one) to place the breakpoint so it chooses one, the wrong one in your case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25793
[Bug middle-end/11135] It ought to be possible to make PIC_OFFSET_TABLE_REGNUM a pseudo
--- Comment #4 from rearnsha at gcc dot gnu dot org 2006-01-17 20:32 --- Closing as WORKSFORME. I didn't have to change anything in the middle-end in order to fix the ARM back-end. Maybe the documentation should be updated to reflect this status. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11135
[Bug target/592] [ARM/Thumb] Poor choice of PIC register
--- Comment #8 from rearnsha at gcc dot gnu dot org 2006-01-17 20:32 --- Fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=592
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-17 20:53 --- Confirmed, this looks obviously broken. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-ibm-aix5.3.0.0 | GCC host triplet|powerpc-ibm-aix5.3.0.0 | GCC target triplet|powerpc-ibm-aix5.3.0.0 | Last reconfirmed|-00-00 00:00:00 |2006-01-17 20:53:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug c++/25787] [4.2 Regression] ext/pb_assoc/example/ds_traits.cc compilation failed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-17 20:55 --- Lets close it as fixed then. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25787
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #10 from dick_guertin at yahoo dot com 2006-01-17 20:55 ---
I rebuilt with -O2 AND -g, and got the following trace. Notice the while-loop
in nscan, statements 1141 thru 1147 are four single statements. The next
trace by gdb shows them occuring multiple times. This should NOT be happening.
This may be another BUG, this time with 'gdb'. Execution ends with the
Illegal Instruction failure at statement 1158, a call to a function called
'rlookup'. I suppose I could try to follow that path, but I've tried 'step'
without success. Maybe I need to set a breakpoint.
(gdb) break comm.c:3651
Breakpoint 1 at 0x269ec: file comm.c, line 3651.
(gdb) run
Starting program: /afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge
Breakpoint 1, EDTBASE () at comm.c:3651
3651 NSCAN ();
(gdb) list comm.c:3650
3645 L_00F42: I_LA(R13,(R13+0x0C));
3646 L_00F46: I_ST(R0,(R1+0x024));
3647 L_00F4A: I_ST(R0,(R1+0x020));
3648 R14 = (long int)((char *)( PRT ));
3649 L_00F4E: I_ST(R14,(R1+0x028));
3650 L_00F52: NOOP;
3651 NSCAN ();
3652 L_00F54: I_L(R14,(R11+0x08C));
3653 L_00F58: I_SH(R13,(DATA+0x020A));
3654 L_00F5C: I_MVC(4,(R14+0x028),(R13));
(gdb) break comm.c:3652
Breakpoint 2 at 0x269f4: file comm.c, line 3652.
(gdb) break nscan
Breakpoint 3 at 0x1eb3e8: file scan.c, line 1122.
(gdb) cont
Continuing.
Breakpoint 3, nscan (scancb=0x0, token=0xffbef3d4, token_length=0xffbef3d0,
stack_pointer=0xffbef3d8) at scan.c:1122
1122 if (scancb-skip == NULL)
(gdb) where
#0 nscan (scancb=0x0, token=0xffbef3d4, token_length=0xffbef3d0,
stack_pointer=0xffbef3d8) at scan.c:1122
#1 0x001eeb44 in NSCAN () at scanstub.c:304
#2 0x000269f4 in EDTBASE () at comm.c:3651
#3 0x00027428 in EDTCOM () at comm.c:3464
#4 0x001ef540 in signon (edit_file=0xffbef888 ) at sign.c:477
#5 0x000e82fc in main (argc=1, argv=0xffbefa04) at main.c:110
(gdb) list scanstub.c:290
285 R15 = result;
286 }
287
288 R2 = regs[0]; R3 = regs[1]; R4 = regs[2]; R5 = regs[3]; R6 =
regs[4];
289
290 I_LTR(R15,R15);
291}
292 void NSCAN()
293{
294 unsigned char *token;
(gdb)
295 long token_length;
296 long r[16];
297
298 r[3] = htonl(R2);
299 r[4] = htonl(R3);
300 r[5] = htonl(R4);
301 r[6] = htonl(R5);
302 r[7] = htonl(R6);
303
304 R15 = nscan((NSCNCB *) R1, token, token_length, r);
(gdb)
305
306 R0 = token_length;
307 R1 = (long) token;
308
309 R2 = ntohl(r[3]);
310 R3 = ntohl(r[4]);
311 R4 = ntohl(r[5]);
312 R5 = ntohl(r[6]);
313 R6 = ntohl(r[7]);
314
(gdb)
315 I_LTR(R15,R15);
316}
317 void SETSKIP()
318{
319 setskip((unsigned char *) R2, (unsigned char *) R1, R0);
320 R15=0;
321 I_LTR(R15,R15);
322}
323 void SETSTOP()
324{
(gdb) where
#0 nscan (scancb=0x0, token=0xffbef3d4, token_length=0xffbef3d0,
stack_pointer=0xffbef3d8) at scan.c:1122
#1 0x001eeb44 in NSCAN () at scanstub.c:304
#2 0x000269f4 in EDTBASE () at comm.c:3651
#3 0x00027428 in EDTCOM () at comm.c:3464
#4 0x001ef540 in signon (edit_file=0xffbef888 ) at sign.c:477
#5 0x000e82fc in main (argc=1, argv=0xffbefa04) at main.c:110
(gdb) list scan.c:1122
1117 {
1118 long result;
1119
1120 /* Set scan defaults if needed */
1121
1122 if (scancb-skip == NULL)
1123scancb-skip = (unsigned char *) htonl((long) tblwskip);
1124
1125 if (scancb-stop == NULL)
1126scancb-stop = (unsigned char *) htonl((long) tblwmark);
(gdb)
1127
1128 scancb-msgl = 0;
1129
1130 if (scancb-kws) /* Scan with keyword table */
1131{
1132 unsigned char *nstloc;
1133 int nsffirst = 1;
1134
1135 result = 0;
1136
(gdb)
1137 while (result == 0)
1138 {
1139 NKW *matched_entry;
1140
1141 result = scntoken(scancb);
1142
1143 result = set_token(scancb, result);
1144
1145 result = set_type(scancb, result);
1146
(gdb)
1147 nstloc = (unsigned char *) ntohl((long)
scancb-tloc);
1148
1149 if ( (result != 0)
1150 || ( (scancb-type NSCNFNUL)
1151 (! nsffirst)
1152 )
1153)
1154break;
1155
1156 nsffirst = 0;
(gdb)
1157
1158 matched_entry = rlookup(scancb,
1159 (NKW *) ntohl((long)
scancb-kws),
1160
[Bug libstdc++/25797] [4.2 Regression] almost all libstdc++ tests fail
--- Comment #6 from hjl at lucon dot org 2006-01-17 20:58 --- The patch doesn't work on Linux/ia64. --gc-sections is ignored on Linux/ia64: [EMAIL PROTECTED] tmp]$ gcc -Wl,--gc-sections x.c /usr/local/bin/ld: Warning: gc-sections option ignored I got many /usr/local/bin/ld: Warning: gc-sections option ignored^M output is: /usr/local/bin/ld: Warning: gc-sections option ignored^M FAIL: 17_intro/header_cassert.cc (test for excess errors) Excess errors: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25797
[Bug c++/25827] New: Barton-Nackman-Trick with more than one template parameter fails with gcc3.3.3
The following code compiles perfectly with gcc 3.3.3 (xlc,icc):
g++ (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
With gcc 4.0.2:
g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared
--with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
And with gcc 3.4.5
g++-3.4 -v
Reading specs from /usr/lib/gcc/i486-linux-gnu/3.4.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,f77,pascal,objc,ada --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug i486-linux-gnu
Thread model: posix
gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)
the following error occurs:
short.cpp: In constructor #8216;BT_t::B(T_t)#8217;:
short.cpp:16: error: #8216;data#8217; was not declared in this scope
code:
#include iostream
using namespace std;
templateclass T_t ,class T_leaftype class A
{
public:
T_t data;
T_t getData() {return data;}
};
templateclass T_t class B : public AT_t, B T_t
{
public:
B(T_t p) { data = p; }
};
int main()
{
Bint test(1);
cout test.getData() endl;
}
--
Summary: Barton-Nackman-Trick with more than one template
parameter fails with gcc3.3.3
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot dolfen at fz-juelich dot de
GCC host triplet: Linux
GCC target triplet: Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25827
[Bug c++/25827] Barton-Nackman-Trick with more than one template parameter fails with gcc3.3.3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 21:02 --- See http://gcc.gnu.org/gcc-3.4/changes.html and PR 12970 *** This bug has been marked as a duplicate of 12970 *** -- 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=25827
[Bug c++/12970] Strange class member access rules
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-01-17 21:02 --- *** Bug 25827 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||a dot dolfen at fz-juelich ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12970
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #26 from hubicka at gcc dot gnu dot org 2006-01-17 21:07
---
Hi,
I've looked into it for some time, so here is my POV of this ugly issue.
It seems to me that from documentation of EMPTY_FIELD_BOUNDARY in gccint it is
clear that it
should be ignored when PPC_BITFIELD_TYPE_MATTERS is set. This seems pretty
correct in Jason's version of code to me.
Corcerning the value of EMPTY_FIELD_BOUNDARY in i386.h, I actually introduced
it back in 2001 while doing the 64bit changes. I am pretty sure I didn't much
worried about actual meaning of the value,
I just looked for 32 and was trying to decide whether the value means 32 or
size of word. The alignment seemed to be more word related.
The behaviour in 3.0.4 is to set the alignment according to type of bitfield
(is PPC_BITFIELD_TYPE_MATTERS). So struct a {char a; short :0;} has size 2.
This seems to be handled by the last hunk overwriting EMPTY_FIELD_BOUDNARY
Steven quotes in his analysis that has no equivalent in Jason's code.
I think it should be added into the conditional PPC_BITFIELD_TYPE_MATTERS in
stor layout at the place PPC_BITFIELD_TYPE_MATTERS is processed now, so I will
try to test the patch tomorrow.
I would also suggest removing the ignored EMPTY_FIELD_BOUNDARY from i386.h.
Does something from the above seem to make sense? (this is really slipperly)
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
Re: [Bug c++/25826] New: pure virtual destructors accepted by GCC, but cause link failure
lloyd at randombit dot net [EMAIL PROTECTED] writes:
| The following code:
|
| class A
|{
|public:
| virtual ~A() = 0;
You still need to *define* the destructor. See §12.4/7.
-- Gaby
[Bug c++/25826] pure virtual destructors accepted by GCC, but cause link failure
--- Comment #4 from gdr at cs dot tamu dot edu 2006-01-17 21:11 ---
Subject: Re: New: pure virtual destructors accepted by GCC, but cause link
failure
lloyd at randombit dot net [EMAIL PROTECTED] writes:
| The following code:
|
| class A
|{
|public:
| virtual ~A() = 0;
You still need to *define* the destructor. See §12.4/7.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
[Bug c++/25826] pure virtual destructors accepted by GCC, but cause link failure
--- Comment #5 from gdr at cs dot tamu dot edu 2006-01-17 21:12 --- Subject: Re: pure virtual destructors accepted by GCC, but cause link failure lloyd at randombit dot net [EMAIL PROTECTED] writes: | Ah, I misread it, but the bug should stay open IMO - the invalidity | of the code reduces it to GCC doesn't reject invalid code, which | is obviously a low priority, but still a bug, no? the code is rejected -- at link time. So it is no bug. PR should be closed as invalid. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
[Bug ada/23519] Dividing fixed point number by zero returns zero.
--- Comment #11 from listor1 dot rombobeorn at comhem dot se 2006-01-17 21:31 --- Subject: Re: Dividing fixed point number by zero returns zero. Excuse me, what's the reason for marking this bug as invalid? That an exception on division by zero isn't required? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23519
[Bug c++/25826] pure virtual destructors accepted by GCC, but cause link failure
--- Comment #6 from lloyd at randombit dot net 2006-01-17 21:39 --- Thank you for the reference Gaby. I'm now not quite sure what purpose a pure virtual destructor has, or why it should be legal, but neither the apparent language oddity nor my confusion about same is a GCC problem, so... Andrew, Gaby, sorry to distract you with the invalid bug report. I'll check the standard first next time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
[Bug fortran/25828] New: [f2003] ACCESS='STREAM' io support
ACCESS='STREAM' is IO without any record structure, i.e. it's similar to how IO is done in C and many other languages. -- Summary: [f2003] ACCESS='STREAM' io support Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org OtherBugsDependingO 20585,25561 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25828
[Bug fortran/25829] New: [F2003] Asynchronous IO support
F2003 supports the ASYNCHRONOUS='YES' specifier in some IO statements, as well as the WAIT io-unit statement. -- Summary: [F2003] Asynchronous IO support Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org OtherBugsDependingO 20585,25561 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug c++/25826] pure virtual destructors accepted by GCC, but cause link failure
--- Comment #7 from gdr at cs dot tamu dot edu 2006-01-17 22:00 --- Subject: Re: pure virtual destructors accepted by GCC, but cause link failure lloyd at randombit dot net [EMAIL PROTECTED] writes: | I'm now not quite sure what purpose a pure virtual destructor has, the usefulness used to be subject of debate when OO was the main topic. Some people believe it is a concise way for them to state that a given base class for a hierarchy is abstract. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
[Bug bootstrap/25825] Add soft float to list of libraries
--- Comment #4 from pedz at easesoftware dot net 2006-01-17 22:01 --- No, I did not. Since your update, I've looked for some documentation and can not find any. If you can point me to some, then I will be happy to investigate futher. I assume that LIBCXXFLAGS or LIBCFLAGS may be able to do what the changes to t-aix52 accomplished. But the changes to pcc64-fp.c would still be needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25825
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #8 from pedz at easesoftware dot net 2006-01-17 22:02 --- Note that 25824 is a close cousin to this bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug libfortran/25830] New: [libgfortran] Optionally support multi-process locking
Currently the gfortran IO library is supposed to be thread safe. Additionally, allowing multiple processes to access the same file could be useful, and if we eventually want to support co-arrays with multiple processes, it will be needed as co-arrays specify that multiple images can access a single file. On POSIX this can be accomplished with the fcntl() syscall. We'd certainly want to make this optional (perhaps with a compiler command-line switch like the fpe options), to avoid the fcntl() overhead as well as frequent buffer flushing in normal single-process usage. -- Summary: [libgfortran] Optionally support multi-process locking Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org OtherBugsDependingO 18918,25561 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25830
[Bug libfortran/25830] [libgfortran] Optionally support multi-process locking
--- Comment #1 from jb at gcc dot gnu dot org 2006-01-17 22:07 --- Change severity to enhancement. -- jb at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25830
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #1 from jb at gcc dot gnu dot org 2006-01-17 22:10 --- Switched dependencies to the correct order. -- jb at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|25828, 25829, 25830 | OtherBugsDependingO||25828, 25829, 25830 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #27 from matz at suse dot de 2006-01-17 22:12 ---
Funnily I've also looked at stor-layout.c a bit, and basically came to
a similar conclusion and patch like Steven. I agree that as per documentation
PCC_BITFIELD_TYPE_MATTERS overrides EMPTY_FIELD_BOUNDARY. But that was
also a change by Jasons patch. Formerly it just influenced how empty
fields are handled. Clearly it influenced it in a different way than simple
overriding.
The problem, like Steven already analyzed, is twofold:
1) maximum_field_alignment now affects also empty bitfields,
which it didn't before, because before Jason maximum_field_alignment
was evaluated before other things were taken into account, and now
it's the last thing done. That's why earlier something larger than
alignment 8 bit was possible with #pragma pack(1) at all.
2) A bug or feature in pre-3.4 lead to the ignoring of EMPTY_FIELD_ALIGNMENT
when larger than 32 in our case. Namely because the initial alignment
of 64 (as required by EMPTY_FIELD_ALIGNMENT) was overriden by the
alignment of the type of the bitfield (int here, i.e. 32 bit).
I've come up with this simple patch for the problem, which fixes the testcase
for i386 and x86-64 (in the sense of being compatible with = 3.3) .
The idea is to simply ignore the max field alignment
for empty bitfield (hence falling back to either PCC_BITFIELD_TYPE_MATTERS
or EMPTY_FIELD_ALIGNMENT as the target requested).
This needs to be tested also with struct where the packed property is not
due to a #pragma pack(1) but rather a packed attribute, or similar.
Index: stor-layout.c
===
--- stor-layout.c (revision 107699)
+++ stor-layout.c (working copy)
@@ -337,6 +337,7 @@
/* For fields, it's a bit more complicated... */
{
bool old_user_align = DECL_USER_ALIGN (decl);
+ bool zero_bitfield = false;
if (DECL_BIT_FIELD (decl))
{
@@ -348,6 +349,7 @@
! DECL_PACKED (decl)
! targetm.ms_bitfield_layout_p (DECL_FIELD_CONTEXT (decl)))
{
+ zero_bitfield = true;
#ifdef PCC_BITFIELD_TYPE_MATTERS
if (PCC_BITFIELD_TYPE_MATTERS)
do_type_align (type, decl);
@@ -428,7 +430,7 @@
}
/* Should this be controlled by DECL_USER_ALIGN, too? */
- if (maximum_field_alignment != 0)
+ if (maximum_field_alignment != 0 ! zero_bitfield)
DECL_ALIGN (decl) = MIN (DECL_ALIGN (decl), maximum_field_alignment);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug ada/23519] Dividing fixed point number by zero returns zero.
--- Comment #12 from simon at pushface dot org 2006-01-17 22:14 --- Subject: Re: Dividing fixed point number by zero returns zero. On 17 Jan 2006, at 21:31, listor1 dot rombobeorn at comhem dot se wrote: Excuse me, what's the reason for marking this bug as invalid? That an exception on division by zero isn't required? I quite agree, sorry not to have noticed that the bug was marked invalid. It's clearly a bug, ought to raise Constraint_Error. I certainly don't expect fast response on Ada problems but it seems wrong to just junk a problem because the maintainers have more pressing matters to deal with! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23519
[Bug testsuite/25831] New: FAIL: gcc.dg/20050922-1.c (test for excess errors)
Executing on host: /test/gnu/gcc-4.0/objdir/gcc/xgcc -B/test/gnu/gcc-4.0/objdir/ gcc/ /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c -O1 -std=c99 -lm -o ./20050922-1.exe(timeout = 300) /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:8:20: error: stdint.h: N o such file or directory /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:13: error: parse error b efore 'f' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:13: error: parse error b efore '*' token /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:14: warning: return type defaults to 'int' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c: In function 'f': /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:15: error: 'uint32_t' un declared (first use in this function) /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:15: error: (Each undecla red identifier is reported only once /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:15: error: for each func tion it appears in.) /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:15: error: parse error b efore 'A' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c: At top level: /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:18: warning: type defaul ts to 'int' in declaration of 'A' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:18: error: 'B' undeclare d here (not in a function) /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:18: warning: data defini tion has no type or storage class /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:19: error: parse error b efore 'for' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:22: warning: type defaul ts to 'int' in declaration of 'A' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:22: error: redefinition of 'A' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:18: error: previous defi nition of 'A' was here /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:22: error: 'S' undeclare d here (not in a function) /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:23: error: 'k' undeclare d here (not in a function) /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:23: warning: data defini tion has no type or storage class /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:25: warning: type defaul ts to 'int' in declaration of 'm' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:25: warning: data defini tion has no type or storage class /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:26: warning: type defaul ts to 'int' in declaration of 'k' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:26: error: 'L' undeclare d here (not in a function) /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:26: warning: data defini tion has no type or storage class /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:27: warning: type defaul ts to 'int' in declaration of 'B' /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:28: warning: data defini tion has no type or storage class /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:29: error: parse error b efore '}' token /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c: In function 'main': /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:36: error: 'uint32_t' un declared (first use in this function) /test/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/20050922-1.c:36: error: parse error b efore 'S' compiler exited with status 1 I think stdint.h should be changed to stdlib.h. -- Summary: FAIL: gcc.dg/20050922-1.c (test for excess errors) Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu 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=25831
[Bug testsuite/25831] [4.0 only] FAIL: gcc.dg/20050922-1.c (test for excess errors)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: gcc.dg/20050922-1.c |[4.0 only] FAIL: |(test for excess errors)|gcc.dg/20050922-1.c (test ||for excess errors) Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25831
[Bug testsuite/25831] [4.0 only] FAIL: gcc.dg/20050922-1.c (test for excess errors)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 22:27 --- This was PR 24107 which was only fixed in 4.1.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||24107 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-17 22:27:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25831
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
