[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- Comment #10 from bonzini at gnu dot org 2009-08-05 06:09 --- preprocessed testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug fortran/40969] [4.5 regression] gfortran.dg/c_by_val_1.f failed
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-05 07:19 --- Works for me on x86-64-linux and seems also to work on several other systems according to the testresults mailing list. (Only failure - your ia64 system: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00487.html) As I cannot reproduce it, can you provide more details? * * * Side note: Can you change your tester to not attach the results as binary but as text/..., cf. http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00484.html; that makes is quicker to reading the test results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40955] STDCALL attributes are not saved in the .MOD files
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-05 08:00 --- Regarding gfc_copy_attr: The following program should print on x86-64(-linux) the warnings: warning: 'dllexport' attribute directive ignored warning: 'stdcall' attribute directive ignored abstract interface subroutine tpl() !GCC$ ATTRIBUTES STDCALL :: tpl end subroutine tpl end interface procedure(tpl) :: foo !GCC$ ATTRIBUTES DLLEXPORT :: foo call foo() end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40955
[Bug fortran/40969] [4.5 regression] gfortran.dg/c_by_val_1.f failed
--- Comment #2 from pault at gcc dot gnu dot org 2009-08-05 08:41 --- (In reply to comment #1) Works for me on x86-64-linux and seems also to work on several other systems according to the testresults mailing list. Works for me too at revision 150482 on x86_64/FC9 Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40877] memory leaks with gfc_charlen?
--- Comment #1 from pault at gcc dot gnu dot org 2009-08-05 08:57 --- * expr.c (simplify_const_ref) * symbol.c (gfc_set_default_type, generate_isocbinding_symbol) These two produce leaks. * trans-decl.c (create_function_arglist) This is OK - the new cl is threaded into the list. Thanks for spotting that. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-05 08:57:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40877
[Bug middle-end/39757] inconsistency in array bounds checking with -O3
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-05 10:01 --- By the way, we would prefer a preprocessed testcase, as minimal as possible. See http://gcc.gnu.org/bugs.html#report Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39757
[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-08-05 10:03
---
This example has four slightly different errors:
struct B {};
struct D : B {};
struct X {};
int foo(B*);
int i = foo( (B*)0 );
int j = foo( (D*)0 );
D* pd = 0;
int k = foo( pd );
X* px = 0;
int l = foo( px );
GCC 4.4.1 gives:
pr13979.cc:8:20: error: invalid initialization of non-const reference of type
B* from a temporary of type B*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
pr13979.cc:10:20: error: invalid initialization of non-const reference of type
B* from a temporary of type D*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
pr13979.cc:13:17: error: invalid initialization of reference of type B* from
expression of type D*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
pr13979.cc:16:17: error: invalid initialization of reference of type B* from
expression of type X*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
Comeau gives equivalent errors in all four cases. The only significant
difference is that Comeau doesn't mention the types in the first two errors.
GCC 2.95.2 is quite different:
pr13979.cc:8: initialization of non-const reference type `struct B *'
pr13979.cc:8: from rvalue of type `B *'
pr13979.cc:6: in passing argument 1 of `foo(B *)'
pr13979.cc:10: initializing non-const `B *' with `D *' will use a temporary
pr13979.cc:6: in passing argument 1 of `foo(B *)'
pr13979.cc:13: initializing non-const `B *' with `D *' will use a temporary
pr13979.cc:6: in passing argument 1 of `foo(B *)'
pr13979.cc:16: type `B' is not a base type for type `X'
pr13979.cc:6: in passing argument 1 of `foo(B *)'
I think the current diagnostics are better than the 2.95 ones. As I said
above, will use a temporary is misleading. The fourth error saying is not a
base type may be true, but is also misleading, because it wouldn't compile
even if it was a base type.
As I said earlier, it might be nice if the third error said e.g.
pr13979.cc:13:17: error: invalid initialization of reference of type B* from
expression of type D*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
pr13979.cc:13:17: note: conversion from `D*' to `B*' would create a temporary
However,
(In reply to comment #8)
I don't even know if we have different codepaths for those!
if it's not possible then I think the current diagnostics are reasonable, and
at least as good as Comeau's.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13979
[Bug middle-end/40965] [graphite] slow compilation
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-05 10:11 --- (In reply to comment #3) The code generation of Graphite can be exponential, didn't I mentioned it yet? however, I'm relatively certain that I tested graphite when it was introduced in 4.4, and it didn't impact compilation times much, also on this testcase. Could it be that something changed there? Unfortunately, I don't have a graphite enabled 4.4 build to verify it right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40965
[Bug c++/39858] C++: expected primary-expression error could be more useful
--- Comment #2 from manu at gcc dot gnu dot org 2009-08-05 10:16 --- At the moment the parser detects and reports the error, it doesn't know that it is parsing an array subscript. We could test for typical errors before trying to parse the expression but that would pessimize valid code. I am not sure what is the best approach in this case. If no expression is found, no error is reported but an empty expression is returned, we could test that and give an appropriate error. Otherwise, we need to propagate the context to the point where the error is reported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39858
[Bug middle-end/40965] [4.5 Regression][graphite] slow compilation
--- Comment #5 from jv244 at cam dot ac dot uk 2009-08-05 10:59 --- Checked against the 4.4 branch, with the following timings: 4.4 w/o1.79 w 1.80 4.5 w/o4.23 w144.30 -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.5.0 Known to work||4.4.2 Summary|[graphite] slow compilation |[4.5 Regression][graphite] ||slow compilation Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40965
[Bug fortran/40877] memory leaks with gfc_charlen?
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-05 11:27 --- (In reply to comment #1) * trans-decl.c (create_function_arglist) This is OK - the new cl is threaded into the list. Actually I think that this is not done properly. The code in question is: gfc_charlen *cl, *cl2; cl = f-sym-ts.cl; f-sym-ts.cl = gfc_get_charlen(); f-sym-ts.cl-length = cl-length; f-sym-ts.cl-backend_decl = cl-backend_decl; f-sym-ts.cl-length_from_typespec = cl-length_from_typespec; f-sym-ts.cl-resolved = cl-resolved; cl2 = f-sym-ts.cl-next; f-sym-ts.cl-next = cl; cl-next = cl2; First problem: cl2 is always NULL, since f-sym-ts.cl gets assigned a fresh gfc_charlen. Second problem: The new charlen is inserted in front of the old one, and not behind it. Let's say before this code is executed we have a linked list of charlen structures like this: something - cl - ... After the code is executed this will look like: something--- | new_cl - cl - NULL where 'something' still points to 'cl', so 'new_cl' is not reachable from within the linked list (and also cl-next is lost). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40877
[Bug fortran/40877] memory leaks with gfc_charlen?
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-05 11:44 --- The code from trans-decl.c (create_function_arglist) cited in comment #2 was committed by Tobias as r148517 just a few weeks ago, as a fix for PR 40383. Tobias, do you remember any of your thoughts when writing this? -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40877
[Bug target/37162] [4.4 Regression] gcc.c-torture/compile/20020120-1.c fails with ICE on -O[23s]
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-05 11:52 --- It compiles fine with both avr-gcc-4.3.3 and avr-gcc-4.4.0 -- abnikant dot singh at atmel dot com changed: What|Removed |Added CC||abnikant dot singh at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37162
[Bug target/37163] [4.4 Regression] gcc.c-torture/compile/pr32606.c fails with ICE on -Os
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-05 11:56 --- gcc.c-torture/compile/pr32606.c compiles fine with both avr-gcc-4.3.3 and avr-gcc-4.4.0 -- abnikant dot singh at atmel dot com changed: What|Removed |Added CC||abnikant dot singh at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37163
[Bug c++/40970] New: Initialization of reference with temporary
Following wrong code compiles and executes properly with 'g++ -Wall -O2', but
compiles and terminates with std::bad_alloc() 'g++ -Wall'. In both cases
expected behaviour would have been an error from compiler stating that it is
not possible to initialize a const long with a const double . gcc errors out
as expected with non const references.
$cat reference_test.cc
#include valarray
#include iostream
using namespace std;
templateclass Value
class T
{
const long dim;
public:
T(const double _dim) : dim(_dim)
{
cout dim endl;
}
Value newValue()
{
cout dim endl;
return Value(dim);
}
};
int main(int argc, char *argv[])
{
long dim = 10;
cout dim endl;
T valarraydouble factory(dim);
valarraydouble tmp = factory.newValue();
}
$g++-4.3.4 -Wall reference_test.cc
$./a.out
10
10
46934497319904
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
$g++-4.3.4 -Wall -O2 reference_test.cc
$./a.out
10
10
10
$g++-4.3.4 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3.4/configure --enable-__cxa_atexit
--disable-multilib --enable-languages=c++ --prefix=/iuehome/schnass/gcc-4.3.4
Thread model: posix
gcc version 4.3.4 (GCC)
--
Summary: Initialization of reference with temporary
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: devh at stuffit dot at
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40970
[Bug c++/31754] Improve column number accuracy in error messages
--- Comment #21 from manu at gcc dot gnu dot org 2009-08-05 12:09 --- Are there any failing testcases for this PR? Perhaps we can turn this into a meta-bug, or if there are no testcases right now, it would be better to close it (we have already enough open PRs). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
[Bug c++/40970] Initialization of reference with temporary
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-05 12:25 --- This is just triggering undefined behavior: after the constructor call dim is bound to a temporary long created on the fly from the double _dim, which disappears by the time newValue is called. Nothing to do with std::valarray or whatelse. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40970
[Bug c++/40970] Initialization of reference with temporary
--- Comment #2 from paolo dot carlini at oracle dot com 2009-08-05 12:29 --- Oh, you just want a warning for this. Indeed, ICC spills one with -Wall. Maybe Manuel has an opinion... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40970
[Bug c++/40970] Initialization of reference with temporary
--- Comment #3 from paolo dot carlini at oracle dot com 2009-08-05 12:34 --- Eh, eh... *** This bug has been marked as a duplicate of 986 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40970
[Bug c++/986] g++ misses warning for on temporary
--- Comment #24 from paolo dot carlini at oracle dot com 2009-08-05 12:34 --- *** Bug 40970 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||devh at stuffit dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug rtl-optimization/40924] [4.4 Regression] miscompiles with -03 (seemingly related to attribute may_alias)
--- Comment #6 from jakub at gcc dot gnu dot org 2009-08-05 12:36 --- Subject: Bug 40924 Author: jakub Date: Wed Aug 5 12:36:34 2009 New Revision: 150483 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150483 Log: PR rtl-optimization/40924 * dse.c (canon_address): Before calling cselib_expand_value_rtx make sure canon_rtx (mem_address) isn't simpler than canon_rtx (expanded_mem_address). * g++.dg/torture/pr40924.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr40924.C Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40924
[Bug fortran/40877] memory leaks with gfc_charlen?
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-05 12:50 --- (In reply to comment #3) Tobias, do you remember any of your thoughts when writing this? Well, they are essentially written in the patch email (linked from the PR 40383): http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01147.html The test case was: subroutine sub(a,b) character(4), optional :: a, b ! Known compile-time length which translates into: sub (a, b, a_, b_) where a_ and b_ are not used in the function (as the character length is known) except for the bounds checking. In that case one needs to access the TREE (or backend declaration) for a_ and for b_. However, as a and b are the same, they share the same cl - and the same backend type declaration (which is fine). Before Daniel's bounds check, the a_ and b_ TREEs were generated but not anywhere saved, as they are not needed. Daniel's patch simply added a pointer to a TREE to cl which points at that hidden argument. As there is only one cl shared by both a and b, one could only access b_ - that way one would effectively only check one of the arguments (incomplete check). However, if optional arguments are involved, that argument might be missing and b_ is 0, which turns it into a wrong diagnostic for a. One solution would be to create two cl - one for a and one for b. However, that would also create two type declaration TREEs even though a and b have exactly the same type. Already at present the middle end has problems with different TREE types for variables which have the same Fortran type. (Maybe I am wrong and we fixed this meanwhile and gfortran re-uses the TREE, but I do not think so.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40877
[Bug rtl-optimization/40924] [4.4 Regression] miscompiles with -03 (seemingly related to attribute may_alias)
--- Comment #7 from jakub at gcc dot gnu dot org 2009-08-05 12:54 --- Subject: Bug 40924 Author: jakub Date: Wed Aug 5 12:54:21 2009 New Revision: 150484 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150484 Log: PR rtl-optimization/40924 * dse.c (canon_address): Before calling cselib_expand_value_rtx make sure canon_rtx (mem_address) isn't simpler than canon_rtx (expanded_mem_address). * g++.dg/torture/pr40924.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr40924.C Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/dse.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40924
[Bug rtl-optimization/40924] [4.4 Regression] miscompiles with -03 (seemingly related to attribute may_alias)
--- Comment #8 from jakub at gcc dot gnu dot org 2009-08-05 12:55 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40924
[Bug c++/986] g++ misses warning for on temporary
--- Comment #25 from manu at gcc dot gnu dot org 2009-08-05 13:21 --- If anyone has any hint on where this could be caught, suggestions are welcome. The explanation of Alexandre Oliva in comment #8 is totally obscure to me and perhaps outdated given the age of this PR. -- manu at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-12-11 21:50:19 |2009-08-05 13:21:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug fortran/40877] memory leaks with gfc_charlen?
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-05 13:21 --- (In reply to comment #4) (In reply to comment #3) Tobias, do you remember any of your thoughts when writing this? Well, they are essentially written in the patch email (linked from the PR Yeah, ok, the general idea sounds fine. What I meant was that the way in which you copy the cl seems to create a memory leak (cf. comment #2), since the newly created cl is not reachable from any ns-cl_list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40877
[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved
--- Comment #10 from jason at redhat dot com 2009-08-05 13:42 --- Subject: Re: Error message about no matching function for call with derived class arguments could be improved On 08/04/2009 06:42 PM, manu at gcc dot gnu dot org wrote: I don't even know if we have different codepaths for those! We do: if there's a conversion that seems likely but invalid, we build it up but set bad_p on it so that we can give a more helpful diagnostic when we try to use it. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13979
[Bug c/20000] missing warning for noreturn function returning non-void
--- Comment #4 from manu at gcc dot gnu dot org 2009-08-05 13:55 --- What happens when a function must have a particular return type because it is accessed through a pointer, but we want to mark it as noreturn? Example: gcc/java/jcf.h (jcf_unexpected_eof) I am not sure this warning is all that useful as long as the function does not have a return statement, and we already warn about this. I propose to remove this warning altogether (less code, the same effect). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
Re: [Bug middle-end/40965] [4.5 Regression][graphite] slow compilation
What changed from 4.4 to 4.5 is that we now get to compile larger SCoPs with Graphite. In 4.5, Graphite can deal with reductions and other unhandled constructs like the NE_EXPR that Fortran is frequently using for representing the exit condition of DO loops.
[Bug middle-end/40965] [4.5 Regression][graphite] slow compilation
--- Comment #6 from sebpop at gmail dot com 2009-08-05 14:04 --- Subject: Re: [4.5 Regression][graphite] slow compilation What changed from 4.4 to 4.5 is that we now get to compile larger SCoPs with Graphite. In 4.5, Graphite can deal with reductions and other unhandled constructs like the NE_EXPR that Fortran is frequently using for representing the exit condition of DO loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40965
[Bug middle-end/40965] [4.5 Regression][graphite] slow compilation
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-05 14:05:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40965
[Bug target/40971] New: [4.4 Regression] ICE in memory_address
extern void bar (char *);
void
foo (int f, long a)
{
{
char d[32768];
bar (d);
}
double b = f;
while (a)
{
char c[8];
__builtin_memcpy (c, b, sizeof (c));
if (*(double *) c != 2.0)
break;
}
}
ICEs on powerpc-linux when compiled with -O -m32 -fstack-protector.
(plus:SI (reg:SI 150)
(const_int 32764 [0x7ffc]))
is not valid memory_address_p for DFmode, because that address offsetted by 4
isn't a valid offset.
--
Summary: [4.4 Regression] ICE in memory_address
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40971
[Bug target/40906] Wrong code generated for push of long double
--- Comment #3 from uros at gcc dot gnu dot org 2009-08-05 14:42 --- Subject: Bug 40906 Author: uros Date: Wed Aug 5 14:41:54 2009 New Revision: 150486 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150486 Log: PR target/40906 * config/i386/i386.c (ix86_split_long_move): Fix push of multi-part source operand. testsuite/ChangeLog: PR target/40906 * gcc.target/i386/pr40906-1.c: New test. * gcc.target/i386/pr40906-2.c: Ditto. * gcc.target/i386/pr40906-3.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/i386/pr40906-1.c trunk/gcc/testsuite/gcc.target/i386/pr40906-2.c trunk/gcc/testsuite/gcc.target/i386/pr40906-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40906
[Bug bootstrap/40972] New: libtool fails to detect pe-x86-64 import library
This prevents the build of libgomp.dll for example: *** Warning: linker path does not have real file for library -lpthread. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libpthread and none of the candidates passed a file format test *** using a file magic. Last file checked: C:/MinGW/cross-gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/x86_64-w64-mingw32/lib//libpthread.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. Rainer -- Summary: libtool fails to detect pe-x86-64 import library Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rainer at emrich-ebersheim dot de GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972
[Bug fortran/40973] New: Mark PRIVATE module functions as STATIC to faciliate optimization
We should consider marking module procedures with PRIVATE attribute as STATIC (in the C sense) such that they can be eliminated. In the following program, two could be optimized away as it cannot be called from outside the module. However, this does not happen with gfortran -O3 -c test.f90(nor with ifort -O3 -c test, nor for NAG f95, openf95) as nm test.o shows. I think STATIC does the right thing also if it is used as in the following example: procedure(), pointer :: ptr ! e.g. dummy argument, module variable, local variable ... ptr = two I think one cannot mark it as STATIC if it has a C binding name, i.e. PRIVATE but bind(C). It can be marked as STATIC, however, if it has no binding name: bind(C,name=). (Maybe I miss something as this optimization does not happen for so many compilers, but I fail to see the flaw.) MODULE M PRIVATE :: two CONTAINS SUBROUTINE one(a) integer :: a a = two() END SUBROUTINE one integer FUNCTION two() two = 42 END FUNCTION two END MODULE -- Summary: Mark PRIVATE module functions as STATIC to faciliate optimization Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40973
[Bug fortran/40847] [4.3/4.4/4.5 Regression] segfault bogus warning
--- Comment #6 from pault at gcc dot gnu dot org 2009-08-05 16:10 --- Subject: Bug 40847 Author: pault Date: Wed Aug 5 16:10:19 2009 New Revision: 150493 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150493 Log: 2009-08-05 Paul Thomas pa...@gcc.gnu.org PR fortran/40847 * iresolve.c (gfc_resolve_transfer): Correct error in 'mold' character length for case where length expresson is NULL. 2009-08-05 Paul Thomas pa...@gcc.gnu.org PR fortran/40847 * gfortran.dg/transfer_resolve_1.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_resolve_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40847
[Bug c/40967] Bad Intel64 codegen for modified 39495 testcase
--- Comment #1 from jakub at gcc dot gnu dot org 2009-08-05 16:24 --- I don't believe this is a valid OpenMP testcase. The standard says: The behavior is unspecified if any intermediate result required to compute the iteration count cannot be represented in the type determined above. and that I think applies here, to compute the number of iterations you should be able to compute end + step (for downward loop actually end - step) in the iteration type, but here that wraps over. IMHO 0U condition for omp for is only valid with step -1, not bigger steps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40967
[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190
--- Comment #7 from ramana at gcc dot gnu dot org 2009-08-05 16:42 --- Invalid testcase as per comment #6. (In reply to comment #4) I see the same problem when I try to compile transmission release 1.73. The error happens with file libtransmission/fdlimit.c. Works till -O1 but fails with -O2 or -O3. Seeing this error with gcc 4.21. Please file a separate bug report about this as per http://gcc.gnu.org/bugs.html if you can reproduce this for trunk or any of the current release branches. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36466
[Bug libstdc++/40974] New: cannot build gcc-4.4.1: fenv_t has not been declared
I'm using a gcc-4.4.1 cross-compiler to build another instance of gcc-4.4.1 for the target system. make fails with the following error message: make[2]: Entering directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3' make AR_FLAGS=rc CC_FOR_BUILD=gcc CC_FOR_TARGET=/mnt/clfs/cross-tools/usr/bin/x86_64-unknown-linux-gnu-gcc CFLAGS=-g -O2 -march=core2 CXXFLAGS=-g -O2 -D_GNU_SOURCE CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET=-g -O2 -march=core2 INSTALL=/usr/bin/install -c INSTALL_DATA=/usr/bin/install -c -m 644 INSTALL_PROGRAM=/usr/bin/install -c INSTALL_SCRIPT=/usr/bin/install -c LDFLAGS= LIBCFLAGS=-g -O2 -march=core2 LIBCFLAGS_FOR_TARGET=-g -O2 -march=core2 MAKE=make MAKEINFO=makeinfo --split-size=500 --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh RUNTESTFLAGS= exec_prefix=/usr infodir=/usr/info libdir=/usr/lib includedir=/usr/include prefix=/usr tooldir=/usr/x86_64-unknown-linux-gnu gxx_include_dir=/usr/include/c++/4.4.1 AR=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/ar AS=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/as LD=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/ld RANLIB=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/ranlib NM=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/nm NM_FOR_BUILD= NM_FOR_TARGET=/mnt/clfs/cross-tools/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../x86_64-unknown-linux-gnu/bin/nm DESTDIR= WERROR= all-recursive make[3]: Entering directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3' Making all in include make[4]: Entering directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include' mkdir -p ./x86_64-unknown-linux-gnu/bits/stdtr1c++.h.gch /mnt/clfs/cross-tools/usr/bin/x86_64-unknown-linux-gnu-c++ -x c++-header -g -O2 -D_GNU_SOURCE -I/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/mnt/clfs/sources/gcc-4.4.1/libstdc++-v3/libsupc++ -O2 -g /mnt/clfs/sources/gcc-4.4.1/libstdc++-v3/include/precompiled/stdtr1c++.h -o x86_64-unknown-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch In file included from /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/cfenv:46, from /mnt/clfs/sources/gcc-4.4.1/libstdc++-v3/include/precompiled/stdtr1c++.h:33: /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:49: error: '::fenv_t' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:50: error: '::fexcept_t' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:53: error: '::feclearexcept' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:54: error: '::fegetexceptflag' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:55: error: '::feraiseexcept' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:56: error: '::fesetexceptflag' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:57: error: '::fetestexcept' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:59: error: '::fegetround' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:60: error: '::fesetround' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:62: error: '::fegetenv' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:63: error: '::feholdexcept' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:64: error: '::fesetenv' has not been declared /mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1_impl/cfenv:65: error: '::feupdateenv' has not been declared make[4]: *** [x86_64-unknown-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch] Error 1 make[4]: Leaving directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory
[Bug c++/31423] Improve upon invalid use of member (did you forget the '' ?)
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-05 16:40 --- c.f isn't even valid, it should be C::f I didn't check the code, but that message isn't used for member variables or nested types, so if it does only apply to member functions then I think changing '' to '()' unconditionally makes sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug tree-optimization/29751] not optimizing access a[0] , a[1]
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-08-05 17:52 --- Created an attachment (id=18307) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18307action=view) Patch which I am testing This patch fixes the problem including a+1 and a+2 not aliasing each other. It adds two testcases and removes a xfail on one. It also fixes a bug in cfgexpand.c (update_alias_info_with_stack_vars) so that it does not create SSA_NAMES with a define statement of NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29751
[Bug c++/31423] Improve upon invalid use of member (did you forget the '' ?)
--- Comment #4 from bangerth at gmail dot com 2009-08-05 17:54 --- (In reply to comment #3) c.f isn't even valid, it should be C::f I didn't check the code, but that message isn't used for member variables or nested types, so if it does only apply to member functions then I think changing '' to '()' unconditionally makes sense. It also strictly wouldn't make things worse: the message we currently print hardly ever has anything to do with what is really happening, and replacing the ampersand by parentheses can only make things better even if it isn't always correct. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug c++/31423] Improve upon invalid use of member (did you forget the '' ?)
--- Comment #5 from bangerth at gmail dot com 2009-08-05 17:57 --- However, one of my gripes with the previous error message is that it's just too obscure: where did I forget the '', and why would I have wanted to write them in the first place? It could have said did you forget to take the address of this member function? and it would have been clearer to me what the message is supposed to tell me. So, in order to be a bit less obscure, how about this wording: 6: error: invalid use of member (did you forget the argument list?) W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug target/40957] [4.5 Regression] standard_sse_constant_opcode crash on x86 64
--- Comment #3 from hjl dot tools at gmail dot com 2009-08-05 18:04 --- A patch is posed at http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00277.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||08/msg00277.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40957
[Bug target/40906] Wrong code generated for push of long double
--- Comment #4 from uros at gcc dot gnu dot org 2009-08-05 18:05 --- Subject: Bug 40906 Author: uros Date: Wed Aug 5 18:04:42 2009 New Revision: 150497 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150497 Log: PR target/40906 * config/i386/i386.c (ix86_split_long_move): Fix push of multi-part source operand. testsuite/ChangeLog: PR target/40906 * gcc.target/i386/pr40906-1.c: New test. * gcc.target/i386/pr40906-2.c: Ditto. * gcc.target/i386/pr40906-3.c: Ditto. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr40906-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr40906-2.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr40906-3.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/i386.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40906
[Bug c++/40975] New: internal compiler error: in copy_tree_r, at tree-inline.c
Using array new as a default initializer of a constructor argument, when the
object being newed itself contains a constructor, crashes the compiler with
an error similar to the following:
% g++ -c gcc_bug.cpp
gcc_bug.cpp:13: internal compiler error: in copy_tree_r, at
tree-inline.c:3160
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions.
The following code example clearly demonstrates the problem.
// BEGIN gcc_bug.cpp
struct data_type
{
// constructor required to reproduce compiler bug
data_type() {}
};
struct ptr_type
{
// array new as default argument required to reproduce compiler bug
ptr_type (data_type* ptr = new data_type[1]) { delete[] ptr; }
};
ptr_type obj;
// END gcc_bug.cpp
The problem is visible in multiple versions of the compiler on multiple
systems:
% g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
% g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
% g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
% g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Note that the problem is _not_ visible on the following compilers/platforms:
% g++-4.0 -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5484~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5484)
g++-4.2 -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5564~1/src/configure --disable-checking
--enable-werror --prefix=/usr --mandir=/usr/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-gxx-include-dir=/usr/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --host=i686-apple-darwin9
--target=i686-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5564)
--
Summary: internal compiler error: in copy_tree_r, at tree-
inline.c
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jonathan dot jones at mathworks dot com
GCC build triplet: x86_64-linux-gnu, i486-linux-gnu
GCC host triplet: x86_64-linux-gnu, i486-linux-gnu
GCC target triplet: x86_64-linux-gnu, i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40975
[Bug c++/31423] Improve upon invalid use of member (did you forget the '' ?)
--- Comment #6 from manu at gcc dot gnu dot org 2009-08-05 18:19 --- Examples where the ampersand probably makes more sense are: g++.dg/rtti/typeid8.C g++.dg/conversion/memfn2.C g++.old-deja/g++.other/asm2.C Not so sure about: g++.dg/template/pseudodtor3.C g++.dg/template/using14.C So this is not as trivial. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug c/40967] Bad Intel64 codegen for modified 39495 testcase
--- Comment #2 from brian dot e dot bliss at intel dot com 2009-08-05
18:46 ---
My interpretation of that rule is that this is a legal testcase as long as ub
is even at runtime. If ub is odd, then the behavior is undefined.
Anyway - that is a subject for bug 39495. What I'm trying to address here is
the codegen problem, which doesn't seem to depend on the termination condition.
Try
#include stdlib.h
#include omp.h
void foo(unsigned ub, unsigned N, unsigned *array)
{
unsigned i;
#pragma omp for schedule(dynamic)
for (i = ub; i N; i -=2) {
array[i] = i;
}
}
and you still see ia32 code in setting up the parameters for the call to
GOMP_loop_dynamic_start:
movl$1, %ecx
movl$4294967294, %edx
movq%rbx, %rsi
movq%rax, %rdi
callGOMP_loop_dynamic_start
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40967
[Bug c++/31423] Improve upon invalid use of member (did you forget the '' ?)
--- Comment #7 from bangerth at gmail dot com 2009-08-05 18:47 --- (In reply to comment #6) Examples where the ampersand probably makes more sense are: g++.dg/rtti/typeid8.C g++.dg/conversion/memfn2.C g++.old-deja/g++.other/asm2.C Possibly, but in all those cases, it may also have been a call expression: - in typeid8.C, did the user mean typeid (A::foo).name (); or typeid (A::foo()).name (); (assuming A::foo is static)? Certainly in the case typeid (foo).name (); it is more likely that she wanted to say foo() than A::foo. - in memfn2.C, void (*p)() = i ? foo : foo was more likely meant to say void (*p)() = i ? foo() : foo() than void (*p)() = i ? A::foo : A::foo All I really mean is that it's at the very least equally likely that people forget the parentheses than the ampersand. Just as another argument, people *call* functions much more often than they *take the address* of them -- so, all things being equal, it's probably more likely that in any given context the intent was a call, rather than taking the address. W. Not so sure about: g++.dg/template/pseudodtor3.C g++.dg/template/using14.C So this is not as trivial. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug testsuite/40704] ^M? in testsuite log leads to binary attachment
--- Comment #4 from hjl dot tools at gmail dot com 2009-08-05 18:47 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00284.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||08/msg00284.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40704
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #3 from hjl dot tools at gmail dot com 2009-08-05 18:58 --- (In reply to comment #1) Works for me on x86-64-linux and seems also to work on several other systems according to the testresults mailing list. (Only failure - your ia64 system: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00487.html) As I cannot reproduce it, can you provide more details? It is caused by revision 150465: http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00145.html It is run-time failure. * * * Side note: Can you change your tester to not attach the results as binary but as text/..., cf. http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00484.html; that makes is quicker to reading the test results. See PR 40704. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||burnus at net-b dot de OtherBugsDependingO||40949 nThis|| Summary|[4.5 regression]|[4.5 regression] Revision |gfortran.dg/c_by_val_1.f|150465 failed |failed |gfortran.dg/c_by_val_1.f http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #4 from kargl at gcc dot gnu dot org 2009-08-05 19:06 --- (In reply to comment #3) (In reply to comment #1) Works for me on x86-64-linux and seems also to work on several other systems according to the testresults mailing list. (Only failure - your ia64 system: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00487.html) As I cannot reproduce it, can you provide more details? It is caused by revision 150465: http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00145.html It is run-time failure. You have got to be kidding! This is not the details that was requested. Your subject line already pointed to the revision. Where the heck is the backtrace? What's the difference in generated assembly before and after the revision? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #5 from hjl dot tools at gmail dot com 2009-08-05 19:07 --- (gdb) bt #0 0xa0010621 in __kernel_syscall_via_break () #1 0x203e7630 in raise () from /lib/tls/libc.so.6.1 #2 0x203ea010 in abort () from /lib/tls/libc.so.6.1 #3 0x400014b0 in f_to_f__ (retval=0x6fffb420, a1=0, a2=0x6fffb430, a3=0x6fffb418) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val.c:21 #4 0x4ad0 in c_by_val_1 () at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val_1.f:18 #5 0x400013e0 in main (argc=1, argv=0x6fffb99c /export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gfortran/c_by_val_1.exe) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val_1.f:52 #6 0x203bd430 in __libc_start_main () from /lib/tls/libc.so.6.1 #7 0x48a0 in _start () (gdb) f 3 #3 0x400014b0 in f_to_f__ (retval=0x6fffb420, a1=0, a2=0x6fffb430, a3=0x6fffb418) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val.c:21 21if ( a1 != *a2 ) abort(); (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #6 from hjl dot tools at gmail dot com 2009-08-05 19:09 --- 21if ( a1 != *a2 ) abort(); (gdb) p a1 $1 = 0 (gdb) p *a2 $2 = 42 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #7 from hjl dot tools at gmail dot com 2009-08-05 19:22 --- When we see external f_to_f, i_to_i, c_to_c external f_to_f8, i_to_i8, c_to_c8 and do typelist = gfc_chainon_list (typelist, void_type_node); Later, we see call f_to_f (b, %VAL (a), %REF (c), %LOC (c)) We build typelist again with an extra void_type_node at the beginning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #8 from hjl dot tools at gmail dot com 2009-08-05 19:28 --- (In reply to comment #7) When we see external f_to_f, i_to_i, c_to_c external f_to_f8, i_to_i8, c_to_c8 and do typelist = gfc_chainon_list (typelist, void_type_node); Later, we see call f_to_f (b, %VAL (a), %REF (c), %LOC (c)) We build typelist again with an extra void_type_node at the beginning. That is incorrect. For some reason, typelist is always NULL before the change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #9 from burnus at gcc dot gnu dot org 2009-08-05 19:33 --- (In reply to comment #6) 21if ( a1 != *a2 ) abort(); (gdb) p a1 $1 = 0 (gdb) p *a2 $2 = 42 Thanks! I think the following patch should cure this. I think we will still have issues with LTO but those are inevitable and need to be solved on the middle end. Index: trans-types.c === --- trans-types.c (Revision 150497) +++ trans-types.c (Arbeitskopie) @@ -2324,7 +2324,10 @@ while (nstr--) typelist = gfc_chainon_list (typelist, gfc_charlen_type_node); - typelist = gfc_chainon_list (typelist, void_type_node); + /* If the explicit interface is known, we tell the middle end + that no more additional arguments will follow in calls. */ + if (sym-attr.if_source != IFSRC_UNKNOWN) +typelist = gfc_chainon_list (typelist, void_type_node); if (alternate_return) type = integer_type_node; -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-05 19:33:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40976] New: Merge DECL of procedure call with DECL of gfc_get_function_type
Motivated by PR 40969. Currently, we generate a function declaration for procedure(empty or interface) :: proc and another one for call proc(something) ! or var = proc(something) If no explicit interface is known, the function argument is undefined, which causes problems with LTO, cf. PR 40949 and PR 40969. In principle, one could update the formal argument list of the proc symbol when encountering the procedure call. That should be already done in the front end and will also provide a means of diagnosing call errors such as: call proc(4) call proc(4.0, 4) ! wrong type, different number of arguments Additionally, one should then re-use the DECL. -- Summary: Merge DECL of procedure call with DECL of gfc_get_function_type Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #10 from hjl dot tools at gmail dot com 2009-08-05 19:49 --- (In reply to comment #9) Thanks! I think the following patch should cure this. I think we will still have issues with LTO but those are inevitable and need to be solved on the middle end. Index: trans-types.c === --- trans-types.c (Revision 150497) +++ trans-types.c (Arbeitskopie) @@ -2324,7 +2324,10 @@ while (nstr--) typelist = gfc_chainon_list (typelist, gfc_charlen_type_node); - typelist = gfc_chainon_list (typelist, void_type_node); + /* If the explicit interface is known, we tell the middle end + that no more additional arguments will follow in calls. */ + if (sym-attr.if_source != IFSRC_UNKNOWN) +typelist = gfc_chainon_list (typelist, void_type_node); if (alternate_return) type = integer_type_node; It failed at a different place: (gdb) bt #0 0xa0010621 in __kernel_syscall_via_break () #1 0x203e7630 in raise () from /lib/tls/libc.so.6.1 #2 0x203ea010 in abort () from /lib/tls/libc.so.6.1 #3 0x40001ac0 in c_to_c__ (retval=0x6fffb498, c1=43 + 0 * I, c2=0x6fffb480, c3=0x6fffb3e8) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val.c:61 #4 0x4f50 in c_by_val_1 () at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val_1.f:42 #5 0x40001430 in main (argc=1, argv=0x6fffb983 /export/build/gnu/gcc-work/build-ia64-linux/gcc/testsuite/gfortran/c_by_val_1.exe) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val_1.f:52 #6 0x203bd430 in __libc_start_main () from /lib/tls/libc.so.6.1 #7 0x48a0 in _start () (gdb) f 3 #3 0x40001ac0 in c_to_c__ (retval=0x6fffb498, c1=43 + 0 * I, c2=0x6fffb480, c3=0x6fffb3e8) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val.c:61 61if ( c1 != *c2) abort(); (gdb) p c1 $1 = 43 + 0 * I (gdb) p *c2 $2 = -1 + 2 * I (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #11 from hjl dot tools at gmail dot com 2009-08-05 19:52 --- This patch works: --- ./trans-types.c.foo 2009-08-05 07:26:53.0 -0700 +++ ./trans-types.c 2009-08-05 12:51:00.0 -0700 @@ -2324,7 +2324,10 @@ gfc_get_function_type (gfc_symbol * sym) while (nstr--) typelist = gfc_chainon_list (typelist, gfc_charlen_type_node); - typelist = gfc_chainon_list (typelist, void_type_node); + /* If the explicit interface is known, we tell the middle end + that no more additional arguments will follow in calls. */ + if (typelist || sym-attr.if_source != IFSRC_UNKNOWN) +typelist = gfc_chainon_list (typelist, void_type_node); if (alternate_return) type = integer_type_node; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #12 from burnus at gcc dot gnu dot org 2009-08-05 20:03 --- (In reply to comment #10) It failed at a different place: 61if ( c1 != *c2) abort(); (gdb) p c1 $1 = 43 + 0 * I (gdb) p *c2 $2 = -1 + 2 * I Hmm, I honestly have no idea why this fails. In my understanding, it should have failed before and should now be working. The reason is that for call f_to_f (b, %VAL (a), %REF (c), %LOC (c)) using external f_to_f generates a prototype void f_to_f(...) which my previous patch in PR 40949 wrongly modified to void f_to_f(void). However, for v = c_to_c (%VAL (u), %REF (w), %LOC (w)) with external c_to_c complex c_to_c and call by reference (-ff2c), the prototype should be void c_to_c(complex*, ...) In my opinion that's what my patch in comment 9 does, while pre-PR40949 gfortran appended a void node, leading to void c_to_c(complex *) // misses , ... I think I miss something obvious here. * * * At the end, gfortran should produce a proper prototype, which is useful to have to provide better diagnostics and needed to fix some LTO issues. I filled PR 40976 to track this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40877] memory leaks with gfc_charlen?
--- Comment #8 from janus at gcc dot gnu dot org 2009-08-05 20:25 --- I guess I'll take over then. Got a patch. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-08-05 08:57:08 |2009-08-05 20:25:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40877
[Bug c/40977] New: Problem with code like this: res = ((uint64_t)resh 32) | resl;
Hi,
When I compile source code with GCC 4.4.1 (-m68060 -O3 -fomit-frame-pointer):
#include stdint.h
#define umul_ppmm(xh, xl, a, b) \
__asm__ (| Inlined umul_ppmm\n \
move%.l %2,%/d0\n \
move%.l %3,%/d1\n \
move%.l %/d0,%/d2\n\
swap%/d0\n \
move%.l %/d1,%/d3\n\
swap%/d1\n \
move%.w %/d2,%/d4\n\
mulu%/d3,%/d4\n\
mulu%/d1,%/d2\n\
mulu%/d0,%/d3\n\
mulu%/d0,%/d1\n\
move%.l %/d4,%/d0\n\
eor%.w %/d0,%/d0\n\
swap%/d0\n \
add%.l %/d0,%/d2\n\
add%.l %/d3,%/d2\n\
jcc 1f\n \
add%.l %#65536,%/d1\n \
1: swap%/d2\n \
moveq %#0,%/d0\n \
move%.w %/d2,%/d0\n\
move%.w %/d4,%/d2\n\
move%.l %/d2,%1\n \
add%.l %/d1,%/d0\n\
move%.l %/d0,%0\
: =g ((uint32_t) (xh)),\
=g ((uint32_t) (xl)) \
: g ((uint32_t) (a)), \
g ((uint32_t) (b)) \
: d0, d1, d2, d3, d4)
int64_t MUL64(int a, int b)
{
uint32_t au = a;
uint32_t bu = b;
uint32_t resh, resl;
uint64_t res;
umul_ppmm(resh, resl, au, bu);
if (a 0)
resh -= bu;
if (b 0)
resh -= au;
res = ((uint64_t)resh 32) | resl;
return res;
}
I get this asm output:
#NO_APP
.text
.even
.globl _MUL64
_MUL64:
movem.l #16128,-(sp)
move.l 28(sp),a0
move.l 32(sp),a1
#APP
| Inlined umul_ppmm
move.l a0,d0
move.l a1,d1
move.l d0,d2
swapd0
move.l d1,d3
swapd1
move.w d2,d4
mulud3,d4
mulud1,d2
mulud0,d3
mulud0,d1
move.l d4,d0
eor.w d0,d0
swapd0
add.l d0,d2
add.l d3,d2
jcc 1f
add.l #65536,d1
1: swapd2
moveq #0,d0
move.w d2,d0
move.w d4,d2
move.l d2,d6
add.l d1,d0
move.l d0,d5
#NO_APP
tst.l a0
jlt L6
tst.l a1
jlt L7
L3:
move.l d5,d0
clr.l d1
move.l d0,d2
move.l d1,d3
or.l d6,d3
move.l d2,d6
move.l d3,d7
move.l d2,d0
move.l d7,d1
movem.l (sp)+,#252
rts
L7:
sub.l a0,d5
move.l d5,d0
clr.l d1
move.l d0,d2
move.l d1,d3
or.l d6,d3
move.l d2,d6
move.l d3,d7
move.l d2,d0
move.l d7,d1
movem.l (sp)+,#252
rts
L6:
sub.l a1,d5
tst.l a1
jge L3
jra L7
The asm output is not good (not optimized), because GCC 4.4.1 have problems
with this part of the code:
res = ((uint64_t)resh 32) | resl;
GCC 3.4.0 generates better asm output (-m68060 -O3 -fomit-frame-ppointer):
#NO_APP
.text
.even
.globl _MUL64
_MUL64:
moveml #0x3e00,s...@-
movel sp@(24),a1
movel sp@(28),a0
#APP
| Inlined umul_ppmm
movel a1,d0
movel a0,d1
movel d0,d2
swapd0
movel d1,d3
swapd1
movew d2,d4
mulud3,d4
mulud1,d2
mulud0,d3
mulud0,d1
movel d4,d0
eorwd0,d0
swapd0
addld0,d2
addld3,d2
jcc 1f
addl#65536,d1
1: swapd2
moveq #0,d0
movew d2,d0
movew d4,d2
movel d2,d6
addld1,d0
movel d0,d5
#NO_APP
tstl a1
jlt L5
tstl a0
jge L3
jra L6
.even
L5:
[Bug fortran/40978] New: Use named return value (NRV) for functions returning the result as argument
Motivated by PR 40969. See also PR 40976. For functions where the result is returned by argument, one should use C++'s named return value optimization (NRV), cf. http://en.wikipedia.org/wiki/Return_value_optimization That presumably also allows to mark PURE functions which return their result as NRV to be marked as PURE. Caveat: Presumably, using result, result_ for character strings does not work with NRV as currently implemented. See also: CALL_EXPR_RETURN_SLOT_OPT TODO: Check that the ABI is preserved. -- Summary: Use named return value (NRV) for functions returning the result as argument Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40978
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #13 from burnus at gcc dot gnu dot org 2009-08-05 20:36 --- (In reply to comment #11) This patch works: + if (typelist || sym-attr.if_source != IFSRC_UNKNOWN) +typelist = gfc_chainon_list (typelist, void_type_node); That patch essentially undoes the patch of PR 40949 as this is essentially identically to if (typelist) typelist = gfc_chainon_list (typelist, void_type_node); I think it is best to go back to the old version (i.e. revert the patch PR 40949) and fix it properly as proposed in PR 40976 (and in PR 40978) -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-08-05 19:33:47 |2009-08-05 20:42:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40976] Merge DECL of procedure call with DECL of gfc_get_function_type
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-05 20:43 --- See also vaguely related PR 40978. -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||40949 nThis|| AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-05 20:43:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
[Bug fortran/40949] FAIL: gfortran.dg/proc_ptr_7.f90
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-05 20:47 --- Subject: Bug 40949 Author: burnus Date: Wed Aug 5 20:47:19 2009 New Revision: 150500 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150500 Log: 2009-08-05 Tobias Burnus bur...@net-b.de PR fortran/40969 Revert: 2009-08-04 Tobias Burnus bur...@net-b.de PR fortran/40949 * trans-types.c (gfc_get_function_type): Fix typelist of functions without argument. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40949
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #14 from burnus at gcc dot gnu dot org 2009-08-05 20:47 --- Subject: Bug 40969 Author: burnus Date: Wed Aug 5 20:47:19 2009 New Revision: 150500 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150500 Log: 2009-08-05 Tobias Burnus bur...@net-b.de PR fortran/40969 Revert: 2009-08-04 Tobias Burnus bur...@net-b.de PR fortran/40949 * trans-types.c (gfc_get_function_type): Fix typelist of functions without argument. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-08-05 20:51 --- The long-dead declaration is brought back to life by the following line in gimplify_var_or_parm_decl() in gimplify.c: tree value_expr = DECL_VALUE_EXPR (decl); I don't know why that happens yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40464
[Bug fortran/40949] FAIL: gfortran.dg/proc_ptr_7.f90
--- Comment #6 from burnus at gcc dot gnu dot org 2009-08-05 20:51 --- Patch broke IA64 and was reverted (cf. 40969). Proper fix is PR 40976 which should solve several of the remaining LTO problems as well. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40949
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #15 from burnus at gcc dot gnu dot org 2009-08-05 20:52 --- FIXED by reverting the bug. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug target/40906] Wrong code generated for push of long double
--- Comment #5 from uros at gcc dot gnu dot org 2009-08-05 21:17 --- Subject: Bug 40906 Author: uros Date: Wed Aug 5 21:16:52 2009 New Revision: 150501 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150501 Log: PR target/40906 * config/i386/i386.c (ix86_split_long_move): Fix push of multi-part source operand. testsuite/ChangeLog: PR target/40906 * gcc.target/i386/pr40906-1.c: New test. * gcc.target/i386/pr40906-2.c: Ditto. * gcc.target/i386/pr40906-3.c: Ditto. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr40906-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr40906-2.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr40906-3.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40906
[Bug target/40906] Wrong code generated for push of long double
--- Comment #6 from ubizjak at gmail dot com 2009-08-05 21:19 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.4.1 4.3.4 Resolution||FIXED Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40906
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- Comment #11 from sje at cup dot hp dot com 2009-08-05 21:36 --- Created an attachment (id=18308) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18308action=view) C++ test case that fails with plausible patch This is cut down from libstdc++-v3 sources. I am not sure it is still legal C++ but it generates the same error that I was getting during the libstdc++-v3 build. No special options are needed, it will fail with: x.cc: In member function 'virtual std::string std::generic_error_category::message(int) const': x.cc:14:61: internal compiler error: in expand_expr_real_1, at expr.c:7427 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-05 22:26 --- You should try to figure out the reason of those errors: whether, for some reason, _GLIBCXX_HAVE_FENV_H is undefined, thus fenv.h is not included in tr1/cfenv. Or, the configure test for the facilities in fenv.h (generated from acinclude.m4) wrongly defines _GLIBCXX_USE_C99_FENV_TR1. All in all, the issue is very mysterious to me, on x86_64-linux, in any case, fenv.h should be perfectly fine. I suspect you are doing something wrong in the setup for cross-compilation. I must also say, not being an expert of cross-compilation, I have no idea what are you trying to do, why you actually need a cross-compiler, if you are targeting your same machine... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
[Bug c++/40975] internal compiler error: in copy_tree_r, at tree-inline.c
--- Comment #1 from mikpe at it dot uu dot se 2009-08-05 22:42 --- I can reproduce this ICE on i686-linux with gcc-4.3-20090802 and gcc-4.4-20090804. gcc-4.5 has some nasty new build requirements for c++ so I didn't try it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40975
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- Comment #12 from bonzini at gnu dot org 2009-08-05 23:09 ---
Created an attachment (id=18309)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18309action=view)
another patch
This failure is related to NRV, which is why there is no C failure.
If I take care of it the patch is actually nicer because there's no distinction
between RESULT_DECL and PARM_DECL. for_return == 2 now means simply the
register in/from which a PARM_DECL/RESULT_DECL is copied.
This means that the only code that needs to special case promote_function_mode
is code copying from parameter registers (calls.c) and into the result
(expand_value_return in stmt.c). I checked the pre-patch code and everybody
else used to guard the call to promote_mode(..., 1) with a call to the
promote_args/promote_return hook; this means that now they can call
promote_function_mode with a final argument that is 0 or 1.
BTW here is a minimal testcase:
struct A
{
A (const A __str);
A (const char * __s);
};
struct B
{
virtual A a (void) const { return A (hi); }
};
const B b;
--
bonzini at gnu dot org changed:
What|Removed |Added
Attachment #18304|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40979] New: induct benchmark 60% slower when compiled with -fgraphite-identity
The Polyhedron 2005 induct benchmark averages 12.44 seconds run-time when compiled with... gfortran -ffast-math -funroll-loops -msse3 -O3 induct.f90 -o induct but averages 20.2 seconds when compiled with -fgraphite-identity added to the compilation flags. This issue remains after... http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00220.html http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00294.html are applied to r150500. -- Summary: induct benchmark 60% slower when compiled with - fgraphite-identity Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
[Bug middle-end/40980] New: air.f90 ICEs compiler with -fgraphite-identity
When the Polyhedron 2005 benchmark air.f90 is compiled with -fgraphite-identity, the compiler ICEs with the error... gfortran -O2 -fgraphite-identity air.f90 -o air air.f90: In function spectop: air.f90:1064:0: error: Incompatible types in PHI argument 0 character(kind=4) integer(kind=4) ivtmp.1799_745 = PHI var.1825_744(157), D.2584_20(158) air.f90:1064:0: internal compiler error: verify_stmts failed Using built-in specs. Target: x86_64-apple-darwin10 Configured with: ../gcc-4.5-20090805/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 Thread model: posix gcc version 4.5.0 20090805 (experimental) (GCC) -- Summary: air.f90 ICEs compiler with -fgraphite-identity Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40980
[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-06 00:23:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
[Bug middle-end/40980] air.f90 ICEs compiler with -fgraphite-identity
--- Comment #1 from spop at gcc dot gnu dot org 2009-08-06 00:26 --- This makes me think that Tobias' regtester does not test the polyhedron benchmarks in the extra tests, or it does not report anymore the failures. I will investigate this issue. -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-06 00:26:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40980
[Bug middle-end/40981] New: aermod.f90 ICEs on -O2 -fgraphite-identity -floop-strip-mine
The Polyhedron 2005 benchmark aermod.f90 ICEs the gfortran compiler when compiled with... gfortran -O2 -fgraphite-identity -floop-strip-mine aermod.f90 -o aermod producing the error... aermod.f90: In function chk_endyr: aermod.f90:5620:0: internal compiler error: Floating point exception This error doesn't occur with... gfortran -O2 -fgraphite-identity aermod.f90 -o aermod ..or... gfortran -O2 -fgraphite-identity -floop-interchange aermod.f90 -o aermod Using built-in specs. Target: x86_64-apple-darwin10 Configured with: ../gcc-4.5-20090805/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 Thread model: posix gcc version 4.5.0 20090805 (experimental) (GCC) -- Summary: aermod.f90 ICEs on -O2 -fgraphite-identity -floop-strip- mine Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40981
[Bug middle-end/40981] aermod.f90 ICEs on -O2 -fgraphite-identity -floop-strip-mine
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-06 01:07:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40981
[Bug middle-end/40982] New: induct.f90 ICEs compiler using -O3 -fgraphite-identity -floop-interchange
When the Polyhedron 2005 benchmark induct.f90 is compiled with... gfortran -O3 -fgraphite-identity -floop-interchange induct.f90 -o induct ...the compiler ICEs with errors of the form... induct.f90: In function mutual_ind_quad_cir_coil: induct.f90:1441:0: error: virtual SSA name for non-VOP decl while verifying SSA_NAME var.1895_512 in statement # .MEM_407 = VDEF .MEM_408 var.1895_512 = __builtin_cexpi (var.1894_513); induct.f90:1441:0: error: virtual SSA name for non-VOP decl while verifying SSA_NAME var.1893_518 in statement # .MEM_408 = VDEF .MEM_409 var.1893_518 = __builtin_cexpi (var.1892_1429); induct.f90:1441:0: error: virtual SSA name for non-VOP decl while verifying SSA_NAME var.1890_579 in statement # .MEM_409 = VDEF .MEM_410 var.1890_579 = __builtin_cexpi (var.1889_580); induct.f90:1441:0: error: virtual SSA name for non-VOP decl while verifying SSA_NAME var.1888_597 in statement while verifying SSA_NAME var.2069_3678 in statement # .MEM_3715 = VDEF .MEM_3714 var.2069_3678 = __builtin_cexpi (var.2068_3677); induct.f90:1441:0: error: virtual SSA name for non-VOP decl while verifying SSA_NAME var.2071_3685 in statement # .MEM_3716 = VDEF .MEM_3715 var.2071_3685 = __builtin_cexpi (var.2070_3684); induct.f90:1441:0: internal compiler error: in is_hidden_global_store, at tree-ssa-sink.c:196 The ICE doesn't occur with -O2 -fgraphite-identity -floop-interchange. Using built-in specs. Target: x86_64-apple-darwin10 Configured with: ../gcc-4.5-20090805/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 Thread model: posix gcc version 4.5.0 20090805 (experimental) (GCC) with http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00220.html and http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00294.html applied to r150500. -- Summary: induct.f90 ICEs compiler using -O3 -fgraphite-identity - floop-interchange Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40982
[Bug middle-end/40980] air.f90 ICEs compiler with -fgraphite-identity
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-08-06 01:28 --- Interestingly... gfortran -O2 -fgraphite-identity -floop-interchange air.f90 -o air compiles the air benchmark without errors but the resulting code produces... AIRFLOW IN A BOX Version 2.0 (c) Hanley Innovations 1995 1.2E-002 0.210.000 0.100010 272.769998272.769998272.769998 272.7699980. 11 12 X-DATA 1 0. 0.100014 2 5.00028E-002 0.220004 3 0.10001 0.24 4 0.20001 0.400024 5 0.2 0.54 6 0.40002 0.599984 7 0.5 0.699964 8 0.59998 0.800044 9 0.69996 0.900024 10 0.80004 0.969974 11 0.900021.4 Y-DATA 0. 0.100014 4.8E-002 0.149994 8.00017E-002 0.200014 0.14999 0.24 0.20001 0.400024 0.2 0.54 0.40002 0.599984 0.5 0.699964 0.59998 0.800044 0.69996 0.890014 0.80004 0.949964 0.949961.4 ITERATION# TIME FINAL MASS RESIDUAL 14 100.43187820 0.0100 NaN deltat, final t, iterations 100.00100.4318782042 14 14 NaN -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40980
[Bug middle-end/40982] induct.f90 ICEs compiler using -O3 -fgraphite-identity -floop-interchange
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-06 02:22:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40982
[Bug target/40983] New: The scheduler incorrectly swaps MMX and floating point instructions
Hi This example fails, because in function f, the scheduler incorrectly swapped floating point store to c and load of mmx registers. Compile with -O2 -march=pentium-mmx -- Summary: The scheduler incorrectly swaps MMX and floating point instructions Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
[Bug target/40983] The scheduler incorrectly swaps MMX and floating point instructions
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-08-06 04:12 --- Created an attachment (id=18310) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18310action=view) A failing example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
[Bug target/40983] The scheduler incorrectly swaps MMX and floating point instructions
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-08-06 04:15 --- Assembler output: f: pushl %ebp movl%esp, %ebp subl$16, %esp movq%mm0, -8(%ebp) movq%mm1, -16(%ebp) emms fldla faddl b movq-8(%ebp), %mm0 paddd -16(%ebp), %mm0 fstpl c leave ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
