[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-04
08:13 ---
(Of course, the root cause of this problem is that fold is being called before
gimplification, which Nathan and I have sermonized about previously.)
There's interesting interplay between this PR and PR 20280. In particular,
RTH's proposed transformation in Comment #8 is invalid if A and B are
bit-fields, because the address of a bitfield cannot be taken.
Consider:
struct S { int i : 7; };
S s;
extern int b;
const int a = (x ? s.i : b);
This cannot be transformed into:
int *a = *((x ? t = s.i : t = *b), t);
as per Comment #8.
Indeed fold transforms ((s.i i)? s.i : i) into MAX_EXPR (s.i, i) in this
program:
struct S { int i : 7; };
S s;
extern int i;
bool b;
void g() {
((s.i i) ? s.i : i) = 3;
}
That happens to work only because of the hack where we allow MAX_EXPR as an
lvalue in an assignment in build_modify_expr if neither argument has
side-effects. (We recreate the COND_EXPR there.) This change went in as the
fix for PR 7503.
Roger, I think you need the same hack where you bind COND_EXPRs to references,
take their addresses, etc. In fact, you should probably just make real_lvalue_p
accept MAX_EXPRs with side-effect free operands. And, then, wherever we need
lvalues do the conversion that you presently do in build_modify_expr. That's
consistent with your MAX_EXPRs are just the canonical form of certain
COND_EXPRs logic.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
[Bug java/20312] New: No warning on bad method
Hi, in the Hecl programming language, I do this:
public String toString() throws HeclException {
Vector v = ListThing.get(new Thing(new HashThing(val)));
ListThing newthing = new ListThing(v);
return newthing.toString();
}
Apparently, that should generate a warning or throw an error, because toString
isn't supposed to throw an exception... regular java says this:
./com/dedasys/hecl/HashThing.java:140: toString() in com.dedasys.hecl.HashThing
cannot override toString() in java.lang.Object; overridden method does not throw
com.dedasys.hecl.HeclException
public String toString() throws HeclException {
^
Thanks,
Dave
--
Summary: No warning on bad method
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davidw at dedasys dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20312
[Bug c++/20311] poor diagnostic
--- Additional Comments From igodard at pacbell dot net 2005-03-04 08:51 --- Sorry guys :-) After a while I forget, and then I run across it again :-( Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20311
[Bug bootstrap/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-04 09:07 --- Created an attachment (id=8326) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8326action=view) Patch I'm testing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug c++/20313] New: poor diagnostic
In:
templateint struct s1{ s1(int); };
templateint i s1i::s1(int j){}
templateint struct s;
template struct s0 { s(int); };
template struct s1 { s(int); };
templateint i si::s(int j) {}
int main() {
s0 a(5);
s10 b(5);
}
you get:
~/ootbc/members/src$ g++ foo.cc
foo.cc:10: error: invalid use of undefined type `struct sanonymous '
foo.cc:5: error: declaration of `struct sanonymous '
foo.cc:10: error: template definition of non-template `sanonymous ::s(int)'
This had me mystified enough that I had to reduce my code to this example and
try it on Comeau, which gives:
Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C++
ComeauTest.c, line 10: error: incomplete type is not allowed
templateint i si::s(int j) {}
^
ComeauTest.c, line 10: error: template argument list must match the parameter
list
templateint i si::s(int j) {}
^
2 errors detected in the compilation of ComeauTest.c.
With that I saw what my problem was. The gcc diagnostic might be obvious to
everyone but me, but I doubt it.
Ivan
--
Summary: poor diagnostic
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20313
[Bug middle-end/17526] [4.0 Regression] libcpp is miscompiled with -fno-pcc-struct-return -O2
--- Additional Comments From wanderer at rsu dot ru 2005-03-04 10:43 --- Current CVS mainline bootstrap fine at self with and without reverting patch in #30. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17526
[Bug libfortran/16339] Unformatted i/o on large arrays inefficient
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-04 10:47 --- This is really _very_ inefficient, by a factor of 20. Some test numbers: $ g77 write-record.f $ time ./a.out real0m1.819s user0m1.774s sys 0m0.044s $ gfortran write-record.f $ time ./a.out real0m43.723s user0m9.003s sys 0m34.571s $ cat write-record.f program main integer n parameter (n=1000) real a(n) write (10) (a(i),i=1,n) end $ gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../gcc-4.1-20050227/configure --prefix=/home/zfkts --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050227 (experimental) By comparison: $ ifort write-record.f $ time ./a.out real0m0.117s user0m0.001s sys 0m0.116s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16339
[Bug middle-end/17526] [4.0 Regression] libcpp is miscompiled with -fno-pcc-struct-return -O2
--- Additional Comments From wanderer at rsu dot ru 2005-03-04 11:27 --- Ops... sorry. I withdraw my prev. note. Current mainline CVS GCC fail bootstrap with reverted patch in #30 -- What|Removed |Added CC||olh at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17526
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-04 11:27 --- - a simpler compiler - simpler interfacing with C code - less excess precision problems with floating point returns (REAL*4 returns are not returned as REAL*8) - faster executables - we'll never get this if we don't do it now But if you really like the default the other way round, I'd suggest: - you implement the necessary changes to the library :-) - we discuss this on the mailing list once I submit the patch, so that other people can weigh in as well. I hope to get there today, I have finished the COMPLEX part, and I don't think the REAL part will be difficult. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug inline-asm/20314] New: Bogus differ in number of alternatives error
With:
int
f1 (void)
{
int x = 4, y;
__asm__ volatile (imull %3\n\tshrdl %%cl,%1,%0
: +a,a (x), =d,d (y)
: %0,0 (x), m,r (8), c,c (2));
return x;
}
int
f2 (void)
{
int x = 4, y;
__asm__ volatile (imull %3\n\tshrdl %%cl,%1,%0
: =a,a (x), =d,d (y)
: %0,0 (x), m,r (8), c,c (2));
return x;
}
int
f3 (void)
{
int x = 4, y;
__asm__ volatile (imull %2\n\tshrdl %%cl,%1,%0
: +a,a (x), =d,d (y)
: m,r (8), c,c (2));
return x;
}
int
f4 (void)
{
int x = 4, y;
__asm__ volatile (imull %3\n\tshrdl %%cl,%1,%0
: +a (x), =d (y)
: %0 (x), r (8), c (2));
return x;
}
int
f5 (void)
{
int x = 4, y;
__asm__ volatile (imull %3\n\tshrdl %%cl,%1,%0
: =a (x), =d (y)
: %0 (x), r (8), c (2));
return x;
}
int
f6 (void)
{
int x = 4, y;
__asm__ volatile (imull %2\n\tshrdl %%cl,%1,%0
: +a (x), =d (y)
: r (8), c (2));
return x;
}
GCC 3.2.3 and 3.4.3 error on f4:
iasm.c:35: error: inconsistent operand constraints in an `asm'
while GCC 4 errors on f1 and f3:
iasm.c: In function `f1':
iasm.c:5: error: operand constraints for `asm' differ in number of alternatives
iasm.c: In function `f3':
iasm.c:25: error: operand constraints for `asm' differ in number of alternatives
This certainly seems to be inconsistent. Either using %0 matching +a
is valid or not but I don't see anything wrong on f3.
If : +a (x) : %0 (x) is invalid, then both f1 and f4 should fail and
all others pass, if it is valid, I think all functions ought to pass.
--
Summary: Bogus differ in number of alternatives error
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20314
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-04 11:40 --- BTW, most (if not all) of the affected functions in BLAS / LAPACK are auxiliary functions, i.e. are only called from within those libraries. Changing the interface will only affect functions called from the outside, so compatibility issues might not be so bad. But as I said, a discussion of this should take place on the mailing list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug target/20294] ia64 gcj failures
-- What|Removed |Added AssignedTo|aph at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294
[Bug c++/20315] New: G++ Problem with two-stage name lookup
I had a derived class template which was making use of two protected
variables of its base class. Now using GCC 3.4.4 (which implements the two-
stage dependant name lookup) Ive read that you need to use the prefix this-
or the prefix BaseClassNameT to avoid getting a undeclared variable message,
but it doesn´t work, at least with this version of the compiler. When you
compile with the m64 option, the first time the compiler not generate the .o
file just generate a .gch file and if you repeat the operation !!?, the
internal compiler error message appear.
If you compile at 32 bits generate the .gch file in ever occasion you compile
it but the error message not appear.?
I have tried the flag fpermissive without luck.
We are compiling with 64 bits. Do you now any work around?
Code:
template typename T class Base {
int i;
};
template typename T class Derived : public BaseT {
int get_i() {return BaseT::i;}
};
Preprocessed Code:
# 1 test.h
# 1 built-in
# 1 command line
# 1 test.h
template typename T class Base {
int i;
};
template typename T class Derived : public BaseT {
int get_i() {return BaseT::i;}
};
Problem :
sun1:~/test g++ -m64 -Wno-deprecated -x c++ -c test.h
cc1plus: internal compiler error: in default_pch_valid_p, at ./toplev.c:4142
Please submit a full bug report,
with preprocessed source if appropriate.
Bug Information:
sun1:~/test g++ -v -save-temps -m64 -Wno-deprecated -x c++ -c test.h
Reading specs from /usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/specs
Configured with: ./configure --prefix=/usr/users/afernand/comp/gcc-bootstrap-
34 --enable-language=c --without-headers --disable-shared :
(reconfigured) ./configure --prefix=/usr/users/afernand/comp/gcc-bootstrap-34 -
-enable-language=c --without-headers --disable-shared :
(reconfigured) ./configure --prefix=/usr/users/afernand/comp/gcc-bootstrap-34 -
-enable-language=c --without-headers --disable-shared :
(reconfigured) ./configure --prefix=/usr/users/afernand/comp/gcc-34 --enable-
language=c,c++
Thread model: posix
gcc version 3.4.4 20041222 (prerelease)
/usr/local/gcc-34/bin/../libexec/gcc/sparc-sun-solaris2.9/3.4.4/cc1plus -E -
quiet -v -iprefix /usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/ -D__arch64__ -D__sparcv9 test.h -mptr64 -mstack-bias -mno-
v8plus -mcpu=v9 -m64 -Wno-deprecated -o test.ii
ignoring nonexistent directory /usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../sparc-sun-solaris2.9/include
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory /usr/users/afernand/comp/gcc-34/lib/gcc/sparc-
sun-solaris2.9/3.4.4/../../../../sparc-sun-solaris2.9/include
#include ... search starts here:
#include ... search starts here:
/usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4
/usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4/sparc-sun-solaris2.9
/usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4/backward
/usr/local/gcc-34/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.4/include
/usr/users/afernand/comp/gcc-34/lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4
/usr/users/afernand/comp/gcc-34/lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4/sparc-sun-solaris2.9
/usr/users/afernand/comp/gcc-34/lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4/backward
/usr/users/afernand/comp/gcc-34/include
/usr/users/afernand/comp/gcc-34/lib/gcc/sparc-sun-solaris2.9/3.4.4/include
/usr/include
End of search list.
/usr/local/gcc-34/bin/../libexec/gcc/sparc-sun-solaris2.9/3.4.4/cc1plus -
fpreprocessed test.ii -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet -
dumpbase test.h -m64 -auxbase test -Wno-deprecated -version -o test.s --output-
pch=test.h.gch
GNU C++ version 3.4.4 20041222 (prerelease) (sparc-sun-solaris2.9)
compiled by GNU C version 3.4.4 20041222 (prerelease).
GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=65536
Waiting to hear from you soon.
Best Regards.
--
Summary: G++ Problem with two-stage name lookup
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cmarco at indra dot es
CC: cmarco at indra dot es,gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20315
[Bug c++/20316] New: attribute((packed)) and call by reference
I have this test program:
struct P { char a; int b; } __attribute__ ((__packed__));
int f (char i) { return ++ i; }
int f (int i) { return ++ i; }
int f (char * i) { return ++ * i; }
int f (int * i) { return ++ * i; }
int main ()
{
P x;
x.a = 1;
x.b = 1;
int i = f (x.a) + f (x.b) + f ( x.a) + f ( x.b);
return 0;
}
It compiles with gcc3.3 (gcc version 3.3.6 20050223 (prerelease) [FreeBSD])
but not with gcc.3.4 (gcc version 3.4.4 20050211 (prerelease) [FreeBSD]).
GCC reports:
test.cpp: In function `int main()':
test.cpp:13: error: cannot bind packed field `x.P::a' to `char'
test.cpp:13: error: cannot bind packed field `x.P::b' to `int'
Probably, this is not a bug but a feature, but what can I do
to my program, which needs a lot of packed structures and runs fine
with gcc3.3?
Perhaps I have to cast away the packed attribute somehow ??
I understand, that my code may not work on cpus needing some specific
alignment, but where is the problem with char? And if this is a cpu issue,
why do the pointers work, but _not_ the references?
--
Summary: attribute((packed)) and call by reference
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nkoch at demig dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-portbld-freebsd4.10
GCC host triplet: i386-portbld-freebsd4.10
GCC target triplet: i386-portbld-freebsd4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20316
[Bug c++/20316] attribute((packed)) and call by reference
--- Additional Comments From falk at debian dot org 2005-03-04 12:51 --- (In reply to comment #0) Probably, this is not a bug but a feature Indeed, it is. but what can I do to my program, which needs a lot of packed structures and runs fine with gcc3.3? Nothing. It only worked by accident in 3.3, and will crash on many architectures. I understand, that my code may not work on cpus needing some specific alignment, but where is the problem with char? It would be completely useless to make an exception for char here. And if this is a cpu issue, why do the pointers work, but _not_ the references? Having pointers point to things that are not correctly aligned for their type does *not* work. It might be easier to fool the compiler to not reject it, though, and it might accidentally do what you meant it to do on some architectures. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20316
[Bug bootstrap/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From olh at suse dot de 2005-03-04 13:30 --- thanks Jakub, this patch fixes bootstrap for me. tested on mainline and gcc-4_0-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug c/20317] New: Solaris 10 and HUGE_VAL
Compiling the program
#define _XOPEN_SOURCE 600
#include math.h
int main()
{
double x = HUGE_VAL;
}
using
/opt/sfw/bin/gcc --std=gnu99 a.c
gives
a.c: In function `main':
a.c:6: error: incompatible types in initialization
I'll attach the preprocessor output if I can; in short,
HUGE_VAL expands to __builtin_huge_val, which is a
function in gcc but a constant in SunPRO.
fixinclude needs to adjust this difference, fixing
iso/math_c99.h appropriately.
--
Summary: Solaris 10 and HUGE_VAL
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at v dot loewis dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.10
GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From schlie at comcast dot net 2005-03-04 14:13 --- (In reply to comment #10) Upon further thought, and agreeing that the explicit use of an asm macro is likely the most appropriate near term solution; it would appear the most ideal longer term solution would be to figure out how to comprehensively enable both explictly and implicitly declared objects optionally tagged with target specific attributes to influence the selection of the access method (generated code) used to access them. Thereby allocated objects may be identified as potentially being allocated to either ROM(progmem), EEPROM, RAM(by defalut), or even requiring a particular access sequence (which in theory may even include the automatic wraping of interrupt disable/enable around the access automatically). (but it appears that a few things wihtin GCC may need to be refined to broadly enable the use of attributes to accomplish this, which I'm attempting to document). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug c/20317] Solaris 10 and HUGE_VAL
--- Additional Comments From martin at v dot loewis dot de 2005-03-04 14:16 --- Created an attachment (id=8327) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8327action=view) preprocessor output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From ericw at evcohs dot com 2005-03-04 14:19 --- (In reply to comment #11) Paul, Everybody who works on the AVR toolchain knows that it would be desirable to have attributes to allow objects to be put in and accessed in different address spaces. This has nothing to do with this bug report. Who are you trying to convince? Please refrain from muddying the waters with comments that have nothing to do with the issue at hand. You're just wasting bandwith. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug c/20317] Solaris 10 and HUGE_VAL
-- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317
[Bug preprocessor/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 14:26 --- Confirmed. Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00326.html. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|bootstrap |preprocessor Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-03-04 14:26:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug bootstrap/20305] [4.0/4.1 Regression] Miscompilation of libcpp/macro.c at -O1 and higher
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 14:27 --- So closing as a dup of bug 20282 since it was confirmed that this was the same bug. *** This bug has been marked as a duplicate of 20282 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug preprocessor/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 14:27 --- *** Bug 20305 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug c++/20313] poor diagnostic
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
14:51 ---
The only poor diagnostic is that in the following code:
templateint struct s;
templateint i si::s(int j) {}
We don't print out si but print out sanonymous which really is the same
problem as the
following too:
templateint j struct s;
templateint i si::s(int j) {}
So this is a dup of bug 99.
*** This bug has been marked as a duplicate of 99 ***
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20313
[Bug c++/99] Bug in template type in error message.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 14:51 --- *** Bug 20313 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
[Bug middle-end/20290] [4.0/4.1 Regression] Miscompilation on ppc/arm with -Os
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 14:57 --- I hear from Richard Earnshaw that this also fails on ARM too which means that it is a generic bug. -- What|Removed |Added Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression] |Miscompilation on ppc with -|Miscompilation on ppc/arm |Os |with -Os http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20290
[Bug java/20312] No warning on bad method
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
15:04 ---
Confirmed, reduced self contained testcase:
class t
{
public String toString() throws java.io.IOException
{return ;}
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||accepts-invalid
Known to fail||4.1.0
Last reconfirmed|-00-00 00:00:00 |2005-03-04 15:04:44
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20312
[Bug c++/99] Bug in template type in error message.
--- Additional Comments From bangerth at dealii dot org 2005-03-04 15:05
---
Here's another very nice example from PR 20313:
-
templateint j struct s;
templateint i si::s(int j) {}
-
Note that the definition of the constructor is invalid because the struct
isn't complete. Here's what we get:
g/x /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c x.cc
x.cc:2: error: invalid use of undefined type ?struct sj?
x.cc:1: error: declaration of ?struct sj?
x.cc:2: error: template definition of non-template ?sj::s(int)?
Note how the compiler uses the template argument 'j', although we use
template argument 'i' in line 2!
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
[Bug tree-optimization/18546] tree vectorizer does not understand RETURN_DECL
--- Additional Comments From cjb at mrao dot cam dot ac dot uk 2005-03-04 15:11 --- I'm not sure that I'm reproducing this; I'm getting the loop reported as vectorized: % ./g++ -O2 -msse2 -march=pentium4 -ftree-vectorize -fdump-tree-vect-stats -ftree-vectorizer-verbose=9 -S 18546.cpp 18546.cpp:9: note: LOOP VECTORIZED. 18546.cpp:6: note: vectorized 1 loops in function. Am enclosing the vectorizer's dump, my source file, and the generated asm. I'm using GCC: (GNU) 4.0.0-autovect 20050302 (experimental, autovect-merge-20050127) on x86. Andrew, could you let me know whether I'm misreading the output or whether there's something I'm doing to avoid triggering the bug? (Or whether it looks like it's been fixed since this was filed.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18546
[Bug target/20315] pch problems on solaris
--- Additional Comments From bangerth at dealii dot org 2005-03-04 15:15 --- This seems to be more a problem of precompiled headers on solaris than anything else... W. -- What|Removed |Added Component|c++ |target GCC host triplet||sparc-sun-solaris2.9 GCC target triplet||sparc-sun-solaris2.9 Summary|G++ Problem with two-stage |pch problems on solaris |name lookup | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20315
[Bug tree-optimization/18546] tree vectorizer does not understand RETURN_DECL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 15:18 --- (In reply to comment #5) I'm not sure that I'm reproducing this; I'm getting the loop reported as vectorized: No you are no missing reading. This is vectorized on x86 but not on PPC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18546
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From schlie at comcast dot net 2005-03-04 15:26 --- (In reply to comment #12) Everybody who works on the AVR toolchain knows that it would be desirable to have attributes to allow objects to be put in and accessed in different address spaces. This has nothing to do with this bug report. Who are you trying to convince? Please refrain from muddying the waters with comments that have nothing to do with the issue at hand. You're just wasting bandwith. (Although I know I should simply ignore ignorant comments, I feel compelled to respond. I pre-apologize, and will not continue the response further than): Eric, I'm glad it's obvious to you; maybe you'd consider attempting to technically contribute to the refinement of AVR's GCC port; as opposed to feeling overly empowered playing secretary for the WINAVR product in which you've obviously never technically contributed to the refinement of the GCC port which it's based upon, but instead apparently feel compelled to exert influence over what appears to obviously be beyond your intimate familiarity, and likely skill set to productively technically contribute towards yourself. (Admittedly I am no GCC expert by any stretch of imagination, but observe that in my relatively short tenure attempting to familiarize myself with both GCC's architecture and the AVR port sufficiently to productively contribute to their refinement, I've likely already contributed more (which isn't saying much) than you would appear to ever likely accomplish; so please try to tone down your misplaced opinions on subjects and people you're clearly predominantly ignorant of.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug preprocessor/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-04 15:28
---
The thing that was stopping me from commiting was that I'm now seeing
FAIL: gcc.dg/cpp/arith-3.c (test for bogus messages, line 257)
regression on i386 and x86-64 when starting bootstrap from 20050228
gcc-4_0-branch. But I have just verified that this is unrelated to my
macro.c fix (which doesn't change the code in any way on i386 even),
but it looks like libgcc.a(expr.o) is miscompiled at -O{2,3,s}.
So will need to do debugging once again for this, but will commit fix for
this PR first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug debug/20253] [3.4/4.0 regression]: Macro debug info broken due to lexer change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04 15:28 --- Subject: Bug 20253 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-04 15:28:46 Modified files: gcc: ChangeLog c-opts.c dwarf2out.c Added files: gcc/testsuite/gcc.dg/debug/dwarf2: dwarf2-macro.c Log message: 2005-03-04 Daniel Berlin [EMAIL PROTECTED] Fix PR debug/20253 * c-opts.c (c_common_parse_file): Call start_source_file and end_source_file at the approriate times. * dwarf2out.c (dwarf2out_finish): Don't auto-end the main file, it will be done for us now. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.20r2=2.7592.2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-opts.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.136r2=1.136.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.570r2=1.570.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf2-macro.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20253
[Bug c/20318] New: RFE: add attribute to specify that a function never returns NULL
It would be useful to have a function attribute which specifies that the function never returns NULL. Currently the GCC 4 snapshots with -O2 -Wall generate ~15 spurious warnings in the Subversion source code which could be eliminated if a couple of functions could be marked as never returning NULL. -- Summary: RFE: add attribute to specify that a function never returns NULL Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: jorton at redhat dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
[Bug java/18362] [4.0 Regression] internal compiler error: in size_binop, at fold-const.c:1598
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04 15:32 --- Subject: Bug 18362 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-04 15:32:44 Modified files: gcc/java : ChangeLog class.c Log message: 2005-03-04 Andrew Haley [EMAIL PROTECTED] PR java/18362 * class.c (set_method_index): Don't set method_index if it is NULL_TREE. (layout_class_method): Don't complain about non-static method foo overrides static method in the case of indirect dispatch. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.1556r2=1.1556.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.220r2=1.220.8.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18362
[Bug bootstrap/20305] [4.0/4.1 Regression] Miscompilation of libcpp/macro.c at -O1 and higher
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04 15:33 --- Subject: Bug 20305 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-04 15:33:24 Modified files: libcpp : ChangeLog macro.c Log message: PR bootstrap/20282 PR bootstrap/20305 * macro.c (replace_args, cpp_get_token): Copy whole cpp_token_u instead of just cpp_string field from it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gccr1=1.57r2=1.58 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/macro.c.diff?cvsroot=gccr1=1.9r2=1.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug preprocessor/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04 15:33 --- Subject: Bug 20282 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-04 15:33:24 Modified files: libcpp : ChangeLog macro.c Log message: PR bootstrap/20282 PR bootstrap/20305 * macro.c (replace_args, cpp_get_token): Copy whole cpp_token_u instead of just cpp_string field from it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gccr1=1.57r2=1.58 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/macro.c.diff?cvsroot=gccr1=1.9r2=1.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug preprocessor/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
15:35 ---
(In reply to comment #13)
The thing that was stopping me from commiting was that I'm now seeing
FAIL: gcc.dg/cpp/arith-3.c (test for bogus messages, line 257)
regression on i386 and x86-64 when starting bootstrap from 20050228
gcc-4_0-branch. But I have just verified that this is unrelated to my
macro.c fix (which doesn't change the code in any way on i386 even),
but it looks like libgcc.a(expr.o) is miscompiled at -O{2,3,s}.
So will need to do debugging once again for this, but will commit fix for
this PR first.
I have been seeing this for a while now.
See http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg00142.html for a test
results where this
happens for an unmodified source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug debug/20253] [3.4 regression]: Macro debug info broken due to lexer change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 15:35 --- Fixed also on the 4.0 branch, 3.4 is a little harder as the loop has changed. -- What|Removed |Added Summary|[3.4/4.0 regression]: Macro |[3.4 regression]: Macro |debug info broken due to|debug info broken due to |lexer change|lexer change http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20253
[Bug c/20318] RFE: add attribute to specify that a function never returns NULL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 15:38 --- Confirmed, PR 19476 is case which depends on this. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org OtherBugsDependingO||19476 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic, missed- ||optimization Last reconfirmed|-00-00 00:00:00 |2005-03-04 15:38:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
[Bug java/18362] [4.0 Regression] internal compiler error: in size_binop, at fold-const.c:1598
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04 15:38 --- Subject: Bug 18362 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-04 15:38:14 Modified files: gcc/java : ChangeLog class.c Log message: 2005-03-04 Andrew Haley [EMAIL PROTECTED] PR java/18362 * class.c (set_method_index): Don't set method_index if it is NULL_TREE. (layout_class_method): Don't complain about non-static method foo overrides static method in the case of indirect dispatch. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1560r2=1.1561 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gccr1=1.220r2=1.221 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18362
[Bug preprocessor/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04 15:39 --- Subject: Bug 20282 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-04 15:39:37 Modified files: libcpp : ChangeLog macro.c Log message: PR bootstrap/20282 PR bootstrap/20305 * macro.c (replace_args, cpp_get_token): Copy whole cpp_token_u instead of just cpp_string field from it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.56.2.1r2=1.56.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/macro.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9r2=1.9.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug bootstrap/20305] [4.0/4.1 Regression] Miscompilation of libcpp/macro.c at -O1 and higher
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04 15:39 --- Subject: Bug 20305 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-04 15:39:37 Modified files: libcpp : ChangeLog macro.c Log message: PR bootstrap/20282 PR bootstrap/20305 * macro.c (replace_args, cpp_get_token): Copy whole cpp_token_u instead of just cpp_string field from it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.56.2.1r2=1.56.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/macro.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9r2=1.9.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug c++/19476] Missed null checking elimination with new
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
[Bug preprocessor/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-04 15:43
---
I'm using:
./cc1 x.c
on
#define APPEND2(NUM, SUFF) NUM ## SUFF
#define APPEND(NUM, SUFF) APPEND2(NUM, SUFF)
# define MAX_INT 9223372036854775807
#define TARG_MIN (-TARG_MAX - 1)
#define TARG_MAX APPEND (MAX_INT, L)
#if 1 * TARG_MIN != TARG_MIN/* { dg-bogus overflow } */
# error /* { dg-bogus error } */
#endif
as a test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug c++/20186] [4.0/4.1 regression] ICE with static_cast and type dependent variable (templates)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-02-26 18:41:56 |2005-03-04 16:15:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20186
[Bug c/20319] New: -fkeep-static-consts with -O asserted doesn't keep consts
Related discussion:
http://gcc.gnu.org/ml/gcc/2005-03/msg00181.html
Given the following,
static char const rcsid[] =
$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $;
int main() {}
When compiled with GCC 3.4.3, at -O2, the ident string above will _not_
appear in the executable. This is apparently expected behavior.
However,
gcc -fkeep-static-consts -O2 t.c
did not retain the ident string, rcsid, defined above. Shouldn't
-fkepp-static-consts have ensured that this static constant would appear
in the executable?
The logic in wrapup_global_declarations (toplev.c) doesn't look quite right:
else if (TREE_READONLY (decl) !TREE_PUBLIC (decl)
(optimize || !flag_keep_static_consts
|| DECL_ARTIFICIAL (decl)))
needed = 0;
If 'optimize' is asserted above then flag_keep_static_consts will
not be tested. Perhaps it should read as follows?
((optimize !flag_keep_static_consts)
Alternatively, I wonder if flag_keep_static_consts should be tested earlier at a
higher level, for example:
if (flag_keep_static_consts)
/* needed */;
but I'm not sure about which of the earlier tests which assert needed = 0;
are mandatory and which are optional.
--
Summary: -fkeep-static-consts with -O asserted doesn't keep
consts
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319
[Bug libf2c/20320] New: GCC 3.3.2 on AMD opetron 64 bits Linux machine
Hi,
I am trying to install gcc 3.3.2 on AMD opetron 64 bits Linux machine and I am
getting following error.Any help would be highly appreciated.
uname -a - Linux abgixcluster.geoquest 2.4.21-4.ELsmp #1 SMP Fri Oct 3
17:32:58 EDT 2003 x86_64 x86_64 x86_64 GNU/Linux
Thanks
Ajay
loading cache ../config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether make sets ${MAKE}... (cached) yes
checking how to run the C preprocessor...
(cached) /data/zion/intersect/local_linux_src/amd_cluster_src/gcc-
3.3.2/gcc/xgcc -B/data/zion/intersect/local_linux_src/amd_cluster_src/gcc-
3.3.2/gcc/ -B/data/zion/intersect/local_linux/amd_cluster_libs/x86_64-unknown-
linux-gnu/bin/ -B/data/zion/intersect/local_linux/amd_cluster_libs/x86_64-
unknown-linux-gnu/lib/ -
isystem /data/zion/intersect/local_linux/amd_cluster_libs/x86_64-unknown-linux-
gnu/include -m32 -E
checking for stdio.h... (cached) yes
checking for built-in g77 integer types... (cached) yes
creating ./config.status
creating Makefile
creating g2c.h
Adding multilib support to Makefile in .
with_multisubdir=32
configuring in libU77
running /bin/sh ./../../../configure --with-multisubdir=32 --with-
multisrctop=../ --enable-multilib --host=x86_64-unknown-linux-gnu --
build=x86_64-unknown-linux-gnu --enable-multilib --with-gcc-version-
trigger=/data/zion/intersect/local_linux_src/amd_cluster_src/gcc-
3.3.2/gcc/version.c --prefix=/data/zion/intersect/local_linux/amd_cluster_libs -
-disable-nls --enable-64bit --with-target-subdir=x86_64-unknown-linux-gnu --
cache-file=../../config.cache --srcdir=.
./../../../configure: ./../../../configure: No such file or directory
configure: error: ./../../../configure failed for libU77
make[1]: *** [g2c.h] Error 1
make[1]: Leaving directory
`/data/zion/intersect/local_linux_src/amd_cluster_src/gcc-3.3.2/x86_64-unknown-
linux-gnu/libf2c'
make: *** [all-target-libf2c] Error 2
--
Summary: GCC 3.3.2 on AMD opetron 64 bits Linux machine
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: critical
Priority: P1
Component: libf2c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajve at chevrontexaco dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20320
Error- GCC 3.3.2 on AMD opetron 64 bits Linux machine
Hi,
I am trying to install gcc 3.3.2 on AMD opetron 64 bits Linux machine
and I am
getting following error.Any help would be highly appreciated.
uname -a - Linux abgixcluster.geoquest 2.4.21-4.ELsmp #1 SMP Fri Oct 3
17:32:58 EDT 2003 x86_64 x86_64 x86_64 GNU/Linux
Thanks
Ajay
loading cache ../config.cache
checking for a BSD compatible install... /usr/bin/install -c checking
whether make sets ${MAKE}... (cached) yes checking how to run the C
preprocessor...
(cached) /data/zion/intersect/local_linux_src/amd_cluster_src/gcc-
3.3.2/gcc/xgcc
-B/data/zion/intersect/local_linux_src/amd_cluster_src/gcc-
3.3.2/gcc/
-B/data/zion/intersect/local_linux/amd_cluster_libs/x86_64-unknown-
linux-gnu/bin/
-B/data/zion/intersect/local_linux/amd_cluster_libs/x86_64-
unknown-linux-gnu/lib/ -
isystem
/data/zion/intersect/local_linux/amd_cluster_libs/x86_64-unknown-linux-
gnu/include -m32 -E
checking for stdio.h... (cached) yes
checking for built-in g77 integer types... (cached) yes creating
./config.status creating Makefile creating g2c.h Adding multilib support
to Makefile in . with_multisubdir=32 configuring in libU77 running
/bin/sh ./../../../configure --with-multisubdir=32 --with-
multisrctop=../ --enable-multilib --host=x86_64-unknown-linux-gnu --
build=x86_64-unknown-linux-gnu --enable-multilib --with-gcc-version-
trigger=/data/zion/intersect/local_linux_src/amd_cluster_src/gcc-
3.3.2/gcc/version.c
--prefix=/data/zion/intersect/local_linux/amd_cluster_libs -
-disable-nls --enable-64bit
--with-target-subdir=x86_64-unknown-linux-gnu --
cache-file=../../config.cache --srcdir=.
./../../../configure: ./../../../configure: No such file or directory
configure: error: ./../../../configure failed for libU77
make[1]: *** [g2c.h] Error 1
make[1]: Leaving directory
`/data/zion/intersect/local_linux_src/amd_cluster_src/gcc-3.3.2/x86_64-u
nknown-
linux-gnu/libf2c'
make: *** [all-target-libf2c] Error 2
--
Summary: GCC 3.3.2 on AMD opetron 64 bits Linux machine
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: critical
Priority: P1
Component: libf2c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajve at chevrontexaco dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20320
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
[Bug c/20321] New: keep static constants if named section attribute asserted
Related discussion:
http://gcc.gnu.org/ml/gcc/2005-03/msg00181.html
Related bug report: Bug #20319
I tried adding a section attribute to a static constant string declaration
which is otherwise not referenced, in the hope that the compiler would
retain the static constant because it had been explicitly
targeted to a named section,
static char const __attribute__ ((section(ident_sect))) rcsid[] =
$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $;
int main() {}
but this didn't prevent the elimination of the const static defintion.
Enhancement request: If an explicit section attribute
is supplied for a static constant declaration (where the declaration
is not otherwise referenced), do not eliminate the static constant
definition. The rationale for this policy is that it is
reasonable to assume that if the user is explicitly assigning the
static constant to a named section, then he/she intends to use that
static constant defintion, and does not want it eliminated from the
executable image.
--
Summary: keep static constants if named section attribute
asserted
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20321
[Bug libf2c/20320] GCC 3.3.2 on AMD opetron 64 bits Linux machine
--- Additional Comments From ajve at chevrontexaco dot com 2005-03-04
17:27 ---
Hi,
I am trying to install gcc 3.3.2 on AMD opetron 64 bits Linux machine and I am
getting following error.Any help would be highly appreciated.
uname -a - Linux abgixcluster.geoquest 2.4.21-4.ELsmp #1 SMP Fri Oct 3
17:32:58 EDT 2003 x86_64 x86_64 x86_64 GNU/Linux
Thanks
Ajay
loading cache ../config.cache
checking for a BSD compatible install... /usr/bin/install -c checking whether
make sets ${MAKE}... (cached) yes checking how to run the C preprocessor...
(cached) /data/zion/intersect/local_linux_src/amd_cluster_src/gcc-
3.3.2/gcc/xgcc -B/data/zion/intersect/local_linux_src/amd_cluster_src/gcc-
3.3.2/gcc/ -B/data/zion/intersect/local_linux/amd_cluster_libs/x86_64-unknown-
linux-gnu/bin/ -B/data/zion/intersect/local_linux/amd_cluster_libs/x86_64-
unknown-linux-gnu/lib/ -
isystem /data/zion/intersect/local_linux/amd_cluster_libs/x86_64-unknown-linux-
gnu/include -m32 -E
checking for stdio.h... (cached) yes
checking for built-in g77 integer types... (cached) yes
creating ./config.status creating Makefile creating g2c.h Adding multilib
support to Makefile in . with_multisubdir=32 configuring in libU77
running /bin/sh ./../../../configure --with-multisubdir=32 --with-
multisrctop=../ --enable-multilib --host=x86_64-unknown-linux-gnu --
build=x86_64-unknown-linux-gnu --enable-multilib --with-gcc-version-
trigger=/data/zion/intersect/local_linux_src/amd_cluster_src/gcc-
3.3.2/gcc/version.c --prefix=/data/zion/intersect/local_linux/amd_cluster_libs -
-disable-nls --enable-64bit --with-target-subdir=x86_64-unknown-linux-gnu --
cache-file=../../config.cache --srcdir=.
./../../../configure: ./../../../configure: No such file or directory
configure: error: ./../../../configure failed for libU77
make[1]: *** [g2c.h] Error 1
make[1]: Leaving directory
`/data/zion/intersect/local_linux_src/amd_cluster_src/gcc-3.3.2/x86_64-unknown-
linux-gnu/libf2c'
make: *** [all-target-libf2c] Error 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20320
[Bug target/20322] New: Miscompilation of libcpp/expr.c at -O2+
libcpp/expr.c is miscompiled when compiled with gcc-4_0-branch GCC on x86-64
(and likely i386 as well).
expr.c miscompiled that way causes a testsuite regression on arith-3.c:
FAIL: gcc.dg/cpp/arith-3.c (test for bogus messages, line 257)
Self-contained testcase that reproduces the problem is:
extern void abort (void);
typedef unsigned long long T;
typedef struct
{
T a, b;
unsigned char c, d;
} S;
#define M (sizeof (T) * 4)
S __attribute__((noinline))
foo (T x, T y)
{
S e;
T f[2], g;
e.b = (x (~(T) 0 M)) * (y (~(T) 0 M));
e.a = (x M) * (y M);
f[0] = (x (~(T) 0 M)) * (y M);
f[1] = (x M) * (y (~(T) 0 M));
g = e.b;
e.b += (f[0] (~(T) 0 M)) M;
if (e.b g)
e.a++;
g = e.b;
e.b += (f[1] (~(T) 0 M)) M;
if (e.b g)
e.a++;
e.a += (f[0] M);
e.a += (f[1] M);
e.c = 1;
e.d = 0;
return e;
}
int
main (void)
{
T x = 1ULL (M * 2 - 1);
S y = foo (1, x);
if (y.a || y.b != x || y.c != 1 || y.d)
abort ();
return 0;
}
--
Summary: Miscompilation of libcpp/expr.c at -O2+
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20322
[Bug c/20318] RFE: add attribute to specify that a function never returns NULL
--- Additional Comments From giovannibajo at libero dot it 2005-03-04 17:53 --- I don't object that this feature is indeed needed, but I would still like to see a reduced testcase from Subversion which shows a bogus warning that could be fixed with this attribute. BTW, Diego, once ASSERT_EXPR becomes a generic node, can't just the C++ FE uses it to assert that the return value for a CALL_EXPR to an allocation function is non-zero? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
[Bug c/20317] Solaris 10 and HUGE_VAL
--- Additional Comments From joseph at codesourcery dot com 2005-03-04 17:58 --- Subject: Re: New: Solaris 10 and HUGE_VAL On Fri, 4 Mar 2005, martin at v dot loewis dot de wrote: I'll attach the preprocessor output if I can; in short, HUGE_VAL expands to __builtin_huge_val, which is a function in gcc but a constant in SunPRO. fixinclude needs to adjust this difference, fixing iso/math_c99.h appropriately. Surely this is the same as bug 19933? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317
[Bug c/20318] RFE: add attribute to specify that a function never returns NULL
--- Additional Comments From dnovillo at redhat dot com 2005-03-04 17:59 --- Subject: Re: RFE: add attribute to specify that a function never returns NULL giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2005-03-04 17:53 --- I don't object that this feature is indeed needed, but I would still like to see a reduced testcase from Subversion which shows a bogus warning that could be fixed with this attribute. I have attached the pre-processed test case from Joe. BTW, Diego, once ASSERT_EXPR becomes a generic node, can't just the C++ FE uses it to assert that the return value for a CALL_EXPR to an allocation function is non-zero? The attribute would be enough. The FE need only set an ECF_ flag to the CALL_EXPR and the optimizers will pick it up from there. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
[Bug fortran/19443] log10 statement does not work properly in gfortran
--- Additional Comments From mgilbert at airborne dot nrl dot navy dot mil
2005-03-04 18:01 ---
I updated all cygwin packages recently as well as gfortran before the hd crash
and ensuing lack of cygwin build on gfortran.org. However, I just got around to
testing the code again. It appears that everything works correctly now.
$ gfc --version
GNU Fortran 95 (GCC 4.0.0 20050131 (experimental))
Copyright (C) 2005 Free Software Foundation, Inc.
$ cat log_test.f90
program test
implicit none
REAL*4 :: tst4
real*8 :: tst8
tst4 = 1e-5_4
tst8 = 1e-5_8
write (*,*) log with real*4 .., 10*log (1e-5_4), 10*log (tst4)
write (*,*) log with real*8 .., 10*log (1e-5_8), 10*log (tst8)
write (*,*) log10 with real*4 , 10*log10 (1e-5_4), 10*log10 (tst4)
write (*,*) log10 with real*8 , 10*log10 (1e-5_8), 10*log10 (tst8)
end program test
$ gfc -o log_test log_test.f90 ./log_test
log with real*4 .. -115.1292 -115.1292
log with real*8 .. -115.129254649702 -115.129254649702
log10 with real*4 -50.0 -50.0
log10 with real*8 -50.0 -50.0
The -fdump-tree-gimple flag doesn't appear to be available for gcc 3.3.3. For
your reference, here is the gfc .original file
$ gfc -fdump-tree-original log_test.f90
$ cat log_test.f90.t02.orginal
MAIN__ ()
{
real4 tst4;
real8 tst8;
tst4 = 9.9974737875163555145263671875e-6;
tst8 = 1.8180305391403130954586231382564e-5;
_gfortran_filename = log_test.f90;
_gfortran_line = 7;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.list_format = 1;
_gfortran_st_write ();
_gfortran_transfer_character (log with real*4 .., 22);
{
real4 C.452 = -1.1512924957275390625e+2;
_gfortran_transfer_real (C.452, 4);
}
{
real4 D.453;
D.453 = __builtin_logf (tst4) * 1.0e+1;
_gfortran_transfer_real (D.453, 4);
}
_gfortran_st_write_done ();
_gfortran_filename = log_test.f90;
_gfortran_line = 8;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.list_format = 1;
_gfortran_st_write ();
_gfortran_transfer_character (log with real*8 .., 22);
{
real8 C.454 = -1.15129254649702289725610171444714069366455078125e+2;
_gfortran_transfer_real (C.454, 8);
}
{
real8 D.455;
D.455 = __builtin_log (tst8) * 1.0e+1;
_gfortran_transfer_real (D.455, 8);
}
_gfortran_st_write_done ();
_gfortran_filename = log_test.f90;
_gfortran_line = 9;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.list_format = 1;
_gfortran_st_write ();
_gfortran_transfer_character (log10 with real*4 , 22);
{
real4 C.456 = -5.0e+1;
_gfortran_transfer_real (C.456, 4);
}
{
real4 D.457;
D.457 = __builtin_log10f (tst4) * 1.0e+1;
_gfortran_transfer_real (D.457, 4);
}
_gfortran_st_write_done ();
_gfortran_filename = log_test.f90;
_gfortran_line = 10;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.list_format = 1;
_gfortran_st_write ();
_gfortran_transfer_character (log10 with real*8 , 22);
{
real8 C.458 = -5.0e+1;
_gfortran_transfer_real (C.458, 8);
}
{
real8 D.459;
D.459 = __builtin_log10 (tst8) * 1.0e+1;
_gfortran_transfer_real (D.459, 8);
}
_gfortran_st_write_done ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-02-27 16:33:26 |2005-03-04 18:09:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug c/20321] keep static constants if named section attribute asserted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 18:09 --- Use the attribute used to keep the constants. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20321
[Bug c/20317] Solaris 10 and HUGE_VAL
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-04 18:10 --- Surely this is the same as bug 19933? Right, Duplicates with a big D. :-) *** This bug has been marked as a duplicate of 19933 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-04 18:10 --- *** Bug 20317 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||martin at v dot loewis dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-04 18:11 --- Confirmed by duplicate. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC host triplet|i386-pc-solaris2.10 |*-*-solaris2.10 Last reconfirmed|-00-00 00:00:00 |2005-03-04 18:11:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug target/20322] [4.0 Regression] Miscompilation of libcpp/expr.c at -O2+
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Summary|Miscompilation of |[4.0 Regression] |libcpp/expr.c at -O2+ |Miscompilation of ||libcpp/expr.c at -O2+ Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20322
[Bug target/20322] [4.0/4.1 Regression] Miscompilation of libcpp/expr.c at -O2+
-- What|Removed |Added Summary|[4.0 Regression]|[4.0/4.1 Regression] |Miscompilation of |Miscompilation of |libcpp/expr.c at -O2+ |libcpp/expr.c at -O2+ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20322
[Bug libf2c/20320] GCC 3.3.2 on AMD opetron 64 bits Linux machine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 18:22 --- How did you configure GCC and how did you build it? Also why do you want 3.3.2, 3.4.3 is out and have some fixes for fortran too. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Status|UNCONFIRMED |WAITING Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20320
[Bug bootstrap/12026] m68k-coff build fails due to undefined references to _EH_FRAME_BEGIN
--- Additional Comments From ericw at evcohs dot com 2005-03-04 18:24 --- Could this problem be because it needs the --with-dwarf2 configure switch (for the __EH_FRAME_BEGIN__)? Reference: http://gcc.gnu.org/ml/gcc/2002-07/msg00352.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12026
[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04
18:29 ---
Nope, -fkeep-static-consts only control when optimization is not on:
From the docs:
Emit variables declared @code{static const} when optimization isn't
turned
on, even if the variables aren't referenced.
Enphise mine.
Use the used attribute if you want to keep unused constants.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319
[Bug target/20322] [4.0/4.1 Regression] Miscompilation of libcpp/expr.c at -O2+
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-04 18:30
---
From initial skimming, this sounds like combiner bug.
(insn 78 41 79 0 (set (reg:CC 17 flags)
(compare:CC (reg:DI 58 [ e$b.9 ])
(reg:DI 59 [ e$b.8 ]))) 2 {cmpdi_1_insn_rex64}
(insn_list:REG_DEP_TRUE 41 (nil))
(expr_list:REG_DEAD (reg:DI 59 [ e$b.8 ])
(nil)))
(insn 79 78 52 0 (parallel [
(set (reg:DI 64 [ e$a ])
(plus:DI (plus:DI (ltu:DI (reg:CC 17 flags)
(const_int 0 [0x0]))
(reg:DI 64 [ e$a ]))
(const_int 0 [0x0])))
(clobber (reg:CC 17 flags))
]) 174 {adddi3_carry_rex64} (insn_list:REG_DEP_TRUE 77
(insn_list:REG_DEP_TRUE 78 (nil)))
(expr_list:REG_DEAD (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 52 79 53 0 (parallel [
(set (reg:DI 76)
(lshiftrt:DI (reg:DI 61 [ f$0 ])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) 435 {*lshrdi3_1_rex64} (nil)
(expr_list:REG_DEAD (reg:DI 61 [ f$0 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 53 52 55 0 (parallel [
(set (reg:DI 60 [ e$a.6 ])
(plus:DI (reg:DI 64 [ e$a ])
(reg:DI 76)))
(clobber (reg:CC 17 flags))
]) 192 {*adddi_1_rex64} (insn_list:REG_DEP_TRUE 79
(insn_list:REG_DEP_TRUE 52 (nil)))
(expr_list:REG_DEAD (reg:DI 64 [ e$a ])
(expr_list:REG_DEAD (reg:DI 76)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
before combine is turned into:
(insn 78 41 79 0 (set (reg:CC 17 flags)
(compare:CC (reg:DI 58 [ e$b.9 ])
(reg:DI 59 [ e$b.8 ]))) 2 {cmpdi_1_insn_rex64}
(insn_list:REG_DEP_TRUE 41 (nil))
(expr_list:REG_DEAD (reg:DI 59 [ e$b.8 ])
(nil)))
(note 79 78 52 0 NOTE_INSN_DELETED)
(insn 52 79 53 0 (parallel [
(set (reg:DI 76)
(lshiftrt:DI (reg:DI 61 [ f$0 ])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) 435 {*lshrdi3_1_rex64} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:DI 61 [ f$0 ])
(nil
(insn 53 52 55 0 (parallel [
(set (reg:DI 60 [ e$a.6 ])
(plus:DI (plus:DI (ltu:DI (reg:CC 17 flags)
(const_int 0 [0x0]))
(reg:DI 64 [ e$a ]))
(reg:DI 76)))
(clobber (reg:CC 17 flags))
]) 174 {adddi3_carry_rex64} (insn_list:REG_DEP_TRUE 77
(insn_list:REG_DEP_TRUE 52 (nil)))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:DI 76)
(expr_list:REG_DEAD (reg:DI 64 [ e$a ])
(nil)
which shouldn't be done, because the middle instruction is kept and clobbers
(reg:CC 17 flags), so combiner can't move use of %eflags from the first to the
last insn accross the clobber.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20322
[Bug preprocessor/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 18:31 --- Fixed. thanks Jakub for looking into this. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug bootstrap/20305] [4.0/4.1 Regression] Miscompilation of libcpp/macro.c at -O1 and higher
-- Bug 20305 depends on bug 20282, which changed state. Bug 20282 Summary: [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched
--- Additional Comments From janis at gcc dot gnu dot org 2005-03-04 18:36 --- I vastly overstated the failures in SPEC CPU2000 for this problem: ammp fails with both -m32 and -m64, and fma3d and sixtrack fail with -m32. Mainline GCC built last night still gets all of the testsuite and CPU2000 failures. The 4.0 compiler built last night now passes all of the named C torture tests, but fails buildling ammp, fma3d, and sixtrack with internal consistency failure; when I get some time I'll get a minimized test case for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20177
[Bug libf2c/20320] GCC 3.3.2 on AMD opetron 64 bits Linux machine
--- Additional Comments From ajve at chevrontexaco dot com 2005-03-04 18:53 --- Thanks Pinskia for the reply. Currently we are using GCC 3.3.2 on all the other machines and we have to go with this for sometime before we decide to upgrade gcc on all the machines. I use 1. ./configure --prefix=/data/zion/intersect/local_linux/amd_cluster_libs -- with-gnu-as --with-gnu-ld --disable-nls 2. make And it gives me this error. Am I missing anything in configure or make? An early reply would be highly appreciated as I am totally stuck with this. Thanks Ajay (In reply to comment #2) How did you configure GCC and how did you build it? Also why do you want 3.3.2, 3.4.3 is out and have some fixes for fortran too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20320
[Bug libf2c/20320] GCC 3.3.2 on AMD opetron 64 bits Linux machine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 18:55 --- Can you read the instruction here: http://gcc.gnu.org/install/ and try building in a different directory other than the source directory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20320
[Bug c/20317] Solaris 10 and HUGE_VAL
--- Additional Comments From martin at v dot loewis dot de 2005-03-04 19:01 --- Right. I did not find it because it does not have Solaris in its subject. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
19:08 ---
Subject: [PR c++/19199] don't turn cond_expr lvalue into min_expr rvalue
(continued from PR c++/20280)
On Mar 4, 2005, Mark Mitchell [EMAIL PROTECTED] wrote:
Actually, looking at this more closely, I think that something is
forgetting to call rationalize_conditional_expr, which is normally
called from unary_complex_lvalue. When the conditional expression is
used in the lvalue context, something should be calling that.
Normally, that happens because something calls build_unary_op
(ADDR_EXPR, ...) on the COND_EXPR.
It may be that I changed something to call build_addr (instead of
build_unary_op) in a case where that's not safe. Can you confirm or
deny that hypothesis?
I'm not sure you're still talking about PR 20280, or about PR 19199,
that is marked as a blocker because it appears to be the same problem,
but AFAICT really isn't.
Here's a patch that fixes PR c++/19199, by avoiding the transformation
from:
cond lt nop(int) parm a nop(int) parm b
parm a parm b
into:
nop(enum) min nop(int) parm a nop(int) parm b
since the latter is clearly not an lvalue, and
rationalize_conditional_expr doesn't manage to turn it back into one
(I don't think it should). I realize we might miss some optimization
opportunities because of this change in C, because the optimization
would be valid there, but I suppose we could arrange for cond_expr
operands in C to be forced into rvalues.
Still testing on x86_64-linux-gnu. Ok to install if it passes?
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR c++/19199
* fold-const.c (non_lvalue): Split tests into...
(maybe_lvalue_p): New function.
(fold_ternary): Use it to avoid turning a COND_EXPR lvalue into
an MIN_EXPR rvalue.
Index: gcc/fold-const.c
===
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.523
diff -u -p -r1.523 fold-const.c
--- gcc/fold-const.c 4 Mar 2005 06:24:09 - 1.523
+++ gcc/fold-const.c 4 Mar 2005 19:04:26 -
@@ -2004,16 +2004,12 @@ fold_convert (tree type, tree arg)
}
}
-/* Return an expr equal to X but certainly not valid as an lvalue. */
+/* Return false if expr can be assumed to not be an lvalue, true
+ otherwise. */
-tree
-non_lvalue (tree x)
+static bool
+maybe_lvalue_p (tree x)
{
- /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
- us. */
- if (in_gimple_form)
-return x;
-
/* We only need to wrap lvalue tree codes. */
switch (TREE_CODE (x))
{
@@ -2053,8 +2049,24 @@ non_lvalue (tree x)
/* Assume the worst for front-end tree codes. */
if ((int)TREE_CODE (x) = NUM_TREE_CODES)
break;
-return x;
+return false;
}
+
+ return true;
+}
+
+/* Return an expr equal to X but certainly not valid as an lvalue. */
+
+tree
+non_lvalue (tree x)
+{
+ /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
+ us. */
+ if (in_gimple_form)
+return x;
+
+ if (! maybe_lvalue_p (x))
+return x;
return build1 (NON_LVALUE_EXPR, TREE_TYPE (x), x);
}
@@ -7095,10 +7107,17 @@ fold_ternary (tree expr)
of B and C. Signed zeros prevent all of these transformations,
for reasons given above each one.
+We don't want to use operand_equal_for_comparison_p here,
+because it might turn an lvalue COND_EXPR into an rvalue one,
+see PR c++/19199.
+
Also try swapping the arguments and inverting the conditional. */
if (COMPARISON_CLASS_P (arg0)
- operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
-arg1, TREE_OPERAND (arg0, 1))
+ ((maybe_lvalue_p (arg1)
+ maybe_lvalue_p (TREE_OPERAND (t, 2)))
+ ? operand_equal_p (TREE_OPERAND (arg0, 0), arg1, OEP_ONLY_CONST)
+ : operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
+ arg1, TREE_OPERAND (arg0, 1)))
!HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (arg1
{
tem = fold_cond_expr_with_comparison (type, arg0,
@@ -7109,9 +7128,13 @@ fold_ternary (tree expr)
}
if (COMPARISON_CLASS_P (arg0)
- operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
-TREE_OPERAND (t, 2),
-TREE_OPERAND (arg0, 1))
+ ((maybe_lvalue_p (arg1)
+ maybe_lvalue_p (TREE_OPERAND (t, 2)))
+ ? operand_equal_p (TREE_OPERAND (arg0, 0),
+TREE_OPERAND (t, 2), OEP_ONLY_CONST)
+ : operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
+ TREE_OPERAND (t, 2),
+ TREE_OPERAND (arg0, 1)))
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
19:23 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 4, 2005, Mark Mitchell [EMAIL PROTECTED] wrote:
Your reading is logical, but it depends on exactly what lvalue for a
bit-field means. (Note that it does not say lvalue *is* a
bit-field; it says lvalue *for* a bit-field.)
Good point. Here's an all-new patch, with the comment updated to
reflect our discussion.
Still testing on x86_64-linux-gnu, ok to install if it succeeds?
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR c++/20280
* gimplify.c (gimplify_cond_expr): Add fallback argument. Use a
temporary variable of pointer type if an lvalues is required.
(gimplify_modify_expr_rhs): Request an rvalue from it.
(gimplify_expr): Pass fallback on.
Index: gcc/gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.113
diff -u -p -r2.113 gimplify.c
--- gcc/gimplify.c 18 Feb 2005 19:35:37 - 2.113
+++ gcc/gimplify.c 4 Mar 2005 19:18:49 -
@@ -2123,7 +2123,8 @@ gimple_boolify (tree expr)
*EXPR_P should be stored. */
static enum gimplify_status
-gimplify_cond_expr (tree *expr_p, tree *pre_p, tree *post_p, tree target)
+gimplify_cond_expr (tree *expr_p, tree *pre_p, tree *post_p, tree target,
+ fallback_t fallback)
{
tree expr = *expr_p;
tree tmp, tmp2, type;
@@ -2137,18 +2138,40 @@ gimplify_cond_expr (tree *expr_p, tree *
the arms. */
else if (! VOID_TYPE_P (type))
{
+ tree result;
+
if (target)
{
ret = gimplify_expr (target, pre_p, post_p,
is_gimple_min_lval, fb_lvalue);
if (ret != GS_ERROR)
ret = GS_OK;
- tmp = target;
+ result = tmp = target;
tmp2 = unshare_expr (target);
}
+ else if ((fallback fb_lvalue) == 0)
+ {
+ result = tmp2 = tmp = create_tmp_var (TREE_TYPE (expr), iftmp);
+ ret = GS_ALL_DONE;
+ }
else
{
- tmp2 = tmp = create_tmp_var (TREE_TYPE (expr), iftmp);
+ tree type = build_pointer_type (TREE_TYPE (expr));
+
+ if (TREE_TYPE (TREE_OPERAND (expr, 1)) != void_type_node)
+ TREE_OPERAND (expr, 1) =
+ build_fold_addr_expr (TREE_OPERAND (expr, 1));
+
+ if (TREE_TYPE (TREE_OPERAND (expr, 2)) != void_type_node)
+ TREE_OPERAND (expr, 2) =
+ build_fold_addr_expr (TREE_OPERAND (expr, 2));
+
+ tmp2 = tmp = create_tmp_var (type, iftmp);
+
+ expr = build (COND_EXPR, void_type_node, TREE_OPERAND (expr, 0),
+ TREE_OPERAND (expr, 1), TREE_OPERAND (expr, 2));
+
+ result = build_fold_indirect_ref (tmp);
ret = GS_ALL_DONE;
}
@@ -2169,7 +2192,7 @@ gimplify_cond_expr (tree *expr_p, tree *
/* Move the COND_EXPR to the prequeue. */
gimplify_and_add (expr, pre_p);
- *expr_p = tmp;
+ *expr_p = result;
return ret;
}
@@ -2907,7 +2930,8 @@ gimplify_modify_expr_rhs (tree *expr_p,
if (!is_gimple_reg_type (TREE_TYPE (*from_p)))
{
*expr_p = *from_p;
- return gimplify_cond_expr (expr_p, pre_p, post_p, *to_p);
+ return gimplify_cond_expr (expr_p, pre_p, post_p, *to_p,
+ fb_rvalue);
}
else
ret = GS_UNHANDLED;
@@ -3721,7 +3745,8 @@ gimplify_expr (tree *expr_p, tree *pre_p
break;
case COND_EXPR:
- ret = gimplify_cond_expr (expr_p, pre_p, post_p, NULL_TREE);
+ ret = gimplify_cond_expr (expr_p, pre_p, post_p, NULL_TREE,
+ fallback);
break;
case CALL_EXPR:
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR c++/20280
* g++.dg/tree-ssa/pr20280.C: New.
Index: gcc/testsuite/g++.dg/tree-ssa/pr20280.C
===
RCS file: gcc/testsuite/g++.dg/tree-ssa/pr20280.C
diff -N gcc/testsuite/g++.dg/tree-ssa/pr20280.C
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/g++.dg/tree-ssa/pr20280.C 4 Mar 2005 19:19:03 -
@@ -0,0 +1,63 @@
+// PR c++/20280
+
+// { dg-do compile }
+
+// Gimplification of the COND_EXPR used to fail because it had an
+// addressable type, and create_tmp_var rejected that.
+
+struct A
+{
+~A();
+};
+
+struct B : A {};
+
+A foo();
+
+void bar(bool b)
+{
+(B) (b ? foo() : foo());
+}
+
+// Make sure bit-fields and addressable types don't cause crashes.
+// These were not in the original bug report.
+
+// Added by Alexandre Oliva [EMAIL PROTECTED]
+
+// Copyright 2005 Free Software Foundation
+
+struct X
+{
+ long i : 32, j, k : 32;
+};
+
+void g(long);
+void h(const long);
+
+void f(X x,
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-03-04 19:38 --- In reply to comment #10. I agree with you Jörg, it is not a dramatic loss if you have a bit less efficient use of volatile pointers :-) and IMHO anybody in the avr community could live with it. I think it's possibly rather a question of style. I'd like to suggest that the explicit use of a macro while sticking to the standard convention for use of the volatile keyword might make it more transparent *why* and *that* an explicit treatment is required for 16 bit registers. Imagine the case of a person who is reading code written by someone else. Just seeing the volatile keyword would not make the possible danger clear. Maybe the volatile solution makes it easier for some programers and I agree with anybody that using macros tends to turn the code uglier. Possibly, however, there is the danger that one makes things easier than they are in fact: With either approach, the user will be required to be avare of the possible problem and would have to handle the code accordingly. My personal opinion is: If there is a pitfall with 16 bit registers, write code that names it by it's real name. Anyway I could also live with a solution that patches the compiler. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
-- What|Removed |Added CC||bjoern dot m dot haase at ||web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug target/20296] Speeding up small interrupts on avr
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-03-04 19:51 --- Hi, IMHO everyone working on the avr back-end is aware of this problem. The difficulty is, that the present architecture of the avr back-end does not easily permit to improve this case: Every instruction pattern (like multiply two 16 bit integers or sign-extend a 16 bit variable to 32 bits) presently is free to assume that may overwrite or change r0 and r1 unless it leaves the __zero_reg__ with 0 after finishing it's task. Resolving this issue, IMHO, would require a major refactoring of the back-end. ... IIUC the keyword is replace all of the more complex instruction patterns by RTL expressions. I suggest to mark this bug as desired enhancement. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20296
[Bug fortran/20323] New: optional arguments incorrectly accepted in specification expressions
In the program below, the optional argument arg is used as part of the specification expression for the length of a string. This is forbidden by section 7.1.6.2; constraint (2) of the F95 standard (and wouldn't make much sense anyway - what happens when the function is called without the optional argument?) gfortran accepts it without complaint, though. parabrisas:~/test% cat testpresent.f90 function testpresent(arg) integer, intent(in), optional :: arg character(len=arg) :: s logical :: testpresent testpresent=.true. end function testpresent parabrisas:~/test% gfortran -c testpresent.f90 parabrisas:~/test% gfortran -v Using built-in specs. Configured with: ../gcc/configure --prefix=/home/tow/root/gcc-4.0 --enable-languages=c,f95 : (reconfigured) ../gcc/configure --prefix=/home/tow/root/gcc-4.0 --with-gcc-version-trigger=/home/tow/dl/gcc/gcc/gcc/version.c --enable-languages=c,f95 --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/home/tow/root/gcc-4.0 --with-gcc-version-trigger=/home/tow/dl/gcc/gcc/gcc/version.c --enable-languages=c,f95 --no-create --no-recursion Thread model: posix gcc version 4.0.0 20050127 (experimental) -- Summary: optional arguments incorrectly accepted in specification expressions Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tow21 at cam dot ac dot uk CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20323
[Bug c/20222] [AVR] Double load of volatile operand
-- What|Removed |Added CC||bjoern dot m dot haase at ||web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
[Bug middle-end/20222] [AVR] Double load of volatile operand
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
[Bug middle-end/20222] [AVR] Double load of volatile operand
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 20:19 --- This is a bug in the middle-end: ;; if (ABS_EXPR xi1 != 1) (void) 0; else goto L3; (insn 29 27 30 (set (reg:HI 44) (mem/i:HI (symbol_ref:HI (xi1) [flags 0x40] var_decl 0x415784a4 xi1) [2 xi1+0 S2 A8])) -1 (nil) (nil)) (insn 30 29 31 (set (reg:HI 45) (mem/i:HI (symbol_ref:HI (xi1) [flags 0x40] var_decl 0x415784a4 xi1) [2 xi1+0 S2 A8])) -1 (nil) (nil)) -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-03-04 20:19:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts
--- Additional Comments From gary at intrepid dot com 2005-03-04 20:24
---
Emit variables declared @code{static const} when optimization isn't turned
on, even if the variables aren't referenced.
How odd. I should've checked the docs, but this brief explanation in the
help line made a lot of sense to me.
-fkeep-static-constsEmit static const variables even if they are not
used
Also, since the constant *was kept* when I compiled _without_ optimization,
the idea of passing a switch telling the compiler to do something that
it seemed to already be doing by default didn't make sense to me.
The comments inside toplev.c say the following:
/* Nonzero means that we should emit static const variables
regardless of whether or not optimization is turned on. */
int flag_keep_static_consts = 1;
which makes sense to me. Note that this is the default setting.
So ... coming back to the if statement in toplev.c:
else if (TREE_READONLY (decl) !TREE_PUBLIC (decl)
(optimize || !flag_keep_static_consts
|| DECL_ARTIFICIAL (decl)))
needed = 0;
At present,
If optimize is set, the unused static constant will always be eliminated
and -fkeep-static-consts will have no effect, and there is no way to override
this behavior (except for __attribute__ ((used))).
This agrees with the documentation, but disagrees with the
comment in the code, and with the spirit of the help message. It also
doesn't make sense to me that -fkeep-static-consts would be ignored. In
fact, it seems to me that -fkeep-static-consts should override the
optimization setting. Otherwise, only -fno-keep-static-consts has
any effect and that is only when optimization is not enabled.
I think the behavior of -fkeep-static-consts should be modified so that
setting this switch overrides the optimization level. Thus, the
documentation would need to be changed as well. Otherwise, the internal
comments and the help line are wrong.
Regarding the used attibute, I thought that I'd tried that, and it
didn't work. But upon retesting, it does seem to have the desired
effect of keeping the static const around (maybe I specified the unused
attribute by mistake in my test).
Note that the used attribute is described only under function attributes
and not under variable attributes in the documentation:
used
This attribute, attached to a function, means that code must be emitted for
the function even if it appears that the function is not referenced. This is
useful, for example, when the function is referenced only in inline assembly.
(see: http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Function-
Attributes.html#Function-Attributes)
It would be helpful if the documentation were updated to describe the
behavior of the `used' attribute when apllied to variables.
--
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319
[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 20:33 --- Don't belive the comments in the source. Also the --help is way out of date. you want to use the used attribute like so: static char const rcsid[]__attribute__((used)) = $Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $; And this works for me. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319
[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts
--- Additional Comments From joseph at codesourcery dot com 2005-03-04 20:42 --- Subject: Re: -fkeep-static-consts with -O asserted doesn't keep consts On Fri, 4 Mar 2005, pinskia at gcc dot gnu dot org wrote: Don't belive the comments in the source. Also the --help is way out of date. Both comments being wrong and --help being wrong are bugs. This PR should be kept open until whatever semantics are agreed are documented in the manual, in --help output, in comments and are implemented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04 21:04 --- Subject: Bug 19673 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-04 21:03:46 Modified files: gcc/fortran: ChangeLog trans-expr.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: func_result_1.f90 Log message: fortran/ PR fortran/19673 * trans-expr.c (gfc_conv_function_call): Correctly dereference argument from a pointer function also if it has a result clause. testsuite/ PR fortran/19673 * gfortran.dg/func_result_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.342r2=1.343 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.38r2=1.39 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5108r2=1.5109 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/func_result_1.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug c++/20324] New: Tru64 assembler cores for 3.4.3 g++ -gcoff of #include iostream
On a Tru64 alpha system, when I compile a file containing: #include iostream using g++ 3.4.3 as follows: g++ -c -gcoff I get the following output: mips-tfile, /tmp//ccnFchPc.s:1071 compiler error, badly formed #.def (internal line # = 2812) line: #.def .eos; .val1; .scl102; .tag13__type_traitsIbE; .size 1; .endef mips-tfile, /tmp//ccnFchPc.s:1072 compiler error, badly formed #.def (internal line # = 2812) line: #.def 13__type_traitsIbE; .scl13; .tag13__type_traitsIbE; .size 1; .type 0x8;.endef mips-tfile, /tmp//ccnFchPc.s:1074 compiler error, badly formed #.def (internal line # = 2812) line: #.def .eos; .val1; .scl102; .tag13__type_traitsIcE; .size 1; .endef mips-tfile, /tmp//ccnFchPc.s:1075 compiler error, badly formed #.def (internal line # = 2812) line: #.def 13__type_traitsIcE; .scl13; .tag13__type_traitsIcE; .size 1; .type 0x8;.endef mips-tfile, /tmp//ccnFchPc.s:1077 compiler error, badly formed #.def (internal line # = 2812) line: #.def .eos; .val1; .scl102; .tag13__type_traitsIaE; .size 1; .endef mips-tfile, /tmp//ccnFchPc.s:1078 compiler error, badly formed #.def (internal line # = 2812) line: #.def 13__type_traitsIaE; .scl13; .tag13__type_traitsIaE; .size 1; .type 0x8;.endef mips-tfile, /tmp//ccnFchPc.s:1080 compiler error, badly formed #.def (internal line # = 2812) line: #.def .eos; .val1; .scl102; .tag13__type_traitsIhE; .size 1; .endef mips-tfile, /tmp//ccnFchPc.s:1081 compiler error, badly formed #.def (internal line # = 2812) line: #.def 13__type_traitsIhE; .scl13; .tag13__type_traitsIhE; .size 1; .type 0x8;.endef mips-tfile, /tmp//ccnFchPc.s:1083 compiler error, badly formed #.def (internal line # = 2812) line: #.def .eos; .val1; .scl102; .tag13__type_traitsIwE; .size 1; .endef mips-tfile, /tmp//ccnFchPc.s:1084 compiler error, badly formed #.def (internal line # = 2812) line: #.def 13__type_traitsIwE; .scl13; .tag13__type_traitsIwE; .size 1; .type 0x8;.endef mips-tfile, /tmp//ccnFchPc.s:1086 compiler error, badly formed #.def (internal line # = 2812) line: #.def .eos; .val1; .scl102; .tag13__type_traitsIsE; .size 1; .endef mips-tfile, /tmp//ccnFchPc.s:1087 compiler error, badly formed #.def (internal line # = 2812) line: #.def 13__type_traitsIsE; .scl13; .tag13__type_traitsIsE; .size 1; .type 0x8;.endef mips-tfile, /tmp//ccnFchPc.s:1089 compiler error, badly formed #.def (internal line # = 2812) line: #.def .eos; .val1; .scl102; .tag13__type_traitsItE; .size 1; .endef mips-tfile, /tmp//ccnFchPc.s:1090 compiler error, badly formed #.def (internal line # = 2812) line: #.def 13__type_traitsItE; .scl13; .tag13__type_traitsItE; .size 1; .type 0x8;.endef mips-tfile, /tmp//ccnFchPc.s:1092 compiler error, badly formed #.def (internal line # = 2812) line: #.def .eos; .val1; .scl102; .tag13__type_traitsIiE; .size 1; .endef mips-tfile, /tmp//ccnFchPc.s:1093 compiler error, badly formed #.def (internal line # = 2812) line: #.def 13__type_traitsIiE; .scl13; .tag13__type_traitsIiE; .size 1; .type 0x8;.endef mips-tfile, /tmp//ccnFchPc.s:1095 compiler error, badly formed #.def (internal line # = 2812) line: #.def .eos; .val1; .scl102; .tag13__type_traitsIjE; .size 1; .endef mips-tfile, /tmp//ccnFchPc.s:1096 compiler error, badly formed #.def (internal line # = 2812) line: #.def 13__type_traitsIjE; .scl13; .tag13__type_traitsIjE; .size 1; .type 0x8;.endef mips-tfile, /tmp//ccnFchPc.s:1098
[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts
--- Additional Comments From gary at intrepid dot com 2005-03-04 21:54 --- Here is some detail on my proposed change in behavior: 1) Change the default setting to -fno-keep-static-consts: /* Nonzero means that we should emit static const variables regardless of whether or not optimization is turned on. */ int flag_keep_static_consts = 0; 2) have flag_keep_static_consts affect only the behavior of the compiler when 'optimize' is asserted: Change the logic in wrapup_global_declarations (toplev.c) to read: else if (TREE_READONLY (decl) !TREE_PUBLIC (decl) (optimize !flag_keep_static_consts) || DECL_ARTIFICIAL (decl))) needed = 0; This change would imply that: 1) -fkeep-static-consts and -fno-keep-static-consts will have no effect at -O0. Presently, -fno-keep-static-consts would eliminate the unreferenced static const variable if it isn't referenced. This would no longer be the case. At -O0, the compiler would always leave unrefereced static consts alone. 2) If optimization is asserted (ie, -O1 and above), then always eliminate static const's that aren't referenced, unless -fkeep-static-consts is asserted. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-04 22:21 --- Subject: Bug 19673 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-04 22:21:17 Modified files: gcc/fortran: ChangeLog trans-expr.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: func_result_1.f90 Log message: fortran/ PR fortran/19673 * trans-expr.c (gfc_conv_function_call): Correctly dereference argument from a pointer function also if it has a result clause. testsuite/ PR fortran/19673 * gfortran.dg/func_result_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.6r2=1.335.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.38r2=1.38.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.15r2=1.5084.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/func_result_1.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-04 22:29 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug other/20325] New: bugzilla is missing a treelang component
every frontend has one, treelang should have one as well -- Summary: bugzilla is missing a treelang component Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at debian dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20325
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug other/20326] New: treelang does install the backend as a driver
the backend (tree1) is installed under the same name as the driver. if it does that, please symlink it, don't copy it. and maybe don't install it as tree1, but treelang, or something like this. -- Summary: treelang does install the backend as a driver Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: phython at gcc dot gnu dot org ReportedBy: doko at debian dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20326
[Bug other/20325] bugzilla is missing a treelang component
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 22:55 --- Fixed. I added one. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20325
[Bug treelang/20326] treelang does install the backend as a driver
-- What|Removed |Added Component|other |treelang http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20326
[Bug c++/20324] Tru64 assembler cores for 3.4.3 g++ -gcoff of #include iostream
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 22:59 --- *** This bug has been marked as a duplicate of 7055 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20324
[Bug debug/7055] [alpha osf4] G++ 3.1 Produced bad debugging entries if compiled with -gcoff, also segv.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-04 22:59 --- *** Bug 20324 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dsanderson at panasas dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7055
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
23:22 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 3, 2005, Andrew Pinski [EMAIL PROTECTED] wrote:
I think this is the wrong approach. The front-end and not
the gimplifier should be creating these temporaries, I mentioned
this already in the bug.
How about this?
I tried with the TARGET_EXPR by itself, but it failed to be recognized
as an lvalue, so I introduced the compound expr.
Testing on x86_64-linux-gnu. Ok to install if it passes?
Index: gcc/cp/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR c++/20103
* semantics.c (finish_compound_literal): Ensure the result is an
lvalue, by creating a compound-expr with a target-expr and its
decl.
Index: gcc/cp/semantics.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/semantics.c,v
retrieving revision 1.463
diff -u -p -r1.463 semantics.c
--- gcc/cp/semantics.c 23 Feb 2005 05:30:48 - 1.463
+++ gcc/cp/semantics.c 4 Mar 2005 23:17:50 -
@@ -1996,7 +1996,11 @@ finish_compound_literal (tree type, tree
complete_array_type (type, compound_literal, 1);
}
- return compound_literal;
+ /* A compound-literal is an lvalue in C, so make it so in C++ as
+ well. */
+ compound_literal = get_target_expr (compound_literal);
+ return build2 (COMPOUND_EXPR, TREE_TYPE (compound_literal),
+compound_literal, TARGET_EXPR_SLOT (compound_literal));
}
/* Return the declaration for the function-name variable indicated by
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
* g++.dg/tree-ssa/pr20103.C: New.
Index: gcc/testsuite/g++.dg/tree-ssa/pr20103.C
===
RCS file: gcc/testsuite/g++.dg/tree-ssa/pr20103.C
diff -N gcc/testsuite/g++.dg/tree-ssa/pr20103.C
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/g++.dg/tree-ssa/pr20103.C 4 Mar 2005 23:18:05 -
@@ -0,0 +1,34 @@
+// PR c++/20103
+
+// { dg-do compile }
+
+// { dg-options }
+
+// Gimplification used to fail for (B){x}, because create_tmp_var
+// required a non-addressable type, and we didn't wrap the constructor
+// in a target_expr, ensuring it's taken as an lvalue.
+
+struct A
+{
+A(const A);
+};
+
+struct B
+{
+A a;
+};
+
+void foo(B);
+void bar(B);
+void bap(B*);
+
+void baz(A x)
+{
+foo ((B){x});
+bar ((B){x});
+bap ((B){x});
+
+foo ((const B)(B){x});
+bar ((B)(B){x});
+bap ((B)(B){x});
+}
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
