[Bug target/20228] [4.1 Regressions] Cannot link two valid C++ TU together
--- Additional Comments From giovannibajo at libero dot it 2005-02-27 08:45 --- I'm not sure this matters, but the program is actually invalid, there is a double definition of A::f. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20228
[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 giovannibajo at libero dot it 2005-02-27 08:49 --- Please, always fill a different bugreport for different testcases, unless you can prove it is exactly the same problem (and here you surely cannot). Then add references forth and back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19948
[Bug c++/11585] static template member definition fails
--- Additional Comments From giovannibajo at libero dot it 2005-02-27 09:03 --- Ah no, then it is ok. When you write: template FakeListIntFactory::TypePair IntFactory::_types; you are actually *declaring* a specialization of _types. A declaration is not a definition, so the linker complains. To mutate this into a definition you need to disambiguate the statement by adding an explicit constructor. For instance: template FakeListIntFactory::TypePair IntFactory::_types = FakeListIntFactory::TypePair(); In this way, the declaration of the specialization is also a definition, and the code compiles and links correctly. But are you sure you want to declare a specialization of the static member in the first place? Probably you just want to define the static member for all the possible instantiations. In this case, the syntax is much easier: template class T FakeListtypename FactoryT::TypePair FactoryT::_types; and you don't need to repeat this for IntFactory, FloatFactory, WhateverFactory. For more information, please consult a good book about C++ templates or ask somewhere else (comp.lang.c++.moderated, for instance). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11585
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Additional Comments From giovannibajo at libero dot it 2005-02-27 09:11 --- Is this a regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug target/20228] [4.1 Regressions] Cannot link two valid C++ TU together
--- Additional Comments From giovannibajo at libero dot it 2005-02-27 09:31 --- Ignore my last comment. I shouldn't post before shower :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20228
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From anton at mips dot complang dot tuwien dot ac dot at 2005-02-27 10:47 --- Subject: Re: [3.3/3.4/4.0 regression] pessimization of goto * steven at gcc dot gnu dot org wrote: Updated patch for this problem Ok, I have now tried it with gcc-4.0-20050220 and gforth-0.6.2 on i386 and it works ok. There is a minor remaining regression related to this issue: gcc-4.0 compiles goto **(ip-1); into 0x804b50d engine+1341:mov0xfffc(%ebx),%eax 0x804b510 engine+1344:jmp*%eax gcc-2.95 compiles it into 0x804b103 engine+227: jmp*0xfffc(%ebx) which looks better. Maybe there should be another combining pass after the duplication of the indirect jumps. Should I create another PR for this? Here are updated timing results (gforth-0.6.2 configured with --enable-force-reg): Pentium 4 2.26GHz; numbers are times in seconds user time gcc-4.0-20050220 gcc-2.95.3 gcc-3.3 gcc-3.4.0 default no-reorder-blocks dynamic no-dyn dynamic no-dyn no-dyndynamic dynamic siev0.240.480.310.470.50 0.370.28 bubble 0.300.780.360.770.78 0.400.36 matrix 0.190.940.170.920.96 0.180.18 fib 0.340.570.410.580.59 0.430.40 - anton -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From falk at debian dot org 2005-02-27 11:16 --- The C standard does in fact not allow this conversion. However, I agree that it might be nice to have an option for semantics as in the C++ standard (4.4). They allow this, and it is safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug tree-optimization/20231] missed optimization of loop IV modulus
--- Additional Comments From falk at debian dot org 2005-02-27 11:23 --- Here's a paper about this if anybody wants to do this systematically: Saman Amarasinghe, Walter Lee, Ben Greenwald. Strength Reduction of Integer Division and Modulo Operations LCPC 2001 http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TM-600.pdf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20231
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From kmk at ssl dot org 2005-02-27 12:48 --- I'm not sure I understand why it is thought that the C standard forbids the conversion I'm talking about here. In fact, the final committee draft of the ISO C standard that I have appears to be silent about the issue of multi-level pointer conversions entirely. As noted by F. Hueffner, conversion rules are made quite explicit in the C++ standard: In ISO/IEC 14882 4.4.4, multi-level pointer conversions are explicitly constrained by restricting automatic qualifier promotion to only those levels for which _all_ preceding levels are const. The example that follows the paragraph furthers the point by noting: if a program could assign a pointer of type T** to a pointer of type const T**...a program could inadvertently modify a const object. Absolutely. But that's not what I'm talking about. GCC issues an unsuppressible warning when a conversion is made between: char *const *object -- const char *const *object or the equivalently innocuous char **object -- const char *const *object Nothing I can find in the FCD of the C standard forbids _any_ multi-level conversion---safe or unsafe. GCC, however, warns about every such conversion (even though it actually performs them). If it's going to complain, it really should only complain about unsafe conversions as per the C++ standard---despite the fact that all conversions appear to be legal in C. Am I wrong? Where does it state in the C standard that you cannot perform a multi-level qualifier promotion? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug c++/20232] New: ICE with covariancy
The attached invalid program ICEs mainline and 4.0 -- Summary: ICE with covariancy Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nathan at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20232
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-27
12:52 ---
Is this really fixed?
Look at this:
$ cat c-div.c
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a,b);
c = b/a;
return creal(c) + cimag(c) 0;
}
$ gcc -ffast-math -O3 -fdump-tree-optimized -fno-cx-limited-range -S c-div.c
$ tail -20 c-div.c.t65.optimized
if (ABS_EXPR SR.26 0.0) goto L1; else goto L2;
L1:;
D.3021 = SR.26 * Inf;
D.3022 = SR.26 * D.3021;
c$real = (D.3012 + D.3011 * D.3021) / D.3022;
c$imag = (D.3012 * D.3021 - D.3011) / D.3022;
goto bb 3;
L2:;
D.3030 = 0.0 / SR.26;
c$real = (D.3011 + D.3012 * D.3030) / SR.26;
c$imag = (D.3012 - D.3011 * D.3030) / SR.26;
bb 3:
return (double) c$real + (double) c$imag 0.0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug c++/20232] ICE with covariancy
--- Additional Comments From nathan at gcc dot gnu dot org 2005-02-27 12:59 --- Created an attachment (id=8292) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8292action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20232
[Bug c++/20232] ICE with covariancy
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-27 13:00:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20232
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From joseph at codesourcery dot com 2005-02-27
13:05 ---
Subject: Re: New: GCC generates non-compliant warnings for
qualifier promotion
On Sun, 27 Feb 2005, kmk at ssl dot org wrote:
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]
All my references in what follows are to the standard itself, C99 as
amended by TC1 and TC2. Using drafts is a false economy.
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);
The constraints for function calls are not in 6.3.2.3, they are in
6.5.2.2#2, which references the constraints for assignment in 6.5.16.1#1.
6.5.16.1 Simple assignment
Constraints
[#1] One of the following shall hold:93)
-- the left operand has qualified or unqualified
arithmetic type and the right has arithmetic type;
Not applicable.
-- the left operand has a qualified or unqualified version
of a structure or union type compatible with the type
of the right;
Not applicable.
-- both operands are pointers to qualified or unqualified
versions of compatible types, and the type pointed to
by the left has all the qualifiers of the type pointed
to by the right;
The type on the left is const char *const *. That on the right is char
**. These are pointers to const char * const and char *. These
types are qualified or unqualified versions of const char * and char
*. (Qualification is defined in 6.2.5#25: each of char * and const
char * has seven qualified versions, while plain char * and const char
* are both unqualified types; note the last sentence of that paragraph,
A derived type is not qualified by the qualifiers (if any) of the type
from which is is derived., and the definition of pointer types as derived
types in paragraph 20.) const char * and char * are unqualified
types which are not compatible: compatibility is defined in 6.2.7#1 and
6.7.3#9 says when qualified types are compatible. Note that char and
const char are not compatible, because they don't have the same
qualifiers, so char * and const char * are not compatible, and the
unqualified version of const char *const is const char * not char *
by the definition of qualification.
-- one operand is a pointer to an object or incomplete
type and the other is a pointer to a qualified or
unqualified version of void, and the type pointed to by
the left has all the qualifiers of the type pointed to
by the right;
Not applicable.
-- the left operand is a pointer and the right is a null
pointer constant; or
Not applicable.
-- the left operand has type _Bool and the right is a
pointer.
Not applicable.
None of the above apply, so GCC diagnoses the constraint violation. If
you want C++ rules, GCC provides a C++ compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From falk at debian dot org 2005-02-27 13:20 --- (In reply to comment #5) Am I wrong? Where does it state in the C standard that you cannot perform a multi-level qualifier promotion? Nowhere. It follows from the fact that it is not allowed explicitly in 6.5.16.1. The demand is: -- both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right; but pointer to char is not compatible with const pointer to const char. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug fortran/19479] UBOUND causes ICE
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 13:54 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-02/msg00357.html -- What|Removed |Added CC||tobi at gcc dot gnu dot org Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19479
[Bug c/20233] New: compiler errors while compiling kernel in Mepis Linux
While trying to compile the 2.6.10 kernel I get the following error everytime. Never seeen this error before, and looks to be a bug. drivers/mmc/mmc_block.c: In function `mmc_blk_issue_rq': drivers/mmc/mmc_block.c:183: warning: `req' is deprecated (declared at include/linux/mmc/mmc.h:60) CC [M] drivers/mmc/wbsd.o drivers/mmc/wbsd.c: In function `wbsd_init_sg': drivers/mmc/wbsd.c:208: warning: `req' is deprecated (declared at include/linux/mmc/mmc.h:60) drivers/mmc/wbsd.c:208: warning: unused variable `req' CC [M] drivers/net/slhc.o CC [M] drivers/net/plip.o CC [M] drivers/net/rrunner.o CC [M] drivers/net/mii.o CC [M] drivers/net/ethertap.o CC [M] drivers/net/8390.o CC [M] drivers/net/shaper.o CC [M] drivers/net/ppp_generic.o CC [M] drivers/net/ppp_async.o CC [M] drivers/net/ppp_synctty.o CC [M] drivers/net/ppp_deflate.o CC [M] drivers/net/bsd_comp.o CC [M] drivers/net/pppox.o CC [M] drivers/net/pppoe.o CC [M] drivers/net/slip.o CC [M] drivers/net/dummy.o CC [M] drivers/net/defxx.o CC [M] drivers/net/eql.o CC [M] drivers/net/tun.o CC [M] drivers/net/arcnet/arcnet.o CC [M] drivers/net/arcnet/rfc1201.o CC [M] drivers/net/arcnet/rfc1051.o CC [M] drivers/net/arcnet/arc-rawmode.o CC [M] drivers/net/arcnet/com90xx.o CC [M] drivers/net/arcnet/com90io.o CC [M] drivers/net/arcnet/arc-rimi.o CC [M] drivers/net/arcnet/com20020.o CC [M] drivers/net/arcnet/com20020-isa.o CC [M] drivers/net/arcnet/com20020-pci.o CC [M] drivers/net/bonding/bond_main.o CC [M] drivers/net/bonding/bond_3ad.o CC [M] drivers/net/bonding/bond_alb.o LD [M] drivers/net/bonding/bonding.o CC [M] drivers/net/irda/irport.o CC [M] drivers/net/irda/irda-usb.o CC [M] drivers/net/irda/nsc-ircc.o CC [M] drivers/net/irda/w83977af_ir.o CC [M] drivers/net/irda/donauboe.o CC [M] drivers/net/irda/smsc-ircc2.o CC [M] drivers/net/irda/ali-ircc.o CC [M] drivers/net/irda/vlsi_ir.o CC [M] drivers/net/irda/via-ircc.o CC [M] drivers/net/irda/esi.o CC [M] drivers/net/irda/tekram.o CC [M] drivers/net/irda/actisys.o CC [M] drivers/net/irda/girbil.o CC [M] drivers/net/irda/litelink.o CC [M] drivers/net/irda/old_belkin.o CC [M] drivers/net/irda/mcp2120.o CC [M] drivers/net/irda/act200l.o CC [M] drivers/net/irda/ma600.o CC [M] drivers/net/irda/irtty-sir.o CC [M] drivers/net/irda/sir_core.o CC [M] drivers/net/irda/sir_dev.o CC [M] drivers/net/irda/sir_dongle.o CC [M] drivers/net/irda/sir_kthread.o LD [M] drivers/net/irda/sir-dev.o CC [M] drivers/net/irda/esi-sir.o CC [M] drivers/net/irda/tekram-sir.o CC [M] drivers/net/irda/actisys-sir.o CC [M] drivers/net/irda/litelink-sir.o CC [M] drivers/net/irda/girbil-sir.o CC [M] drivers/net/irda/old_belkin-sir.o CC [M] drivers/net/irda/mcp2120-sir.o CC [M] drivers/net/irda/act200l-sir.o CC [M] drivers/net/irda/ma600-sir.o CC [M] drivers/net/pcmcia/3c589_cs.o CC [M] drivers/net/pcmcia/3c574_cs.o CC [M] drivers/net/pcmcia/fmvj18x_cs.o CC [M] drivers/net/pcmcia/nmclan_cs.o CC [M] drivers/net/pcmcia/pcnet_cs.o CC [M] drivers/net/pcmcia/smc91c92_cs.o CC [M] drivers/net/pcmcia/xirc2ps_cs.o CC [M] drivers/net/pcmcia/com20020_cs.o CC [M] drivers/net/pcmcia/axnet_cs.o CC [M] drivers/net/skfp/skfddi.o CC [M] drivers/net/skfp/hwmtm.o drivers/net/skfp/hwmtm.c: In function `hwm_tx_frag': drivers/net/skfp/hwmtm.c:1699: warning: passing arg 2 of `writel' makes pointerfrom integer without a cast drivers/net/skfp/hwmtm.c: In function `smt_send_mbuf': drivers/net/skfp/hwmtm.c:1940: warning: passing arg 2 of `writel' makes pointerfrom integer without a cast CC [M] drivers/net/skfp/fplustm.o CC [M] drivers/net/skfp/smt.o CC [M] drivers/net/skfp/cfm.o include/linux/byteorder/little_endian.h: In function `__le64_to_cpup': include/linux/byteorder/little_endian.h:50: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.3/README.Bugs. make[5]: *** [drivers/net/skfp/cfm.o] Error 1 make[4]: *** [drivers/net/skfp] Error 2 make[3]: *** [drivers/net] Error 2 make[2]: *** [drivers] Error 2 make[2]: Leaving directory `/usr/src/kernel-source-2.6.10' make[1]: *** [stamp-build] Error 2 make[1]: Leaving directory `/usr/src/kernel-source-2.6.10' make: *** [stamp-buildpackage] Error 2 -- Summary: compiler errors while compiling kernel in Mepis Linux Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: csalsb at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20233
[Bug libfortran/20163] gfortran - error opening direct access file
--- Additional Comments From dir at lanl dot gov 2005-02-27 14:05 ---
Looks like a missing call to library_end ()in open.c. I added that one line and
the recursive error went away -
[dir:~/tests/gfortran] dir% gfortran -o recursive3 recursive3.f
[dir:~/tests/gfortran] dir% recursive3
[dir:~/tests/gfortran] dir% cat recursive3.f
open(10,status=foo,err=100)
call abort
100 continue
open(10,status=scratch)
end
[dir:~] dir% diff -c /Users/dir/junk/io/open.c
/Users/dir/gfortran/gcc/libgfortran/io/open.c
*** /Users/dir/junk/io/open.c Sat Jan 22 16:14:30 2005
--- /Users/dir/gfortran/gcc/libgfortran/io/open.c Sat Feb 26 21:36:28 2005
***
*** 480,488
if (flags.position == POSITION_UNSPECIFIED)
flags.position = POSITION_ASIS;
! if (ioparm.library_return != LIBRARY_OK)
return;
!
u = find_unit (ioparm.unit);
if (u == NULL)
--- 480,489
if (flags.position == POSITION_UNSPECIFIED)
flags.position = POSITION_ASIS;
! if (ioparm.library_return != LIBRARY_OK){
! library_end ();
return;
! }
u = find_unit (ioparm.unit);
if (u == NULL)
(In reply to comment #5)
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 c++/18491] testsuite failure: WARNING: g++.old-deja/g++.mike/p10769a.C compilation failed to produce executable
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-27 14:39 --- It's about time to close this one, the test-case being removed and all... -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18491
[Bug target/19745] [meta-bug]: cris-elf gcc, g++, objc testsuite failures as of Tue Feb 1 22:03:59 UTC 2005
-- Bug 19745 depends on bug 18491, which changed state. Bug 18491 Summary: testsuite failure: WARNING: g++.old-deja/g++.mike/p10769a.C compilation failed to produce executable http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18491 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19745
[Bug target/19745] [meta-bug]: cris-elf gcc, g++, objc testsuite failures as of Tue Feb 1 22:03:59 UTC 2005
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-27 14:51 --- Update. Remaining from the original list (i.e. new ones uncounted) are, as of LAST_UPDATED Sun Feb 27 01:30:09 UTC 2005: Running /home/hp/combined/combined/gcc/testsuite/gcc.dg/dg.exp ... WARNING: gcc.dg/20010912-1.c compilation failed to produce executable FAIL: gcc.dg/20020430-1.c (test for excess errors) FAIL: gcc.dg/20021018-1.c (test for excess errors) WARNING: gcc.dg/20021018-1.c compilation failed to produce executable FAIL: gcc.dg/20021023-1.c (test for excess errors) FAIL: gcc.dg/20021029-1.c (test for excess errors) ERROR: gcc.dg/20021029-1.c: error executing dg-final: couldn't open 20021029-1.s: no such file or directory WARNING: gcc.dg/20030225-1.c compilation failed to produce executable FAIL: gcc.dg/20030702-1.c (test for excess errors) FAIL: gcc.dg/20030708-1.c (test for excess errors) FAIL: gcc.dg/20040311-2.c (test for excess errors) FAIL: gcc.dg/Wpadded.c (test for warnings, line 10) FAIL: gcc.dg/bitfld-3.c execution test FAIL: gcc.dg/intmax_t-1.c (test for excess errors) FAIL: gcc.dg/setjmp-1.c spurious clobbered warning (test for bogus messages, line 16) FAIL: gcc.dg/trampoline-1.c execution test XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times link_error 0 FAIL: gcc.dg/tree-ssa/loop-1.c scan-assembler-times foo 5 FAIL: gcc.dg/weak/typeof-2.c scan-assembler baz3.*baz3.*baz3.*baz3.*baz3.*baz3 Running /home/hp/combined/combined/gcc/testsuite/g++.dg/dg.exp ... FAIL: g++.dg/abi/bitfield12.C (test for warnings, line 3) FAIL: g++.dg/abi/vbase10.C (test for warnings, line 13) FAIL: g++.dg/ext/visibility/noPLT.C (test for excess errors) ERROR: g++.dg/ext/visibility/noPLT.C: error executing dg-final: couldn't open noPLT.s: no such file or directory FAIL: g++.dg/opt/vt1.C (test for excess errors) ERROR: g++.dg/opt/vt1.C: error executing dg-final: couldn't open vt1.s: no such file or directory Running /home/hp/combined/combined/gcc/testsuite/g++.old-deja/old-deja.exp ... FAIL: g++.old-deja/g++.jason/thunk2.C (test for excess errors) WARNING: g++.old-deja/g++.jason/thunk2.C compilation failed to produce executable (no failing objc tests) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19745
[Bug c/20229] -Wcast-qual option is easily evaded
--- Additional Comments From schwab at suse dot de 2005-02-27 14:54 --- Casting to an integer does not remove the qualifier from the target type, it removes the target type completely. Since an integer is not a pointer, there cannot be a target type any more. So the documentation is correct. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20229
[Bug c/20229] -Wcast-qual option is easily evaded
--- Additional Comments From joseph at codesourcery dot com 2005-02-27 14:59 --- Subject: Re: -Wcast-qual option is easily evaded On Sun, 27 Feb 2005, schwab at suse dot de wrote: Casting to an integer does not remove the qualifier from the target type, it removes the target type completely. Since an integer is not a pointer, there cannot be a target type any more. So the documentation is correct. I would add that it is *useful* for programmers to be able to avoid the warning in cases where they know what they are doing. That is, it's a *feature* that one can define #define remove_const(x, type) ((type)(size_t)(x)) and so avoid the warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20229
[Bug rtl-optimization/17356] [4.0/4.1 Regression] [Ada] [ia64] ACATS c41325a other ICE, also while building libada
--- Additional Comments From schwab at suse dot de 2005-02-27 15:09 --- Only happens with --enable-checking. -- What|Removed |Added Keywords||ice-checking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17356
[Bug target/20233] compiler errors while compiling kernel in Mepis Linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 15:21 --- Obviously you did not read:URL:http://gcc.gnu.org/bugs.html as instructed. We need the preprocessed source. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Component|c |target Version|unknown |3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20233
[Bug c++/20232] [4.0/4.1 Regression] ICE with covariancy
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 15:34 --- Confirmed, a regression also. It worked with 20050113. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||error-recovery, ice-on- ||invalid-code Known to fail||4.0.0 Known to work||3.4.0 Last reconfirmed|2005-02-27 13:00:07 |2005-02-27 15:34:02 date|| Summary|ICE with covariancy |[4.0/4.1 Regression] ICE ||with covariancy Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20232
[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 15:40 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01723.html. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug c++/20234] New: incorrect error: class has not been declared
g++-4.0s give the following incorrect error on valid code (it should be
accepted, I think):
gcc4rejectvalid.cc:25: error: 'persistent_object_manager' has not been declared
Run command
g++-4.0 -v --save-temps -c gcc4rejectvalid.cc -o gcc4rejectvalid.o
Output with version specs:
Using built-in specs.
Configured with: ../configure --prefix=/sw --prefix=/sw/lib/gcc4 --enable-
languages=c,c++,objc,f95,java --infodir=/share/info --with-gmp=/sw
--with-as=/sw/lib/odcctools/
bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-included-gettext
--host=powerpc-apple-darwin
Thread model: posix
gcc version 4.0.0 20050130 (experimental)
/sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin/4.0.0/cc1plus -E -quiet -v
-D__DYNAMIC__
-D__APPLE_CC__=1 gcc4rejectvalid.cc -fPIC -fpch-preprocess -o gcc4rejectvalid.ii
ignoring nonexistent directory
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/../../../../powerpc-
apple-darwin/include
#include ... search starts here:
#include ... search starts here:
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/../../../../include/c++/4.0.0
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/../../../../include/c++/4.0.0/powerpc-apple-
darwin
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/../../../../include/c++/4.0.0/backward
/usr/local/include
/sw/lib/gcc4/include
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
/sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin/4.0.0/cc1plus -fpreprocessed
gcc4rejectvalid.ii
-fPIC -quiet -dumpbase gcc4rejectvalid.cc -auxbase-strip gcc4rejectvalid.o
-version -o
gcc4rejectvalid.s
GNU C++ version 4.0.0 20050130 (experimental) (powerpc-apple-darwin)
compiled by GNU C version 3.3 20030304 (Apple Computer, Inc. build
1640).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
gcc4rejectvalid.cc:25: error: 'persistent_object_manager' has not been declared
- gcc4rejectvalid.ii ---
# 1 gcc4rejectvalid.cc
# 1 built-in
# 1 command line
# 1 gcc4rejectvalid.cc
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-of-file
Remarks:
The above code is accepted by gcc-3.3 and 3.4.
The example above was created from a variation of the code reported in PR
19948, and may be closely
related.
The error goes away when:
1) the first friend declaration is class pointer_manipulator is removed.
2) add a using util::persistent_object_manager; in namespace memory before
defining class
pointer_manipulator.
Workaround:
Use 2). (This workaround also applies to PR 19948.)
--
Summary: incorrect error: class has not been declared
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fang at csl dot cornell dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20234
[Bug target/20228] [4.1 Regressions] Cannot link two valid C++ TU together
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27
15:50 ---
Ignore the sources in comment #0, I got the definition wrong.
The following is the way libjava produces the code (now I don't know if this is
valid or not):
source 1 -
struct a
{
virtual void g();
virtual void f();
};
void a::f(){}
int main() { a b; b.f(); b.g(); }
cut -
struct a
{
virtual void g();
virtual void f(){}
};
void a::g() {}
- cut --
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20228
[Bug libfortran/20101] zero prints incorrectly with 1pe12.4
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-27 15:54 --- Patch submitted: http://gcc.gnu.org/ml/fortran/2005-02/msg00362.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20101
[Bug libfortran/18025] libgfortran: format, incompatible minimum width edit descriptor
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-27 16:01 --- Portland, Sun, Intel and SX compilers does it with no leading blank. MIPSpro compiler is the only I could find that puts leading blanks. -- What|Removed |Added CC||coudert at clipper dot ens ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18025
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
--- Additional Comments From schwab at suse dot de 2005-02-27 16:08 --- I can reproduce it with a cross compiler from powerpc64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Additional Comments From hjl at lucon dot org 2005-02-27 16:16 --- __attribute__ ((visibility (hidden))) is a new feature. We can define ASM_OUTPUT_EXTERNAL to make it work properly. I can try to come up with a patch if everyone agrees is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug rtl-optimization/17728] [3.4 Regression] ICE in extract_insn, at recog.c:2083, unrecognizable insn
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-27 16:17 --- Subject: Bug 17728 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-02-27 16:17:09 Modified files: gcc: ChangeLog gcc/config/pa : pa.md Log message: PR rtl-optimization/17728 * pa.md (mulsi3, divsi3, udivsi3, modsi3): Change predicate for operand 0 from general_operand to move_dest_operand. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.8r2=2.7592.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa.md.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.158r2=1.158.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17728
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 16:19 --- (In reply to comment #7) __attribute__ ((visibility (hidden))) is a new feature. We can define ASM_OUTPUT_EXTERNAL to make it work properly. I can try to come up with a patch if everyone agrees is a bug. It is not that new. It was not introduced with 4.0, it has been in gcc since at least Febuary of 2002, so it is 3 years old now and nobody noticed this before, I really doubt this is gcc bug as it works correctly on ppc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug rtl-optimization/17728] [3.4 Regression] ICE in extract_insn, at recog.c:2083, unrecognizable insn
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-27 16:32 --- Subject: Bug 17728 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-27 16:32:15 Modified files: gcc: ChangeLog gcc/config/pa : pa.md Log message: PR rtl-optimization/17728 * pa.md (mulsi3, divsi3, udivsi3, modsi3): Change predicate for operand 0 from general_operand to move_dest_operand. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7605r2=2.7606 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa.md.diff?cvsroot=gccr1=1.158r2=1.159 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17728
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Additional Comments From hjl at lucon dot org 2005-02-27 16:32 --- My guess is this is an ELF only bug. I don't beleive ppc-darwin is an ELF target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
--- Additional Comments From schwab at suse dot de 2005-02-27 16:33 --- Broken by this change: 2005-01-01 Richard Henderson [EMAIL PROTECTED] PR c/19031 * c-decl.c (pop_file_scope): Call maybe_apply_pending_pragma_weaks. * c-lang.c (finish_file): Don't do it here. * objc/objc-act.c (objc_finish_file): Likewise. * cgraph.c (decl_assembler_name_equal): New. (cgraph_node_for_asm, cgraph_varpool_node_for_asm): New. (cgraph_varpool_node): Actually link up cgraph_varpool_nodes. * cgraph.h (struct cgraph_varpool_node): Add next. (cgraph_node_for_asm, cgraph_varpool_node_for_asm): Declare. * varasm.c (assemble_alias): Mark the target as needed. -- What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-27 16:33:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug fortran/20235] New: Gfortran internal read error
/sodsim/local/gcc-4.0-20050220#gcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../configure --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050220 (experimental) Build with no problems. This little test program was created as a result of a runtime error on a large program used to test gfortran. G77 does not have this problem. program ntst character*16 bufld character*142 line open (10,file='bumsls',status='old') 32 read (10,'(a)',end=33) line if (line(1:1) .eq. '.') goto 32 write(*,*) 'write values on the line ',line write(*,*) read (line,79) bufld,budelt 79 format (t43,a16,t61,f8.0) write(*,*) 'write 2 values from the line ',bufld,budelt write(*,*) 33 continue end At line 14 of file ntst.f Fortran runtime error: Bad value during floating point read -- Summary: Gfortran internal read error Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: blime at cox dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20235
[Bug c++/20206] [4.0/4.1 Regression] COMDAT broken for C++ thunks
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-27 17:14 --- Subject: Bug 20206 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-27 17:13:28 Modified files: gcc/cp : ChangeLog gcc/testsuite : ChangeLog gcc/cp : decl.c Added files: gcc/testsuite/g++.dg/opt: covariant1.C thunk2.C Log message: PR c++/20206 * decl.c (cxx_comdat_group): Put thunks for TARGET_USE_LOCAL_THUNK_ALIAS_P (function) functions into the same comdat group as the thunk target. * g++.dg/opt/thunk2.C: New test. * g++.dg/opt/covariant1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4648r2=1.4649 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5091r2=1.5092 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1371r2=1.1372 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/covariant1.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/thunk2.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20206
[Bug rtl-optimization/17728] [3.4 Regression] ICE in extract_insn, at recog.c:2083, unrecognizable insn
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-27 17:15 --- Subject: Bug 17728 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-27 17:14:38 Modified files: gcc: ChangeLog gcc/config/pa : pa.md Log message: PR rtl-optimization/17728 * pa.md (mulsi3, divsi3, udivsi3, modsi3): Change predicate for operand 0 from general_operand to move_dest_operand. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.807r2=2.2326.2.808 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa.md.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.138.4.8r2=1.138.4.9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17728
[Bug fortran/20236] New: Gfortran internal read error
/sodsim/local/gcc-4.0-20050220#gcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../configure --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050220 (experimental) Build with no problems. This little test program was created as a result of a runtime error on a large program used to test gfortran. G77 does not have this problem. program ntst character*16 bufld character*142 line open (10,file='bumsls',status='old') 32 read (10,'(a)',end=33) line if (line(1:1) .eq. '.') goto 32 write(*,*) 'write values on the line ',line write(*,*) read (line,79) bufld,budelt 79 format (t43,a16,t61,f8.0) write(*,*) 'write 2 values from the line ',bufld,budelt write(*,*) 33 continue end At line 14 of file ntst.f Fortran runtime error: Bad value during floating point read bumsls file contents 3 lines * . . -- --- - - - 1 a 154.3000 35.3000 rrrabcrb 1200. 13p3 3 -- Summary: Gfortran internal read error Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: blime at cox dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20236
[Bug c++/20206] [4.0/4.1 Regression] COMDAT broken for C++ thunks
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-27 17:23 --- Subject: Bug 20206 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-02-27 17:22:58 Modified files: gcc/cp : ChangeLog gcc/testsuite : ChangeLog gcc/cp : decl.c Added files: gcc/testsuite/g++.dg/opt: covariant1.C thunk2.C Log message: PR c++/20206 * decl.c (cxx_comdat_group): Put thunks for TARGET_USE_LOCAL_THUNK_ALIAS_P (function) functions into the same comdat group as the thunk target. * g++.dg/opt/thunk2.C: New test. * g++.dg/opt/covariant1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.4648r2=1.4648.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.4r2=1.5084.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.1371r2=1.1371.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/covariant1.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/thunk2.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20206
[Bug c++/20206] [4.0/4.1 Regression] COMDAT broken for C++ thunks
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-27 17:25 --- Fixed in CVS. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20206
[Bug fortran/20236] Gfortran internal read error
-- What|Removed |Added OtherBugsDependingO||20235 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20236
[Bug fortran/20235] Gfortran internal read error
--- Additional Comments From blime at cox dot net 2005-02-27 17:26 --- added input data to bug 20236 omitted in 20235 bug report -- What|Removed |Added BugsThisDependsOn||20236 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20235
[Bug rtl-optimization/17728] [3.4 Regression] ICE in extract_insn, at recog.c:2083, unrecognizable insn
--- Additional Comments From danglin at gcc dot gnu dot org 2005-02-27 17:29 --- Fixed http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01732.html. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17728
[Bug libfortran/18025] libgfortran: format, incompatible minimum width edit descriptor
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-27 17:32 --- Proposed patch: http://gcc.gnu.org/ml/fortran/2005-02/msg00374.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18025
[Bug c++/20175] [3.4 Regression] Warnings are issued when initializing struct members with strings
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-27 18:11 --- Subject: Bug 20175 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-27 18:10:42 Modified files: gcc/cp : ChangeLog gcc/testsuite : ChangeLog gcc/cp : decl.c Added files: gcc/testsuite/g++.dg/warn: Wbraces2.C Log message: PR c++/20175 * decl.c (reshape_init): Don't warn about missing braces if STRING_CST initializes a char/wchar_t array. * g++.dg/warn/Wbraces2.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.201r2=1.3892.2.202 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.364r2=1.3389.2.365 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1174.2.31r2=1.1174.2.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wbraces2.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20175
[Bug c++/20175] [3.4 Regression] Warnings are issued when initializing struct members with strings
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-27 18:12 --- Fixed in CVS. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20175
[Bug fortran/20154] fortran: scoping of implicit none interfaces
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 18:16 --- I committed a patch for this February 23rd, verified that it also fixes this PR. I had checked bugzilla for this bug, but only before you opened this PR ;-) -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20154
[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 18:18 --- We should probably call fflush() in the following places: - at the beginning of a Fortran I/O operation - at termination of the program anywhere else? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-27 18:18:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug fortran/20224] gfortran - flags error on strange, but correct f66 program
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 18:32 --- Downgrading this to enhancement. 27 years of this not being allowed are a long time. -- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug fortran/20236] Gfortran internal read error
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 18:34 --- *** Bug 20235 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20236
[Bug fortran/20235] Gfortran internal read error
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 18:34 --- I didn't see any difference between this ans PR20236 except the missing input data. *** This bug has been marked as a duplicate of 20236 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20235
[Bug fortran/20236] runtime error reading float
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 18:41 --- Fixed form testcase which doesn't need the data file: program ntst character*16 bufld character*142 line line = ' 1 a 154.3000 35.3000 rrrabcr' 1 //'b 1200. 13p3 3' write(*,*) 'write values on the line ',line write(*,*) read (line,79) bufld,budelt 79 format (t43,a16,t61,f8.0) write(*,*) 'write 2 values from the line ',bufld,budelt write(*,*) 33 continue end Works with g77, output: write values on the line 1 a 154.3000 35.3000 rrrabcrb 1200. 13p3 3 write 2 values from the line rrrabcrb 1200. Runtime error with gfortran. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-27 18:41:12 date|| Summary|Gfortran internal read error|runtime error reading float http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20236
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 18:43 --- Upgraded to normal severity, interoperability with g77 is important. -- What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug ada/20075] Bug in GNAT.Expect.Non_Blocking_Spawn
--- Additional Comments From sbellon at sbellon dot de 2005-02-27 18:47
---
I have investigated further. There are further places in the C part of the GNAT
library that need changing because they are inconsistent.
In __gnat_portable_spawn in ada/adaint.c the spawn/exec calls are always the
'path' variants except for Unix. The patch for GCC 3.4.3 should be as follows:
--- adaint.c2004-01-13 12:51:31.0 +0100
+++ patched/adaint.c2005-02-25 13:25:40.0 +0100
@@ -1520,9 +1520,9 @@
if (pid == 0)
{
/* The child. */
- if (execv (args[0], args) != 0)
+ if (execvp (args[0], args) != 0)
#if defined (VMS)
- return -1; /* execv is in parent context on VMS. */
+ return -1; /* execvp is in parent context on VMS. */
#else
_exit (1);
#endif
The only excuse could be that not all operating systems support execvp. In that
case, a simple define could fix that situation.
Furthermore, in ada/expect.c there are several versions of
__gnat_expect_portable_execvp that in fact don't call the 'path' variant of the
spawn/exec call although the function is called __gnat_expect_portable_execvp.
The following patch fixes that:
--- expect.c2003-10-31 02:08:42.0 +0100
+++ patched/expect.c2005-02-25 13:31:57.0 +0100
@@ -80,7 +80,7 @@
void
__gnat_expect_portable_execvp (int *pid, char *cmd, char *argv[])
{
- *pid = (int) spawnve (_P_NOWAIT, cmd, argv, NULL);
+ *pid = _spawnvp (_P_NOWAIT, cmd, argv);
}
int
@@ -168,8 +168,7 @@
__gnat_expect_portable_execvp (int *pid, char *cmd, char *argv[])
{
*pid = (int) getpid ();
- /* Since cmd is fully qualified, it is incorrect to call execvp */
- execv (cmd, argv);
+ execvp (cmd, argv);
_exit (1);
}
@@ -308,8 +307,7 @@
__gnat_expect_portable_execvp (int *pid, char *cmd, char *argv[])
{
*pid = (int) getpid ();
- /* Since cmd is fully qualified, it is incorrect to call execvp */
- execv (cmd, argv);
+ execvp (cmd, argv);
_exit (1);
}
The comment that it is incorrect to call execvp is in fact incorrect itself. The
specification of execvp allows to call it with a fully qualified pathname and in
fact does exactly what is needed here.
With all my suggested patches applied, the handling of spawning child processes
and the way the command itself is passed to the child process are made
consistent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20075
[Bug c++/20237] New: Problem with order of destruction in shared object.
Not sure if this can really be considered a bug, it certainly violates the C++ standard, but since I'm using extensions (e.g. dlopen, dlclose)... The problem is simple: in the main module, I have an std::map std::string, Base* at namespace scope, which is getting constructed before main is entered. Sometime later, I load a shared object, using dlopen; the shared object has an object at namespace scope which derives from Base. The constructor of Base enroles the object in the map, and the destructor removes it. A rather common idiom, I would have thought. Regretfully, the std::map is destructed before the derived object. If someone wants to look into this, I should be able to provide a small test program; I won't bother to try and isolate it further, however, if you take the position that I'm using a non-supported extension, and that it is my problem. (I've a simply work-around: I allocate the map dynamically with a sort of singleton idiom, and never delete it, so it is never destructed.) -- Summary: Problem with order of destruction in shared object. Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: james dot kanze at free dot fr 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: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20237
[Bug ada/20035] failed run-time assertion : Tasking not implemented on this configuration on sparc-linux
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-27 19:02:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20035
[Bug fortran/16531] [gfortran] Hollerith Data not supported
--- Additional Comments From jvdelisle at verizon dot net 2005-02-27 19:13 --- Is anyone working on this? It is blocking some significant codes I am testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16531
[Bug c++/11585] static template member definition fails
--- Additional Comments From jaco at kroon dot co dot za 2005-02-27 19:25 --- Ok. The only reason I found this was cause I tried to compile quasar on my system. The code I supplied was the most reduced form I could create that duplicated the problem. As such I will attempt to make the smallest number of changes to the system (there is about 4 of these so I'll just go with the explicit instantiation for each as this is the way it currently works). The cover all cases definition will need to be in the header file though right? Won't this produce duplicate symbols? Or will the linked automatically know to consolidate all these different symbols in the different object files into the same symbol in the produced executable? Yes, I was aware of the declaration vs definition problem (The book I learned C++ from explained this quite well), but I'm by no means a template guru, in fact, very far from (I use them in basic ways usually, even when using the STL). I was actually quite surprised that the compiler moaned in the first place, and was a bit skeptical about adding template cause that just felt/looked like a declaration and not a definition. Oh, and yes, the solution provided does work. Thank you very much for your help. One thing is sure though, I don't see the ambiguity between the statement with template ...::_types; and template ...::_types = ...; Both in my opinion is quite clearly a definition. We are defining that variable, for IntFactory, which as far as I can tell, is no longer really a template - why the template still? Someone explained to me that it is, actually, still a template, but doesn't take any more parameters (it's a specialisation of the template - this much makes sense). But as we are defining the _types static attribute, this is no longer a specialization - why is the template prefix still required? After all, it is simply a variable. I guess I just need to go and think about this for a bit to wrap my mind around it. Once again: Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11585
[Bug target/19819] ICE when compiling aegis 4.20
--- Additional Comments From danglin at gcc dot gnu dot org 2005-02-27
19:37 ---
This appears to be a reload problem. The reason the insn isn't
recognized is that the REG_POINTER flag (f/frame-related) has been
lost. Under HP-UX the base register must be marked with the
REG_POINTER flag because the base register is used to determine
which space register to use for the insn. This matters under
HP-UX because the space registers forthe four memory quadrants
contain different values.
After the lreg pass, we have:
(note 1056 1055 1057 114 NOTE_INSN_DELETED)
(insn 1057 1056 1855 114 (set (reg/v:DF 237 [ x ])
(mem/s/j:DF (plus:SI (reg:SI 241)
(reg/v/f:SI 213 [ rp ])) [0 variable.data S8 A64])) 67 {*pa.md
:3791} (insn_list 1055 (nil))
(nil))
The ICE occurs in the greg pass where we now have the following rtl:
(note 1056 2195 2197 114 NOTE_INSN_DELETED)
(insn 2197 1056 2198 114 (set (reg:SI 1 %r1)
(mem:SI (plus:SI (reg/f:SI 30 %r30)
(const_int -292 [0xfedc])) [0 rp+0 S4 A32])) 37
{*pa.md:2265}
(nil)
(nil))
(insn 2198 2197 2196 114 (set (reg:DF 68 %fr22)
(mem/s/j:DF (plus:SI (reg:SI 21 %r21)
(reg:SI 1 %r1)) [0 variable.data S8 A64])) -1 (nil)
(nil))
At the moment, it's not clear where the flag is lost.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19819
[Bug c++/20237] Problem with order of destruction in shared object.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 19:45 --- How did you configure gcc? Did you use --enable-__cxa_atexit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20237
[Bug libfortran/20101] zero prints incorrectly with 1pe12.4
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-27 19:47 --- Subject: Bug 20101 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-27 19:47:12 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : write.c Added files: gcc/testsuite/gfortran.dg: write_0_pe_format.f90 Log message: libgfortran/ 2005-02-27 François-Xavier Coudert [EMAIL PROTECTED] PR libfortran/20101 * write.c (output_float): Adding special check for value 0.0 in PE format. gcc/testsuite/ 2005-02-27 François-Xavier Coudert [EMAIL PROTECTED] PR libfortran/20101 * gfortran.dg/write_0_pe_format.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5092r2=1.5093 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/write_0_pe_format.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.165r2=1.166 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gccr1=1.24r2=1.25 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20101
[Bug fortran/20224] gfortran - flags error on strange, but correct f66 program
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-27 19:49 --- This is not an enhancement and should be given the WONTFIX status. Re-read the excerpt from the F77 standard that I quoted. If it is not an outright error, then consider the implications that this so-called enhancement will have on optimizing DO-loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug libfortran/20101] zero prints incorrectly with 1pe12.4
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-27 20:44 --- Subject: Bug 20101 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-02-27 20:44:52 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : write.c Log message: libgfortran/ 2005-02-27 Francois-Xavier Coudert [EMAIL PROTECTED] PR libfortran/20101 * io/write.c (output_float): Added special check for value 0.0 in PE format. gcc/testsuite/ PR libfortran/20101 * gfortran.dg/write_0_pe_format.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.6r2=1.5084.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.1r2=1.163.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.23.2.1r2=1.23.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20101
[Bug libfortran/20101] zero prints incorrectly with 1pe12.4
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 20:48 --- Fixed on both the mainline and the release branch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20101
[Bug libfortran/20101] zero prints incorrectly with 1pe12.4
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20101
[Bug fortran/20151] internal compiler error: Bus error
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 21:03 --- Reduced testcase: module token_module2 COMMON /MPIPRIV/ MPI_BOTTOM integer i end module token_module2 use token_module2, only: mpi_bottom use token_module2, only: i end Removing either of the use lines makes the failure disappear. Note that the failure happens also without using the ONLY clauses, but I'm not sure if the code would be illegal then (and wrongly accepted). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20151
[Bug c/20238] New: signed/unsigned multiplication + sign extension broken 32-64 bit sign promotion?
The stuff below applies to the CVS head revision as well as 3.4.*.
Maybe there is a bug w.r.t. sign promotion of the results of signed/unsigned
mixed multiplication from 32 to 64 bits. IMHO the result should be signed
(shouldn't it?).
I'm a little bit confused w.r.t. to signed/unsigned multiplication on x86_64:
Assume multiplying (signed some integer type)-1 by (unsigned same integer
type)20 and cast that value to a larger integer. With gcc-3.4.3 as well as the
CVS head revision I get the following:
1.
(signed long) = (signed int) = (signed short) = (signed char) x (unsigned char)
This yields proper (?) sign extension to every integer type. In hex notation:
if (signed long)a = (signed char)-1 * (unsigned char)20,
then a = 0x ffec
2.
(signed long) = (signed int) = (signed short) x (unsigned short)
Dito (with char replaced by short):
if a = -1 * 20, then a = 0x ffec
3.
(signed long) = (signed int) x (unsigned int)
Surprisingly the sign is not promoted in this case:
a = -1 * 20, then a = 0x ffec
IMHO, this is a bug. Below is a short test program which tries to execute the
three scenarios. But maybe there is some thinko on my side.
The output from the test program below (on my host) is:
Char : 0xffec | 0xffec | 0xffec
Short: 0xffec | 0xffec
Int : 0xffec
Best regards
Claus
snip
#include stdio.h
short char_mix(signed char sign, unsigned char val)
{
return sign * val;
}
int short_mix(signed short sign, unsigned short val)
{
return sign * val;
}
long int int_mix(int sign, unsigned int val)
{
return sign * val;
}
int main(int argc, const char *argv[])
{
shortshort_res;
int int_res;
long int long_int_res;
short_res = char_mix(-1, 20);
int_res = short_mix(-1, 20);
long_int_res = int_mix(-1, 20);
printf(Char : 0x%016lx | 0x%08x | 0x%04x\n,
(unsigned long)short_res, (unsigned int)short_res, (unsigned
short)short_res);
printf(Short: 0x%016lx | 0x%08x\n,
(unsigned long)int_res, (unsigned int)int_res);
printf(Int : 0x%016lx\n, (unsigned long)long_int_res);
}
snap
--
Summary: signed/unsigned multiplication + sign extension broken
32-64 bit sign promotion?
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ch at dot-heine dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20238
[Bug fortran/20154] fortran: scoping of implicit none interfaces
-- What|Removed |Added CC||tobi at gcc dot gnu dot org Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20154
[Bug c/20238] signed/unsigned multiplication + sign extension broken 32-64 bit sign promotion?
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20238
[Bug c/20238] signed/unsigned multiplication + sign extension broken 32-64 bit sign promotion?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 21:08 --- No I think this is invalid and here is why: casting even to unsigned still sign extened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20238
[Bug c/20238] signed/unsigned multiplication + sign extension broken 32-64 bit sign promotion?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 21:10 --- This is invalid. (unsigned int)(signed_char) is still signed extened. if you don't want a sign extension do: (unsigned int)(unsigned char)(signed_char). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20238
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From kmk at ssl dot org 2005-02-27 21:37 --- 1. A pointer is a derived type. 2. A derived type is not qualified by the qualifiers (if any) of the type from which it is derived. 3. 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. [emphasis mine; note that a pointer is, by itself, a derived type which does not inherit any qualifiers---so what] 4. A pointer to a pointer is itself a pointer. 5. The C standard, unlike C++, does not further restrict qualifier promotion of multi-level pointers---in fact, it is completely silent on the issue. 6. By (3), above, the left-hand side of a pointer assignment can be converted so that all qualifiers match. I ask again: where is the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From kmk at ssl dot org 2005-02-27 21:43 --- 6. I meant right-hand side not left-hand side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug libfortran/20005] reading a single return character fails
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-27 21:45 --- I believe this bug, PR 20092 and PR 20131 are duplicates. We will be sure when they get fixed, but I mention this here for the record. I may not have time to work on this before a few weeks, but this shouldn't be too hard to fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20005
[Bug c/20229] -Wcast-qual option is easily evaded
--- Additional Comments From kmk at ssl dot org 2005-02-27 21:55 --- It is precisely because it is useful to programmers in the manner described that a check is needed on it so that persons charged with the task of code validation or modification do not have to read 250,000 lines of code to find clever little hacks that have been inserted to fix otherwise inconvenient problems. If you want to pick nits about casting to a pointer removing the target type completely: fine. That is a perfectly reasonable technicality. However, in that event, I would suggest that a separate option be added that exhibits the behavior I describe by flagging ALL cases where a qualifier is discarded. Such an option would be significantly more useful to code maintainers (as opposed to the original authors of the code) in uncovering places where things go boom when code is extended or modified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20229
[Bug c/20229] -Wcast-qual option is easily evaded
--- Additional Comments From kmk at ssl dot org 2005-02-27 22:03 --- And furthermore, if it is so useful to be able to hide this behavior, why have this option at all? Why force programmers to undertake the two-step bomb-arming instead of just letting them do it in one step by casting away the const directly? What is the purpose of this option if you can evade it with a little extra effort? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20229
[Bug c/20238] signed/unsigned multiplication + sign extension broken 32-64 bit sign promotion?
--- Additional Comments From ch at dot-heine dot de 2005-02-27 22:05 --- Subject: Re: signed/unsigned multiplication + sign extension broken 32-64 bit sign promotion? pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 21:10 --- This is invalid. (unsigned int)(signed_char) is still signed extened. if you don't want a sign extension do: (unsigned int)(unsigned char)(signed_char). I'll getter get myself a copy of the ANSI standard. However, this is still funny. This means that I have sign extension when I skip an integer size in between, so (unsigned long)(signed short) will be promoted sign extended to 64 bits but (unsigned long)(signed int) will not. Ok. But then there is a bug in h8300.c in h8300_emit_stack_adjustment() where such a construct is passed to GEN_INT() which will not do the sign extension; later on that integer is compared with the result of trunc_int_for_mode() which _does_ sign extension. I'll submit a corresponding bug report later. Thx for the quick reply Claus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20238
[Bug c/20239] New: ICE on empty preprocessed input
When feeding a preprocessed input file consisting of only a newline to gcc, it gets a segmentation fault: snaga:tmp rm -f test.i snaga:tmp echo test.i snaga:tmp gcc test.i test.i:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE on empty preprocessed input Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lalle at sics dot se 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: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20239
[Bug c/20239] [3.4 Regression] ICE on empty preprocessed input
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-27 22:29 --- Confirmed, only happens in 3.4.x. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||3.4.0 Known to work||3.3.3 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-02-27 22:29:13 date|| Summary|ICE on empty preprocessed |[3.4 Regression] ICE on |input |empty preprocessed input Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20239
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From joseph at codesourcery dot com 2005-02-27 22:30 --- Subject: Re: GCC generates non-compliant warnings for qualifier promotion On Sun, 27 Feb 2005, kmk at ssl dot org wrote: 1. A pointer is a derived type. 2. A derived type is not qualified by the qualifiers (if any) of the type from which it is derived. 3. 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. [emphasis mine; note that a pointer is, by itself, a derived type which does not inherit any qualifiers---so what] Indeed, a pointer to non-qualified char * may be converted to a pointer to qualified char *. For example, char ** or char **const may be converted to char *const * or char *volatile *const restrict. But const char * isn't a qualified version of char *; char * and const char * are entirely distinct unqualified types. So char ** may not be converted to const char *const *, because they are pointers to distinct unqualified types, not pointers to qualified and unqualified versions of the same type. Your misconception appears to be that const char * is a qualified version of char *. It isn't. They are incompatible unqualified types. Similarly, const char *const * is not a qualified version of char **. 4. A pointer to a pointer is itself a pointer. 5. The C standard, unlike C++, does not further restrict qualifier promotion of multi-level pointers---in fact, it is completely silent on the issue. It doesn't need to discuss the issue, as it follows from the definitions in the standard. There is *no* concept of multi-level pointers in the standard; just that of pointers, derived from a type which may or may not be a pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion
--- Additional Comments From kmk at ssl dot org 2005-02-27 23:12 --- But const char * isn't a qualified version of char * Ahhh. Now I see your point. Amazingly enough, the C standard does not, under any circumstances, permit objects (including the targets of pointers) to be qualifier promoted---only pointers themselves are so provided for. While that may be _phenomenally_ stupid, I acknoledge that it is, in fact, a direct interpretation of the standard. Accordingly, I withdraw my objection. Since the behavior is literally non-compliant with the standard, it is perfectly reasonable for the compiler to warn about it. Thank you for the enlightenment. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230
[Bug c++/20240] New: invalid using-redeclaration accepted
sorry if this is a dupe, I've checked the summaries, but there are too many
about using to read each in detail.
I think this is a bug:
namespace A{int a;};
namespace C{
int a;
using A::a;
}
accepted.
if not, then this is one:
namespace A{int a;};
namespace C{
double a;
using A::a;
}
error: `a' is already declared in this scope
--
Summary: invalid using-redeclaration accepted
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20240
[Bug c++/20240] [3.3/3.4/4.0/4.1 Regression] invalid using-redeclaration accepted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 00:27 --- Confirmed, a regression from 3.2.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Known to fail||4.0.0 3.3.2 3.4.0 Known to work||3.2.3 Last reconfirmed|-00-00 00:00:00 |2005-02-28 00:27:24 date|| Summary|invalid using-redeclaration |[3.3/3.4/4.0/4.1 Regression] |accepted|invalid using-redeclaration ||accepted Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20240
[Bug fortran/20058] Error on kind 16 hex data statement
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-28 00:38 --- Subject: Bug 20058 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-28 00:38:13 Modified files: gcc/fortran: ChangeLog trans-types.c gfortran.h primary.c Log message: PR fortran/20058 * trans-types.c (gfc_max_integer_kind): Declare (gfc_init_kinds): Initialize it. * gfortran.h (gfc_max_integer_kind): extern it. * primary.c (match_boz_constant): Use it; remove gfortran extension of kind suffixes on BOZ literal constants Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.336r2=1.337 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gccr1=1.37r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gccr1=1.58r2=1.59 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/primary.c.diff?cvsroot=gccr1=1.22r2=1.23 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20058
[Bug fortran/20058] Error on kind 16 hex data statement
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-28 00:42 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20058
[Bug c++/20220] [4.0/4.1 Regression] Rejecting invalid template code, breaks most of Boost
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 01:09 --- (In reply to comment #3) This worked with 4.0.0 20050113 but fails with 20050210. To get a smaller window, it fails with 20050201. Hmm, it passes with 20050225. I think this was fixed by: PR c++/19991 * init.c (integral_constant_value): Iterate if the value of a decl is itself a constant. Since this is fixed both the orginal full test case and the reduced version, I am going to close it as fixed. Giovanni if you want to apply the testcase I think that would be useful for the future. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20220
[Bug c++/20241] New: [4.0/4.1 Regression] ICEing with VLA in template that is type dependent
The following invalid (well valid if we say that VLA is a GCC extension) ICE
in fold_convert:
templatetypename T void foo(T t)
{
int f[t];
}
Also we don't reject this with -pedantic in 2.95.3-3.4.0 either so that is not
a regression.
There might be missing a processing_template somewhere.
--
Summary: [4.0/4.1 Regression] ICEing with VLA in template that is
type dependent
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: minor
Priority: P2
Component: c++
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=20241
[Bug c++/20241] [4.0/4.1 Regression] ICEing with VLA in template that is type dependent
-- What|Removed |Added Severity|minor |normal Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20241
[Bug c++/20208] [4.0/4.1 Regression] No array-to-pointer decay happens for template functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 01:42 --- This has failed since at least 20040909. The ICE is: t1.cc:8: internal compiler error: in fold_convert, at fold-const.c:1952 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20208
[Bug c++/20212] [4.0/4.1 Regression] attribute unused vs. member function template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 01:45 --- This worked with 3.5.0 20040909. -- What|Removed |Added Last reconfirmed|2005-02-25 19:00:48 |2005-02-28 01:45:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20212
[Bug c++/20241] [4.0/4.1 Regression] ICEing with VLA in template that is type dependent
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 01:49 --- And it fails with 20050113. Those are the two closest compilers I have. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20241
[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.
-- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18560
[Bug target/19065] Make CRIS libstdc++ asms autoincrement-safe
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-28 02:21 --- Subject: Bug 19065 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-28 02:21:40 Modified files: gcc: ChangeLog gcc/config/cris: cris.h cris.md Log message: PR target/19065. * config/cris/cris.h (EXTRA_CONSTRAINT_Q): Accept only (mem (reg)), not including (reg). Do not check for reg being CRIS_PC_REGNUM. (EXTRA_MEMORY_CONSTRAINT): Define as 'Q'. * config/cris/cris.md: Tweak comments referring to Q. (cmpsi, cmphi, cmpqi, *movsi_internal, movhi) (movstricthi, movqi, movstrictqi, movsf, addsi3) (addhi3, addqi3, subsi3, subhi3, subqi3) (*expanded_andsi, *expanded_andhi, *andhi_lowpart, andqi3) (*andqi_lowpart, iorsi3, iorhi3, iorqi3, uminsi3): Insert spaces in constraints to align alternatives vertically for readability. (cmphi): Ditto. Add separate alternative for operand 0 Q, operand 1: M. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7606r2=2.7607 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/cris/cris.h.diff?cvsroot=gccr1=1.84r2=1.85 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/cris/cris.md.diff?cvsroot=gccr1=1.22r2=1.23 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19065
[Bug target/19065] Make CRIS libstdc++ asms autoincrement-safe
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-28 02:33 --- Subject: Bug 19065 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-28 02:33:40 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/config/cpu/cris: atomicity.h Log message: PR target/19065 * config/cpu/cris/atomicity.h (__exchange_and_add): In asm, use 'Q' constraint, not 'm'. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.2919r2=1.2920 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config/cpu/cris/atomicity.h.diff?cvsroot=gccr1=1.6r2=1.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19065
[Bug rtl-optimization/20242] New: Pessimizing effects of defining EXTRA_MEMORY_CONSTRAINT
In some large functions, where all hardware registers are used up and some pseudo-register need to be allocated on stack, EXTRA_MEMORY_CONSTRAINT will have a pessimizing effect. Without further analysis, it seems that it causes pseudo-registers to be committed (too devoted) to memory with no apparent re-use of registers, if any free one is found later on (perhaps as part of reload inheritance). I compared LAST_UPDATED: Sun Feb 27 17:43:10 UTC 2005 without (0) and with (1) the patch at URL: and also with the patch applied except the EXTRA_MEMORY_CONSTRAINT definition (2) (the removal of that line and the atomicity.h patch to avoid build failure). For ghostscript-5.50 (patched to submission for current trunk) and the minimal input in the attachment named test.ps, emitting png, the longest_match function (from zlib 1.1.3) in the attached test-case (attachment bigfun.i) was part of an execution path with similar other pessimizations observed. Numbers are simulated schedulable cycles. 0, baseline: 495989262. 1, E_M_C: 498036429 (time-ratio vs baseline: 100.41%). 2, Q-fixes but no E_M_C was identical to baseline. Note differences in between baseline and fixed-Q-and-E_M_C in the generated assembly code (baseline and diff to be attached). Compiled with -O2 -march=v10 -mno-mul-bug-workaround. -- Summary: Pessimizing effects of defining EXTRA_MEMORY_CONSTRAINT Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20242
[Bug target/19065] Make CRIS libstdc++ asms autoincrement-safe
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-28 02:50 --- Fixed, see URL:http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01769.html and URL:http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01770.html. But see also PR 20242. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19065
