[Bug c++/20221] New: Declspec sequences on pointer declarations: C++ vs C
The behaviour of C++ with declspec sequences on pointer declarations has changed: Compiling: /* declspec.c */ int i = 1; int __attribute__((aligned(16))) * foo = &i; int * __attribute__((aligned(16))) bar = &i; as gcc -xc -W -S declspec.c, I get: .section .drectve .ascii " -export:bar,data" .ascii " -export:foo,data" Compiling above as gcc -xc++ -W -S declspec.c, I get: .section .drectve .ascii " -export:foo,data" The attribute is silently ignored for bar. In gcc-3.3.3 and 3.4.4 , the dllexport attribute was applied to both declarations in C++, as in C. In old gcc-2.95.2, the behaviour was the same as in 4.0.0 A similar difference between C and C++ is observed if I substitute aligned(16) for dllexport, ie, foo is 16-byte aligned, bar is 4-btye aligned in C++, while both are 16- byte aligned in C. Is this a bug, or are declspec sequence rules being followed more strictly now in C++? If the latter, should there be some kind of warning at least with -Wextra? Danny -- Summary: Declspec sequences on pointer declarations: C++ vs C Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20221
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
-- Bug 19987 depends on bug 20219, which changed state. Bug 20219 Summary: Missed optimisation sin / tan --> cos http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20219 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
[Bug tree-optimization/20219] Missed optimisation sin / tan --> cos
--- Additional Comments From uros at kss-loka dot si 2005-02-26 09:50 --- Here is the patch to implement missing folds: http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01024.html And here is the explanation why this transformation is not suitable for GCC even with -ffast-math: http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01034.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20219
[Bug c++/11585] static template member definition fails
--- Additional Comments From jaco at kroon dot co dot za 2005-02-26 10:03
---
A more complex example, this code works with gcc 3.3 so this imho is either
incorrect code or a bug in the new parses:
template class FakeList {
public:
void foo() {};
};
template class Factory {
public:
typedef T* (*CreateType)();
typedef struct { char *name; CreateType creator; } TypePair;
static FakeList _types;
T* createOne() {
_types.foo();
return 0;
};
};
typedef Factory IntFactory;
/*
* I've tried prefixing this with template <>
* which them compiles, but fails to link.
*/
FakeList IntFactory::_types;
int main(int, char**) {
IntFactory blah;
blah.createOne();
return 0;
}
I'm using gcc 3.4.3 on amd64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11585
[Bug rtl-optimization/19683] MIPS wrong-code for 64-bit multiply.
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-02-26 10:16 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01665.html -- What|Removed |Added Component|target |rtl-optimization Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19683
[Bug c/20189] assignment error in inline function
--- Additional Comments From dirk at cle-mens dot de 2005-02-26 10:35
---
(In reply to comment #1)
> Invalid you are violating C90/C99 aliasing rules.
Ok. But where is the compiler warning?
The dokumentation of gcc says: (man gcc)
-Wstrict-aliasing
This option is only active when -fstrict-aliasing is active. It
warns about code which might break the strict aliasing rules that
the compiler is using for optimization. The warning does not
catch all cases, but does attempt to catch the more common pit‐
falls. It is included in -Wall.
But the compiler don't give any warning!
And this is a compiler error in category warnings.
P.S.: I have minimized the Programm that shows this error:
#include
#include
typedef unsigned int uint32;
typedef unsigned long long uint64;
struct data
{
uint32 lo;
uint32 hi;
};
inline uint64 GetData ( const struct data * d )
{
const uint64 *p = (uint64*)d; //
return *p;
}
int main( int argc, char ** argv )
{
struct data D = {1,2};
uint64 u64 = GetData(&D);
printf("%016llx\n",u64);
return 0;
}
--
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20189
[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-26 11:22 --- The pointer "base" looks a bit uninitialized. Fix the test-case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-26 11:24 --- Ignore comment #4, sorry (misread this as being about run-time behavior). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug c++/20220] [4.0/4.1 Regression] Rejecting invalid template code, breaks most of Boost
--- Additional Comments From giovannibajo at libero dot it 2005-02-26 12:01 --- I forgot to thank Martin Wille for notifying me of this bug and providing me with this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20220
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-26 12:56 --- (Interested because I see this for CRIS too. For CRIS v32, it's even more interesting, because it has no reg+offset addressing.) -- What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug rtl-optimization/13049] Does not warn on obvious aliasing problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26 14:26 --- *** Bug 20189 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dirk at cle-mens dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13049
[Bug c/20189] assignment error in inline function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26 14:26 --- Because that would be PR 13049. *** This bug has been marked as a duplicate of 13049 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20189
[Bug c/20222] New: [AVR] Double load of volatile operand
built in abs (and perhaps other) function creates two loads for optimisation
-02,-O3 and -Os (-O1 does not have problem)
Also seen on 4.0 head
testcase, assembler and RTL dump are attached below.
back to back loads of volatile operand i1 are generated in initial RTL. This
remains throughout code generation.
The second example xi1 without "volatile" also has extra load in initial RTL -
but is optimised away. Problem is due to creation of unwanted fetch.
extern int xi1;
extern volatile int i1;
void
main (void)
{
/* First 'abs' on volatile results in TWO loads from stack. */
/* Second 'abs' from global results in two but one is optimised away */
i1 = 1;
if (abs (i1) != 1)
abort ();
if (abs (xi1) != 1)
abort ();
}
1.file "testabs-2.c"
2.arch atmega169
3__SREG__ = 0x3f
4__SP_H__ = 0x3e
5__SP_L__ = 0x3d
6__tmp_reg__ = 0
7__zero_reg__ = 1
8.global __do_copy_data
9.global __do_clear_bss
17.Ltext0:
18.global main
20main:
21.LFB2:
22.LM1:
23/* prologue: frame size=0 */
24 C0E0 ldi r28,lo8(__stack - 0)
25 0002 D0E0 ldi r29,hi8(__stack - 0)
26 0004 DEBF out __SP_H__,r29
27 0006 CDBF out __SP_L__,r28
28/* prologue end (size=4) */
29.LM2:
30 0008 81E0 ldi r24,lo8(1)
31 000a 90E0 ldi r25,hi8(1)
32 000c 9093 sts (i1)+1,r25
33 0010 8093 sts i1,r24
34.LBB2:
35.LM3:
36 0014 8091 lds r24,i1
37 0018 9091 lds r25,(i1)+1
38 001c 8091 lds r24,i1
39 0020 9091 lds r25,(i1)+1
40 0024 97FD sbrc r25,7
41 0026 0BC0 rjmp .L8
42.L3:
43.LM4:
44 0028 0197 sbiw r24,1
45 002a 89F4 brne .L6
46.LBE2:
47.LBB3:
48.LM5:
49 002c 8091 lds r24,xi1
50 0030 9091 lds r25,(xi1)+1
51 0034 97FD sbrc r25,7
52 0036 07C0 rjmp .L9
53.L5:
54 0038 0197 sbiw r24,1
55 003a 59F0 breq .L1
56 003c 08C0 rjmp .L6
57.L8:
58.LBE3:
59.LBB4:
60.LM6:
61 003e 9095 com r25
62 0040 8195 neg r24
63 0042 9F4F sbci r25,lo8(-1)
64 0044 F1CF rjmp .L3
65.L9:
66.LBE4:
67.LBB5:
68.LM7:
69 0046 9095 com r25
70 0048 8195 neg r24
71 004a 9F4F sbci r25,lo8(-1)
72 004c F5CF rjmp .L5
73.L6:
74.LBB6:
75.LM8:
76 004e 0E94 call abort
77.L1:
78.LBE6:
79.LBE5:
80/* epilogue: frame size=0 */
81 0052 0C94 jmp exit
82/* epilogue end (size=2) */
83/* function main size 45 (39) */
84.LFE2:
86.Letext0:
DEFINED SYMBOLS
*ABS*: testabs-2.c
*ABS*:003f __SREG__
*ABS*:003e __SP_H__
*ABS*:003d __SP_L__
*ABS*: __tmp_reg__
*ABS*:0001 __zero_reg__
c:\DOCUME~1\Andy\LOCALS~1\Temp/ccgX.s:20 .text: main
UNDEFINED SYMBOLS
__do_copy_data
__do_clear_bss
__stack
i1
xi1
abort
exit
;; Function main
(note 1 0 2 ("testabs-2.c") 5)
(note 2 1 3 NOTE_INSN_DELETED)
(note 3 2 4 NOTE_INSN_FUNCTION_BEG)
(note 4 3 5 NOTE_INSN_DELETED)
(note 5 4 6 007292A8 NOTE_INSN_BLOCK_BEG)
(note 6 5 7 NOTE_INSN_DELETED)
(note 7 6 8 ("testabs-2.c") 9)
(insn 8 7 9 (set (reg:HI 41)
(const_int 1 [0x1])) -1 (nil)
(nil))
(insn 9 8 10 (set (mem/v/f:HI (symbol_ref:HI ("i1") [flags 0x40] ) [2 i1+0 S2 A8])
(reg:HI 41)) -1 (nil)
(nil))
(note 10 9 11 00729230 NOTE_INSN_BLOCK_BEG)
(note 11 10 12 NOTE_INSN_DELETED)
(note 12 11 13 ("testabs-2.c") 11)
(insn 13 12 14 (set (reg:HI 42)
(mem/v/f:HI (symbol_ref:HI ("i1") [flags 0x40] )
[2 i1+0 S2 A8])) -1
[Bug libgcj/20223] New: libjava testsuite does not fully support multilibs
the libjava testsuite does not correctly re-initialize itself for testing
multiple multilib variants in a second or subsequent run. For example if your
site.exp contains:
case "$target_triplet" in {
{ "arm*-*-elf*" } {
set target_list { "arm-sim{,-mthumb}" }
set board_info(arm-sim,hostname) "localhost"
set board_info(arm-sim,gdb,skip_huge_test) 1
set board_info(arm-sim,sim,options) "-m 8378368"
set board_info(arm-sim/-mthumb,hostname) "localhost"
set board_info(arm-sim/-mthumb,gdb,skip_huge_test) 1
set board_info(arm-sim/-mthumb,sim,options) "-m 8378368"
}
# Other targets
}
(the key line is the target-list)
Then the testsuite glue and libraries for the -mthumb run are not correctly set.
This works for the other components in the testsuite.
--
Summary: libjava testsuite does not fully support multilibs
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20223
[Bug tree-optimization/20188] [4.0/4.1 Regression] asm and memory operands does not add a V_MAY_DEF
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-26 16:15 --- Subject: Bug 20188 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-26 16:15:26 Modified files: gcc: ChangeLog tree-ssa-alias.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: inline_asm-1.c inline_asm-2.c gcc/testsuite/gcc.dg: asm-b.c Log message: 2005-02-26 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/20188 * gcc.dg/tree-ssa/inline_asm-1.c: New test. * gcc.dg/tree-ssa/inline_asm-2.c: New test. * gcc.dg/asm-b.c: New test. 2005-02-26 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/20188 * tree-ssa-alias.c (count_uses_and_derefs): If we have TREE_LIST for the lhs, also walk over the tree. Likewise for rhs. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7602&r2=2.7603 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-alias.c.diff?cvsroot=gcc&r1=2.71&r2=2.72 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5087&r2=1.5088 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/inline_asm-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/inline_asm-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/asm-b.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20188
[Bug tree-optimization/20188] [4.0/4.1 Regression] asm and memory operands does not add a V_MAY_DEF
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-26 16:24 --- Subject: Bug 20188 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-02-26 16:24:44 Modified files: gcc: ChangeLog tree-ssa-alias.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: asm-b.c gcc/testsuite/gcc.dg/tree-ssa: inline_asm-1.c inline_asm-2.c Log message: 2005-02-26 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/20188 * gcc.dg/tree-ssa/inline_asm-1.c: New test. * gcc.dg/tree-ssa/inline_asm-2.c: New test. * gcc.dg/asm-b.c: New test. 2005-02-26 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/20188 * tree-ssa-alias.c (count_uses_and_derefs): If we have TREE_LIST for the lhs, also walk over the tree. Likewise for rhs. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.6&r2=2.7592.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-alias.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.71&r2=2.71.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.2&r2=1.5084.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/asm-b.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/inline_asm-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/inline_asm-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20188
[Bug tree-optimization/20188] [4.0/4.1 Regression] asm and memory operands does not add a V_MAY_DEF
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26 16:25 --- Fixed, thanks for your report and thanks for looking into the problem a little more than most would look into it, it helped getting a short testcase and fixing the problem faster. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20188
[Bug libgcj/20160] [4.0/4.1 Regression] link errors building libgcj tests
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-26 16:34 --- That patch seems to work, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug middle-end/19046] [4.0/4.1 Regression] usage of MOVE_RATIO should be tweaked
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26 17:19 --- Moving to 4.1 since this will take more work as just tweaking MOVE_RATIO for powerpc causes SPEC to get worse. What should be tweaked is the usage of MOVE_RATIO instead. -- What|Removed |Added Component|target |middle-end Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression] usage |MOVE_RATIO should be tweaked|of MOVE_RATIO should be |on ppc |tweaked Target Milestone|4.0.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19046
[Bug fortran/20224] New: gfortran - flags error on strange, but correct f77 program
I have a few old programs that do this - it is legal in f77 and actually has a special name that I cannot recall at the moment. Absoft likes and runs it correctly. [dir:~/tests/gfortran] dir% f77 -o jump jump.f FORTRAN 77 Compiler 8.0a, Copyright (c) 1987-2003, Absoft Corp. [dir:~/tests/gfortran] dir% jump hi hi [dir:~/tests/gfortran] dir% gfortran -o jump jump.f In file jump.f:4 10 continue 1 In file jump.f:9 2 Error: Label at (1) is not in the same block as the GOTO statement at (2) [dir:~/tests/gfortran] dir% cat jump.f program main do 20 i=1,2 go to 30 10 continue 20 continue stop 30 continue write(*,*) 'hi' goto 10 end -- Summary: gfortran - flags error on strange, but correct f77 program Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug fortran/20224] gfortran - flags error on strange, but correct f77 program
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26 18:32 --- Hmm, g77 just warned about it: t.f: In program `main': t.f:4: warning: 10 continue 1 t.f:9: (continued): goto 10 2 Reference to label at (2) is outside block containing definition at (1) Confirmed. -- What|Removed |Added OtherBugsDependingO||19292 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-02-26 18:32:27 date|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug libstdc++/19747] [meta-bug] : cris-elf libstdc++ testsuite failures as of "Tue Feb 1 22:03:59 UTC 2005"
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-26 18:32:51 date|| Summary|meta: cris-elf libstdc++|[meta-bug] : cris-elf |testsuite failures as of|libstdc++ testsuite failures |"Tue Feb 1 22:03:59 UTC|as of "Tue Feb 1 22:03:59 |2005" |UTC 2005" http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19747
[Bug libfortran/17748] libgfortran contains undefined references to _environ
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-26 18:33 --- Subject: Bug 17748 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-26 18:33:12 Modified files: libgfortran: ChangeLog libgfortran/runtime: environ.c Log message: 2005-02-26 Peter O'Gorman <[EMAIL PROTECTED]> Toon Moene <[EMAIL PROTECTED]> PR libgfortran/17748 * runtime/environ.c: Remove references to environ. (show_variables): remove GFORTRAN_UNBUFFERED_* and GFORTRAN_NAME_* because they require environ. (pattern_scan): Remove function. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.163&r2=1.164 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/environ.c.diff?cvsroot=gcc&r1=1.7&r2=1.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17748
[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-02-26 19:20 --- The first part of the patch seems fine. We should make tree_fold_binomial non-recursive. Note, however, that once you do that, the other part of the patch isn't actually doing anything (the change to chrec_apply). Then all the memory usage comes from fold (all 600 meg of memory usage, i mean) creating new trees. It also doesn't recurse int hat case. In any case, limiting the input to chrec_apply to <1024 is uh, wrong, as it's not really fixing anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug fortran/20224] gfortran - flags error on strange, but correct f77 program
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-26 19:44 --- This is illegal code with respect to F77. >From ansi-x3dot9-1978-Fortran77.pdf 11.10.8 Transfer into the Range of a Do-Loop Transfer of control into the range of a DO-loop from outside the range is not permitted. I haven't looked in the F2003 standard, but I suspect it is also illegal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug libfortran/20163] gfortran - error opening direct access file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-26 20:46 --- Patch for the first bug here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01694.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20163
[Bug libfortran/20163] gfortran - error opening direct access file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-26 20:49 --- Here is a reduced test case for the second error: $ cat open-after-error.f open(10,status="foo",err=100) call abort 100 continue open(10,status="scratch") end $ cat open-after-error.f open(10,status="foo",err=100) call abort 100 continue open(10,status="scratch") end $ gfortran open-after-error.f $ ./a.out At line 4 of file open-after-error.f Internal Error: Recursive library calls not allowed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20163
[Bug tree-optimization/19360] [4.0 Regression] ICE with -O1 -funit-at-a-time
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-26 22:27 --- Subject: Bug 19360 CVSROOT:/cvs/gcc Module name:gcc Branch: apple-ppc-branch Changes by: [EMAIL PROTECTED] 2005-02-26 22:27:29 Modified files: gcc: ChangeLog.apple-ppc tree-ssa-dom.c Log message: 2005-02-26 Dale Johanensen <[EMAIL PROTECTED]> Radar 3988125 PR 19360 (from mainline) * tree-ssa-dom.c (tree_ssa_dominator_optimize): Clear SSA_NAME_VALUE at the end of the main DOM loop rather than just before DOM exits. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.apple-ppc.diff?cvsroot=gcc&only_with_tag=apple-ppc-branch&r1=1.1.2.325&r2=1.1.2.326 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dom.c.diff?cvsroot=gcc&only_with_tag=apple-ppc-branch&r1=1.1.2.149.2.11&r2=1.1.2.149.2.12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19360
[Bug c++/20225] New: [4.0/4.1 regression] ICE during GC
$ ./cc1plus -fpreprocessed libkspreadpart_la.all_cc.ii -quiet -O -w Program received signal SIGSEGV, Segmentation fault. gt_ggc_mx_cgraph_node (x_p=) at gtype-desc.c:188 188 gt_ggc_m_9tree_node ((*x).decl); (gdb) bt #0 gt_ggc_mx_cgraph_node (x_p=) at gtype-desc.c:188 #1 0x404a3a80 in gt_ggc_mx_cgraph_node (x_p=) at gtype-desc.c:196 #2 0x404a3a80 in gt_ggc_mx_cgraph_node (x_p=) at gtype-desc.c:196 #3 0x404ab120 in gt_ggc_m_P11cgraph_node4htab ( x_p=) at gtype-desc.c:1498 #4 0x4049eff0 in ggc_mark_roots () at ggc-common.c:118 #5 0x40662110 in ggc_collect () at ggc-page.c:1981 #6 0x4066c690 in rest_of_compilation () at passes.c:477 #7 0x40204e40 in execute_pass_list (pass=0x60016e90) at tree-optimize.c:533 #8 0x40205600 in tree_rest_of_compilation (fndecl=0x2af51fb0) at tree-optimize.c:669 #9 0x40131630 in expand_body (fn=0x2af51fb0) at semantics.c:2977 #10 0x406a0f30 in cgraph_expand_function (node=0x200010652e50) at cgraphunit.c:832 #11 0x406a3d30 in cgraph_optimize () at cgraphunit.c:1699 #12 0x400afd10 in cp_finish_file () at decl2.c:3032 #13 0x40003630 in finish_file () at cp-lang.c:113 #14 0x401c58a0 in c_common_parse_file ( set_yydebug=) at c-opts.c:1096 #15 0x40624380 in toplev_main (argc=, argv=) at toplev.c:996 #16 0x401d8380 in main (argc=6, argv=0x6fffa858) at main.c:35 (gdb) p x $1 = (struct cgraph_node *) 0x0 -- Summary: [4.0/4.1 regression] ICE during GC Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: ia64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug c++/20225] [4.0/4.1 regression] ICE during GC
--- Additional Comments From schwab at suse dot de 2005-02-26 23:23 --- Created an attachment (id=8289) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8289&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
-- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|c++ |middle-end Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From giovannibajo at libero dot it 2005-02-26 23:45 --- HJL: would you please open a different bug report for the x86-64 issue and link it to this bug? Benjamin: can you open a different enhancement proposal about supporting the visibility attribute at namespace-level? Anyway, I think the correct way to go for 4.0 is to use the pragmas. A patch against the 4.0 branch would be much appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-26 23:55 --- Hmm, the last time this happened, it was PR 17126. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug c++/11585] static template member definition fails
--- Additional Comments From giovannibajo at libero dot it 2005-02-27 00:02 --- This is still incorrect code. You need an explicit template<> before that line. Though, after that, I cannot see why it should fail to link. What is the link error? That is a possible bug in GCC. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11585
[Bug fortran/20224] gfortran - flags error on strange, but correct f77 program
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-27 00:06 --- Here's a little more info from the F77 standard, Appendix A. A2. Conflicts with ANSI X3.9-1966 An extremely important consideration in the preparation of this standard was the minimization of conflicts with the previous standard, ANSI X3.9-1966. This standard includes changes that create conflicts with ANSI X3.9-1966 only when such changes were necessary to correct an error in the previous standard or to add to the power of the FORTRAN language in a significant manner. The following is a list of known conflicts: (7) This standard does not permit a transfer of control into the range of a DO-loop from outside the range. The range of a DO-loop may be entered only by the execution of a DO statement. ANSI X3.9-1966 permitted transfer of control into the range of a DO-loop under certain conditions. This involved the concept referred to as "extended range of a DO." I think that this can be closed with a WONTFIX, since there is nothing to fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug fortran/20224] gfortran - flags error on strange, but correct f66 program
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 00:10 --- (In reply to comment #3) > Here's a little more info from the F77 standard, Appendix A. Hmm, people still have fortran 66 code floating around. /me hides -- What|Removed |Added Summary|gfortran - flags error on |gfortran - flags error on |strange, but correct f77|strange, but correct f66 |program |program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From fjahanian at apple dot com 2005-02-27 00:51 --- (In reply to comment #6) > The first part of the patch seems fine. > We should make tree_fold_binomial non-recursive. You meant tree_fold_factorial? tree_fold_binomial is not recursive as is. > Note, however, that once you do that, the other part of the patch isn't > actually > doing anything (the change to chrec_apply). I agree. checking for 1024 is arbitrary and I did not propose it as a final solution. I think a better solution would be to compute the factorial of the array upper bound, as currently is done. If it cannot be evaluated, due to overflow, chrec_evaluate which depends on computation of tree_fold_binomial returns chrec_dont_know. In other words, we do this optimization only when factorial can be computed. This prevents setting an arbitrary limit and will let the implmentation limitations dicides feasibility of this optimization. What do you think on a patch along this line? > > Then all the memory usage comes from fold (all 600 meg of memory usage, i > mean) > creating new trees. > It also doesn't recurse int hat case. > > In any case, limiting the input to chrec_apply to <1024 is uh, wrong, as it's > not really fixing anything. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-02-27 02:09 --- Subject: Re: [4.0/4.1 Regression] Simple loop runs out of stack at -O1 On Sun, 2005-02-27 at 00:51 +, fjahanian at apple dot com wrote: > --- Additional Comments From fjahanian at apple dot com 2005-02-27 00:51 > --- > (In reply to comment #6) > > The first part of the patch seems fine. > > We should make tree_fold_binomial non-recursive. > You meant tree_fold_factorial? tree_fold_binomial is not recursive as is. > > > Note, however, that once you do that, the other part of the patch isn't > > actually > > doing anything (the change to chrec_apply). > I agree. checking for 1024 is arbitrary and I did not propose it as a final > solution. > I think a better solution would be to compute the factorial of the array > upper bound, > as currently is done. If it cannot be evaluated, due to overflow, > chrec_evaluate > which depends on computation of tree_fold_binomial returns chrec_dont_know. > In other words, we > do this optimization only when factorial can be computed. This prevents > setting an arbitrary limit and will let the implmentation limitations dicides > feasibility > of this optimization. What do you think on a patch along this line? I believe Roger Sayle was considering simply rewriting this code to not use fold at all, for starters, and then doing the smart thing about evaluation of binomial. Let's see what he has to say. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 02:25 --- Hmm, I cannot reproduce with a cross compiler from powerpc-darwin with today's source. Either we are missing compiling gcc or this could be related to one of my local patches (which I really doubt it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug ada/20226] New: [4.0, 4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap
When bootstrapping GCC mainline 20050226, the build breaks here: ../../gnatbind -C -I- -I../rts -I. - I/aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada -o b_gnatm.c gnatmake.ali make[3]: *** [b_gnatm.c] Error 5 make[3]: Leaving directory `/aaronwl/cs/env/mingw- head/20050226/build/gcc/gcc/ada/tools' gdb shows: Program received signal SIGSEGV, Segmentation fault. __gnat_install_SEH_handler (ER=0x77c3aead) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/seh_init.c:220 220 ((int *)ER)[1] = (int)__gnat_SEH_error_handler; /* new handler */ (gdb) bt #0 __gnat_install_SEH_handler (ER=0x77c3aead) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/seh_init.c:220 #1 0x00401595 in main (argc=9, argv=0x3d4238, envp=0x3d2fc8) at ada/b_gnatb.c:260 (gdb) quit This may be related to this recent patch: <http://gcc.gnu.org/ml/gcc- patches/2005-02/msg00428.html>. I can't tell superficially what the problem is, as "set ((int *)ER)[1] = (int) __gnat_SEH_error_handler" appears to work just fine. Target: i686-pc-mingw32 Configured with: /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/configure --enable- languages=ada,c,c++,f95,java,objc --with-dwarf2 --enable-libmudflap --enable- libgcj --enable-libstdcxx-allocator=mt --enable-libstdcxx-debug --enable- concept-checks --with-included-gettext --prefix=/aaronwl/cs/env/mingw- head/20050226 --with-libiconv-prefix=/aaronwl/cs/internat/iconv/install --with- gmp=/aaronwl/cs/math/gmp/gmp-4.1.4 --with-mpfr=/aaronwl/cs/math/mpfr/mpfr-2.1.0 Thread model: win32 gcc version 4.1.0 20050226 (experimental) i686-pc-mingw32 Windows XP SP2 Professional Pentium 4 256MB Cygwin Current Thu Feb 24 03:40:25 2005 host gcc 3.4.1 (mingw special) host binutils 2.15.91 20040904 (mingw) host mingwrt 3.5 host w32api 3.1 msvcrt 7.0.2600.2180 libiconv 1.9.1 GNU Make 3.80 expect 5.26 tcl 8.4 dejagnu 1.4.2.x ln with softlinks disabled -- Summary: [4.0, 4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: build Severity: critical Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: charlet at adacore dot com,gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226
[Bug ada/20226] [4.0/4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 02:29 --- Hmm, http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01702.html but that could be just a -Werror problem. Did you do make or make bootstrap -- What|Removed |Added Severity|critical|normal Summary|[4.0, 4.1 Regression] Error |[4.0/4.1 Regression] Error |in |in |__gnat_install_SEH_handler |__gnat_install_SEH_handler |breaks bootstrap|breaks bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226
[Bug ada/20226] [4.0/4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-02-27 02:35 --- Since you asked, I noticed that I had used 'make' instead of 'make bootstrap' by accident. I will try again using 'make bootstrap'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226
[Bug target/19819] ICE when compiling aegis 4.20
-- What|Removed |Added CC||danglin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-27 03:08:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19819
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-02-27 03:54 --- There are 3 bugs here: 1. libstdc++ should have pop/push of the visibility. 2. C++ should support pop/push of the visibility. 3. Gcc should emit ".hidden foo" when foo is marked hidden, defined or not. Patches for #2 are at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00287.html I opened a bug for #3, bug 20218. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol
-- What|Removed |Added OtherBugsDependingO||19664 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug tree-optimization/20188] [4.0/4.1 Regression] asm and memory operands does not add a V_MAY_DEF
--- Additional Comments From danglin at gcc dot gnu dot org 2005-02-27 04:04 --- inline_asm-2 test fails on all hppa targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20188
[Bug target/20227] New: [m68k] long double -> double cast fails with -0.0
I found a problem because the FP emulation of long doubles in the m68k port
doesn't treat -0.0 correctly. A cast from a long double -0.0 to a double results
in a double with the value -2.0.
The relevant function is __truncxfdf2 in gcc/config/m68k/fpgnulib.c. There are
two issues here.
First of all the short-cut test for zero only tested for +0.0, not -0.0.
However that by itself shouldn't have shown up a problem as the more lengthy
code underneath should have still come up with the right answer. The problem is
that it doesn't treat a long double exponent of 0 as special. Without this
fixed, subnormal numbers continue to be broken when converted to doubles.
I believe this is the correct fix, but I'm not sure:
--- fpgnulib.c~ Mon Jan 12 03:55:42 2004
+++ fpgnulib.c Sun Feb 27 04:05:13 2005
@@ -315,8 +315,14 @@
ldl.ld = ld;
/*printf ("xfdf in: %s\n", dumpxf (ld));*/
- if (!ldl.l.upper && !ldl.l.middle && !ldl.l.lower)
-return 0;
+ /* Match +/- 0 and subnormals, which get flushed to 0 */
+ if ( EXPX(ldl) == 0 )
+{
+ /* Preserve sign */
+ dl.l.upper = SIGNX (ldl);
+ dl.l.lower = 0;
+ return dl.d;
+}
exp = EXPX (ldl) - EXCESSX + EXCESSD;
/* ??? quick and dirty: keep `exp' sane */
In the above case, both +/- 0 and subnormals cause a correctly signed double 0.0
to be returned. Is this the right fix?
In case it is:
2005-02-27 Jonathan Larmour <[EMAIL PROTECTED]>
* config/m68k/fpgnulib.c (__truncxfdf2): Match subnormals as well as
-0.0 in special case test, and preserve sign.
--
Summary: [m68k] long double -> double cast fails with -0.0
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20227
[Bug target/20228] New: [4.1 Regressions] Cannot link two valid C++ TU together
Try linking the following two C++ sources together:
struct a
{
virtual void g();
virtual void f(){}
};
int main() { a b; b.f(); b.g(); }
cut -
struct a
{
virtual void g();
virtual void f(){}
};
void a::g() {}
We get an error:
/tmp/ccFSWYxL.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
/tmp/ccUWWgfl.o(.gnu.linkonce.r._ZTI1a[typeinfo for a]+0x0): undefined
reference to `vtable for
__cxxabiv1::__class_type_info'
This is relative new binutils too:
GNU ld version 2.15.94 20041104
Also this breaks building libjava on the same target.
--
Summary: [4.1 Regressions] Cannot link two valid C++ TU together
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: wrong-code, build
Severity: critical
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20228
[Bug target/20228] [4.1 Regressions] Cannot link two valid C++ TU together
-- What|Removed |Added Target Milestone|--- |4.1.0 Version|4.0.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20228
[Bug target/20228] [4.1 Regressions] Cannot link two valid C++ TU together
-- What|Removed |Added CC||jules at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20228
[Bug target/20228] [4.1 Regressions] Cannot link two valid C++ TU together
-- What|Removed |Added GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20228
[Bug tree-optimization/20188] [4.0/4.1 Regression] asm and memory operands does not add a V_MAY_DEF
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 04:37 --- (In reply to comment #21) > inline_asm-2 test fails on all hppa targets. Fails on all targets, I just committed a fix for this: 2005-02-26 Andrew Pinski <[EMAIL PROTECTED]> * gcc.dg/tree-ssa/inline_asm-2.c: link_error produces a V_MAY_DEF also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20188
[Bug ada/20226] [4.0/4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-02-27 04:41 --- OK, I tried again with "make bootstrap", and I get a nearly identical problem: stage1/gnatbind -C -I- -I. -Iada -I/aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada -o ada/b_gnat1.c -n ada/gnat1drv.ali make[3]: *** [ada/b_gnat1.c] Error 5 make[3]: Leaving directory `/aaronwl/cs/env/mingw-head/20050226/build/gcc/gcc' make[2]: *** [stage2_build] Error 2 In gdb: Program received signal SIGSEGV, Segmentation fault. 0x004034e9 in __gnat_install_SEH_handler (ER=0x77c3b814) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/seh_init.c:219 219 ((int *)ER)[0] = (int)ptr; /* previous handler */ #0 0x004034e9 in __gnat_install_SEH_handler (ER=0x77c3b814) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/seh_init.c:219 #1 0x0040321b in __gnat_initialize (eh=0x77c3b814) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/init.c:840 #2 0x004015a8 in main (argc=10, argv=0x3d4250, envp=0x3d2fc0) at ada/b_gnatb.c:260 Inspecting the values above yield nothing apparently abnormal. In particular, ((int *)ER)[0] appears to be valid. Is this a codegen bug? -- What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226
[Bug debug/20229] New: -Wcast-qual option is easily evaded
The -Wcast-qual option in GCC can easily be evaded by "clever" hacks, which
seriously reduces the utility of this feature in catching dangerous behavior
intentionally hidden by programmers from unit testers.
Here is code for a test case (which is extremely simple, and includes no
headers, so I am sending the source rather than the virtually-identical
intermediate file, which lacks comments):
---
void evil_string_modifier(char *s) { s[0] = 0; }
int main(void) {
// This warns, as expected:
evil_string_modifier("Test string one.");
// This also warns, as expected:
evil_string_modifier((char *)"Test string two.");
// This, however, does not warn...but should:
evil_string_modifier((char *)(int)"Test string three.");
}
---
The compiler output for the code given above:
Using built-in specs.
Configured with: ./configure --prefix=/usr --host=i386-just-dragonflybsd
Thread model: posix
gcc version 3.4.3 [DragonFly] (propolice, visibility)
/usr/libexec/gcc34/cc1 -E -quiet -v -iprefix
/usr/libexec/gcc34/../gcc34//3.4.1/ bug.c -march=pentium3 -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
-Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts
-Winline -Wnested-externs -Wredundant-decls -O -o bug.i
ignoring nonexistent directory "/usr/libexec/gcc34/../gcc34//3.4.1/include"
ignoring nonexistent directory
"/usr/libexec/gcc34/../gcc34//3.4.1/libdata/gcc34"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/libdata/gcc34
End of search list.
/usr/libexec/gcc34/cc1 -fpreprocessed bug.i -quiet -dumpbase bug.c
-march=pentium3 -auxbase bug -O -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wall -W
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts
-Winline -Wnested-externs -Wredundant-decls -version -o bug.s
GNU C version 3.4.3 (i386-just-dragonflybsd)
compiled by GNU C version 2.95.4 20020320 [DragonFly].
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
bug.c:2: warning: no previous prototype for 'evil_string_modifier'
bug.c: In function `main':
bug.c:7: warning: passing arg 1 of `evil_string_modifier' discards qualifiers
from pointer target type
bug.c:10: warning: cast discards qualifiers from pointer target type
bug.c:15: warning: control reaches end of non-void function
as -o bug.o bug.s
ld -V -dynamic-linker /usr/libexec/ld-elf.so.1 -o bug /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib/gcc34 bug.o -lgcc -lc -lgcc
/usr/lib/crtend.o /usr/lib/crtn.o
GNU ld version 2.15 [DragonFly] 2004-05-17
Supported emulations:
elf_i386
--
Summary: -Wcast-qual option is easily evaded
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kmk at ssl dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20229
[Bug c/20229] -Wcast-qual option is easily evaded
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 05:02 --- Nope the following cannot be warned about because you first change the pointer to an integer and then cast it to a char pointer which is only defined iff int is the same size as the pointer (which is warned about on 64bit targets): // This, however, does not warn...but should: evil_string_modifier((char *)(int)"Test string three."); Not warning is correct as there is a cast inbetween. the docs are clear: Warn whenever a pointer is cast so as to remove a type qualifier from the target type. For example, warn if a const char * is cast to an ordinary char *. Since the cast to int is inbetween there, the warning does not makes sense any more. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|debug |c Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20229
[Bug c++/11585] static template member definition fails
-- What|Removed |Added CC||jaco at kroon dot co dot za Target Milestone|3.4.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11585
[Bug debug/20230] New: GCC generates non-compliant warnings for qualifier promotion
When compiling code with GCC that involves passing an unqualified object to a
function that advertises certain qualification guarantees, unsuppressible
warnings are generated about passing "incompatible types."
That these types are formally incompatible under the standard is not in
question. It is, however, irrelevant. While I do not possess the ISO document
(C++ is my native tongue, and G++ does not exhibit this flaw), I was able to
download draft n843 from the Internet, and it explicitly states:
"For any qualifier q, a pointer to a non-q-qualified type may be converted to a
pointer to the q-qualified version of the type; the values stored in the
original and converted pointers shall compare equal." [section 6.3.2.3,
paragraph 2]
The intention of this provision is quite clear: functions should be able to
advertise qualification guarantees that are more strict than the actual
qualifications of any call parameters supplied to the function when it is
called. By generating unsuppressible warnings for explicitly-permitted qualifier
promotions, GCC makes it impossible to avoid warnings when compiling code that
is completely in compliance with the standard. This greatly complicates the
maintenance of warnings-free code in complex development environments and
critically reduces the utility of the const keyword.
Test case:
--
void safe_function(const char *const *s) { }
int main(void) {
char *mystrings[2] = { "First string", "Second string" };
// This call warns, but should not:
safe_function(mystrings);
}
--
Compiler output:
Using built-in specs.
Configured with: ./configure --prefix=/usr --host=i386-just-dragonflybsd
Thread model: posix
gcc version 3.4.3 [DragonFly] (propolice, visibility)
/usr/libexec/gcc34/cc1 -E -quiet -v -iprefix
/usr/libexec/gcc34/../gcc34//3.4.1/ bug2.c -march=pentium3 -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
-Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts
-Winline -Wnested-externs -Wredundant-decls -O -o bug2.i
ignoring nonexistent directory "/usr/libexec/gcc34/../gcc34//3.4.1/include"
ignoring nonexistent directory
"/usr/libexec/gcc34/../gcc34//3.4.1/libdata/gcc34"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/libdata/gcc34
End of search list.
/usr/libexec/gcc34/cc1 -fpreprocessed bug2.i -quiet -dumpbase bug2.c
-march=pentium3 -auxbase bug2 -O -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wall -W
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts
-Winline -Wnested-externs -Wredundant-decls -version -o bug2.s
GNU C version 3.4.3 (i386-just-dragonflybsd)
compiled by GNU C version 2.95.4 20020320 [DragonFly].
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
bug2.c:2: warning: no previous prototype for 'safe_function'
bug2.c:2: warning: unused parameter 's'
bug2.c: In function `main':
bug2.c:6: warning: initialization discards qualifiers from pointer target type
bug2.c:6: warning: initialization discards qualifiers from pointer target type
bug2.c:9: warning: passing arg 1 of `safe_function' from incompatible pointer
type
bug2.c:11: warning: control reaches end of non-void function
as -o bug2.o bug2.s
ld -V -dynamic-linker /usr/libexec/ld-elf.so.1 -o bug2 /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib/gcc34 bug2.o -lgcc -lc -lgcc
/usr/lib/crtend.o /usr/lib/crtn.o
GNU ld version 2.15 [DragonFly] 2004-05-17
Supported emulations:
elf_i386
--
Summary: GCC generates non-compliant warnings for qualifier
promotion
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kmk at ssl dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug debug/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 05:30 --- Note the following warning basically says this is invalid C: bug2.c:9: warning: passing arg 1 of `safe_function' from incompatible pointer type use -pedantic-errors and you will see that it is converted to an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
-- What|Removed |Added Component|debug |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 05:32 --- Quals can only be promoted once. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug c/20229] -Wcast-qual option is easily evaded
--- Additional Comments From kmk at ssl dot org 2005-02-27 05:40 --- Actually, the documentation clearly claims: "Warn WHENEVER a pointer is cast so as to remove a type qualifier from the target type." It does not say: "Warn whenever a pointer is cast to ANOTHER POINTER in such a way that it removes a type qualifier from the target type." Casting a const pointer to any non-pointer object will remove the const qualifier from the pointer, no matter how you look at it. To not flag this abuse is not only in obvious contradiction with the documentation, it makes the option utterly useless for detecting intentionally dangerous behavior by programmers. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20229
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From kmk at ssl dot org 2005-02-27 06:03 ---
Exactly where does it state that you can only promote one _level_ of qualifier,
as opposed to promoting a single qualifier scope more than once?
Not only that, but even if you declare the string array this way,
char a[8], b[8];
char *const mystrings[2] = { a, b };
it _still_ fails. There is only one level of promotion left here, no matter how
you look at it.
--
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug c++/11585] static template member definition fails
--- Additional Comments From jaco at kroon dot co dot za 2005-02-27 06:17 --- $ g++ -o templates templates.C -Wall /tmp/ccoANWiL.o(.gnu.linkonce.t._ZN7FactoryIiE9createOneEv+0xd): In function `Factory::createOne()': : undefined reference to `Factory::_types' collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11585
[Bug c++/19948] [4.0/4.1 Regression] ICE: tree check: expected class 'declaration', have 'exceptional' (error_mark) in pushtag, at cp/name-lookup.c:4658
--- Additional Comments From fang at csl dot cornell dot edu 2005-02-27
06:25 ---
1) Has anyone figured out a workaround to this yet? I suppose I could remove
some using
namespace declarations and prefix type names with namespaces... I'll keep
tinkering around.
2) New and perhaps closely related bug?
g++-4.0 is also rejecting-valid the following code, tweaked from Andrew's
example to reproduce
something else I'm doing in my project: (using same version info as reported
here)
//-- snip ---
namespace util
{
class persistent_object_manager;
namespace memory
{
class pointer_manipulator
{
friend class persistent_object_manager;
};
}
}
namespace util
{
using namespace memory;
class persistent_object_manager
{
static const int foo;
};
}
namespace util {
const int
persistent_object_manager::foo = 666;
}
//--- end snip
g++-4.0 -c blah.cc -o blah.o
reports:
blah.cc:24: error: 'persistent_object_manager' has not been declared
whereas 3.3 and 3.4 accept the code.
Removing the friend declaration on line 8 allows g++-4.0 to compile.
Removing the using namespace memory line 14 also allows g++-4.0 to compile.
It was difficult to find a bug in the bugzilla database with the same
characteristics.
Should I file a separate bug report for this one or just tack it on to this one
because it's probably closely
related?
-- David
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19948
[Bug c++/19948] [4.0/4.1 Regression] ICE: tree check: expected class 'declaration', have 'exceptional' (error_mark) in pushtag, at cp/name-lookup.c:4658
--- Additional Comments From fang at csl dot cornell dot edu 2005-02-27 06:53 --- Workaround discovered (shortly after I asked for one, fancy that!) Declaring: using util::persistent_object_manager; inside the 'memory' namespace before the first friend declaration (after line 5) results in correct output for the examples listed above. The using declaration prevents (I think) injection of the friend class declaration into the 'memory' namespace and further confusion. Not a bad idea in practice, actually. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19948
[Bug tree-optimization/20231] New: missed optimization of loop IV modulus
[zebes:~] astrange% /usr/local/bin/gcc -v
Using built-in specs.
Target: powerpc-apple-darwin7.7.0
Configured with: ../configure --enable-threads=posix --with-threads=posix
Thread model: posix
gcc version 4.1.0 20050226 (experimental)
Command line: /usr/local/bin/gcc -O3 -mcpu=7400 -mtune=7400
-fdump-tree-optimized -c
mod_loop.c
Code:
void mod_loop(unsigned char *array, int len, unsigned char repeat)
{
unsigned char i;
for (i = 0; i < len; i++) array[i] = i%repeat;
}
void mod_loop2(unsigned char *array, int len, unsigned char repeat)
{
unsigned char i,i2=0;
for (i = 0; i < len; i++) {array[i] = i2++; if (i2 == repeat) i2 = 0;}
}
Although the two functions are equivalent and mod_loop2 is better (avoiding an
expensive divide), GCC
doesn't transform the first into the second.
--
Summary: missed optimization of loop IV modulus
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.7.0
GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20231
[Bug tree-optimization/20231] missed optimization of loop IV modulus
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 06:55 --- Confirmed, this is semi hard. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|powerpc-apple-darwin7.7.0 | GCC host triplet|powerpc-apple-darwin7.7.0 | Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-02-27 06:55:42 date|| Summary|missed optimization of loop |missed optimization of loop |IV modulus |IV modulus http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20231
